My approach to multi lang abilities uses the following db structure
base_name is the input field name and the basic raw label for the field
lang_1
lang_2
...
lang_12
prompt_1
prompt_2
...
prompt_12
since i currently need to support 12 languages in the initial concept
when the user signs on, i equate the language to an offset on the table to be
able to pull the correct language out of the tables. I have the prompts in
there to provide prompts for input fields as required. These values are then
input thru a translation interface. Using the interface, i build up
translatable values for the controls as well, where items like radio buttons
and selects are done in the following manner
base_name
lang_1 lang_2 ... lang_n
----------------------------------------------------------------------------------------------------
salutation
Salutation Salut something
base_name.db_value_1 = first option mr
Mister Monsiour
base_name.db_value_2 = second option mrs
Mrs Madam
...
base_name.db_value_n = n option
Then for each option value i have a function that pulls the the correct values
and builds the options list for each control type
Our final step to improve perfomance (note that this is, sadly, ASP / vbscript
) was to take the translation table into an XML application level object to
cache the data since its relatively immutable.
Now when I write this same app in php, I am more likely to skip the caching
portion of this in favor of templating the forms for each language. I would use
a folder for each language.
hth
bastien
> To: php-general@lists.php.net> From: [EMAIL PROTECTED]> Date: Tue, 27 Nov
> 2007 15:18:45 +0000> Subject: [PHP] Re: Newbie asks about multi-lingual
> website strategies> > Jeff Benetti wrote:> > I'm a noob so keep the comments
> to a noob's level please.> > > > I am doing a website and my client wants the
> bulk of the text to be> > bilingual (French and English). The last site I did
> used php and mysql so I> > am getting comfortable with that technology.
> Typically I am using a single> > php file and my menu constantly points to
> the same file with different id> > options example "index.php?id=30" and I
> want to use the same idea to choose> > a language example
> "index.php?lang=fr&id=30". Pretty straight forward for> > many of you folks
> but before I start reinventing the wheel I wondered if> > anyone could offer
> any suggestions. I have a couple of approaches in mind.> > > > 1: Session
> vars, I have never used this but it seems straight forward.> > Drawbacks?> >
> 2: Cookies again not too big a deal, never used cookies either but it> >
> doesn't seem to be mystifying however the fact that the user can turn> >
> cookies off makes me not want to go this route.> > 3: Use the mysql database
> and log each ip address and record the preference> > and maybe the last time
> on the site. I am leaning in this direction because> > I think it is the most
> robust but will it be slow? First I have to get the> > ip then I have to
> check to see if it is in my data base and then get the> > language
> preference. It would be great to have a standardized function that> > I could
> use on all of my sites. I live in a bilingual country (Canada) so> > this
> could be a real selling point for my services.> > > > Any any and all
> comments are welcome, it will be a learning curve no matter> > which route I
> take so a little advice on the best direction pros cons would> > be great.> >
> > > And of course knowing that I will have many many thousands of people on
> my> > site (hee hee) which option will perform best once I start
> accumulating> > vistors. That's one problem I see with the mysql solution, I
> think it may> > start to be slow unless I start purging vistors who have not
> shown up in a> > while or limit the number of entries.> > > First of all you
> can use the browser supplied language preferences (if> available) to try and
> guess the users preferred language. It should be> obvious from phpinfo() and
> a half decent browser what vars you need to> inspect ($_SERVER['HTTP_LANG']
> or something like that - can't remember> of hand!).> > You could do soemthing
> like:> 1. Check session for lang preference and use it.> 2. Regardless of the
> result of 1, check GET for a preference and store> in session if present and
> use it.> 3. If neither 1 nor 2 has any preference, use the browser supplied>
> preference.> 4. If nothing else, use a hard coded default.> > > > OK, that
> selection taken care of :)> > > For hard coded strings in your PHP code use
> Gettext and bind to standard> your catalog files and use the language choice
> from the above algorithm.> xgettext can extract strings from PHP files easily
> enough. You just have> to make sure you write in your default language and do
> not use variable> substition as you normally would in PHP.> > e.g.> BAD:>
> echo gettext("Hello $user, welcome to my site");> > GOOD:>
> printf(gettext("Hello %s, welcome to my site"), $user);> > printf and sprintf
> are your friend!!> > > If you use modules, be sure to write all your strings
> with a gettext> domain. It's a pain to go back and do this later!!!> > > I'd
> recommend looking at the gallery2 codebase for a nice example of> well
> internationalised and modular string handling.> > > > As for the database
> contained strings there are multiple approaches here.> > You could have a
> general linking structure that uses tables to store the> different strings.
> This is simple conceptually but also a pain to> implement in terms of SQL
> code.> > I've actually created a set of custom functions for MySQL (in C)
> which> pack and extract multilingual content into text fields. It's a bit of
> a> pain in terms of standards complient SQL but it makes coding much
> simpler.> > I would do e.g. "INSERT INTO table (mystring)
> VALUES(LANG_PACK('en',> 'Hello', 'fr', 'Bonjour'));> > Then> SELECT
> LANG_EXTRACT(mystring) FROM table;> ("Hello" - defaults to first string)> of>
> SELECT LANG_EXTRACT(mystring, 'de', 'fr') FROM table;> ('Bonjour' - can't
> find de but finds fr).> > I've wrapped up the calls to LANG_EXTRACT in the
> SQL to use the user's> language preference automatically which works quite
> well.> > There are lots of solutions here and if I were to think about it
> again> I'd maybe reconsider what I've done. It's convenient in some ways but>
> not so in others!> > Hope this gives food for thought.> > Col> > -- > PHP
> General Mailing List (http://www.php.net/)> To unsubscribe, visit:
> http://www.php.net/unsub.php>
_________________________________________________________________
Have fun while connecting on Messenger! Click here to learn more.
http://entertainment.sympatico.msn.ca/WindowsLiveMessenger
