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



Reply via email to