Localisation of web app

Ladies and Gentlemen..

I've got a moderately complex web application in PHP feeding off MySQL
and user input. The application is in English, but we need to localise
it into other languages. We also need to devise a system that makes it
easy to administer for translator(s) and programmer(s) and suffers
minimal performance slow down. Of course this issue should have been
considered at the design stage, but it's too late now.

I see three routes..

1) Replace text with string variables which get their values via queries
to a MySQL table. This would be easiest to set up and easiest to
administer. But would it significantly slow performance compared to
either of the other options?

2) Replace text with string variables which get their values from
include files. This would also be almost as easy to administer and
presumably faster than 1.

3) Hard code translations right into the php pages. This would
presumably offer fastest performance, but would be bloody difficult to
administer, particularly with upgrades.

Do you have any experience with this kind of thing? My inclination is to
go with option (2). But you are the experts. Perhaps I am wrong or there
is a better solution I haven't seen.

Many thanks!

Jeffrey

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Localisation of web app

Jeffrey wrote:
> Ladies and Gentlemen..
>
> I've got a moderately complex web application in PHP feeding off MySQL
> and user input. The application is in English, but we need to localise
> it into other languages. We also need to devise a system that makes it
> easy to administer for translator(s) and programmer(s) and suffers
> minimal performance slow down. Of course this issue should have been
> considered at the design stage, but it's too late now.
>
> I see three routes..
>
> 1) Replace text with string variables which get their values via queries
> to a MySQL table. This would be easiest to set up and easiest to
> administer. But would it significantly slow performance compared to
> either of the other options?
>
> 2) Replace text with string variables which get their values from
> include files. This would also be almost as easy to administer and
> presumably faster than 1.

1 & 2 are good. I use #2 because my database is already pretty big and I
wanted to have separate language files per section of the app (much the
same as the db setup I outline below).

#1 shouldn't be too slow - I'd suggest four columns:

lang_id (auto_increment)
page
lang_variable
lang_description

The 'page' is for the page (or url if you prefer) that the language
variable is for. That way you only have to load up the ones you need:

select * from lang_table where page='xyz';

Just create an index on the page so that the loading is quick and you're
done.

The others should be self-explanatory.

> 3) Hard code translations right into the php pages. This would
> presumably offer fastest performance, but would be bloody difficult to
> administer, particularly with upgrades.

That's as bad as not having translations in the first place - so forget
about that one.

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php