Jochem Maas wrote:
1. Storing multilingual data in a database. Possible solutions I know:
a. many tables, one per each supported language, e.g. news_en, news_de.
b. one table having many columns with translations, e.g. (id, date, text_en,
text_de)
We use MySQL 4.1 as a back-end.what about 1 table, 3 columns: translatekey (varchar) - string to translate lang - lang code/id/name translation (varchar/text) - translated string
I have used c) for a long time but as of recently I've become a supporter of b). Reasoning: firstly, select-s are fastest this way due to lower number of joins needed and secondly, MySQL as of 4.1 now supports different collations for different columns. I use Unicode for all the data but sorting order and such still depends on collation used.
2. Multilingual HTML templates, possible solutions: a. one generic template for everything, one per each language, like contents_en.tpl.html, contents_de.tpl.html b. many localized templates for each page, e.g news_en.tpl.html, news_de.tpl.html Template engine is Smarty.using Smarty I sometimes assign an assoc array of translated strings: $Lang['yes'] = 'yessiree'; $Lang['no'] = 'nocando'; then in Smarty: <div class="LangExample"> 'yes' is {$Lang.yes}, 'no' is {$Lang.no} </div>
I completely agree with Jochem there. Unless your base layout is different for each language involved, you should use common templates for all languages and have localized texts displayed via {$lang.yes} and similar. Clean and swift. And you can have your localized texts stored in whatever format you wish - database, XML or PHP variable files.
best in terms of SEO.3. Storing current language variable, possible solutions: a. inside the URL like /en/news/
And therefore it is best used on informative sites that are mainly visited via public side. Keeping the current language inside the URL means that the customers can easily copy-paste links while keeping the language selected. If the site is intended for internal use (intranet, CRM, ERP etc) you might opt for storing the language in a session instead.
b. using cookieshandy for presistence.
I would personally use it as an addition to a) and c). Upon the first visit to a site (session getting set up) the language is retrieved from the cookie. Later on either session or URL are used.
c. using sessionsprovides cleaner URLS.
And I would use this solution on sites intended for internal use, as stated above.
HTH, Allan Kolk
-- PHP Internationalization Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php