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@xxxxxxxxxxxxx> From: gmane@xxxxxxxxxxxxxx> Date: Tue, 27 Nov 2007 15:18:45 +0000> Subject: 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