Re: [PHP-I18N] Multilingual Web application - how to?

[Allan Kolk]

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.

3. Storing current language variable, possible solutions:
a. inside the URL like /en/news/
best in terms of SEO.
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 cookies
handy 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 sessions
provides 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