Multi-language site best practices

Wendy thanks for the sharp eye. I also added some more from you there.

Thanks for all. I see that as soon as possible.
A little question : when the next release is planned ? Thanks

The next release is planned for as soon as possible. I’d really really like to get it out this month in fact.

Some things to consider when creating multi-language sites outside of localization that might need logic/implementation tweaks:

• All the "main page" meta-data (page-title, alias, etc.)
• Keyword metadata.
• All the TVs associated with a page
• Number/Date formats
• Manager/System Configuration language setting
• Chunks/Snippets/Plugins/Modules

Sorry but I can’t read all messages. I’m french and sometimes english is a little hard for me. And I do not have enough time to translate all. So, I prefer continue this post to talk about my experience.

* All the "main page" meta-data (page-title, alias, etc.)
* Keyword metadata.
* All the TVs associated with a page
* Number/Date formats
* Manager/System Configuration language setting
* Chunks/Snippets/Plugins/Modules

I add "Templates"

Is it possible to make it "easly" in the modx core but it is long.

I propose all that follows, based on my experience. This way had be choiced after many tests with several possibilities of implementation (MySQL performances and simplicity of implementation). There are all solutions but I think is good compromise.


Use a session variable to store the language used by the user ($_SESSION[’lang’])

This variable permit to retrieve easily paths, tables, etc... (Thanks to see below).

Use 1 database (is the better solution) and 1 table by language (only for content, metatag, keywords... : all tables that contains localized string). Also, it is necessary to separate localized tables and setting tables. Tables wich contain localized contents must have reference at the language. Exemple : site_content_en, site_content_en.
This avoid to make heavy one table. Requests in database are faster on little table than bigger.
An other possiblity is to add fields to store reference to the language but request is longer and more complicated (need to make condition for select rows instead (1st solution) select directly in the good table)

Use language files to display messages and strings of the interface.

Note: Settings which are displayed in table like key / value can’t be localized easly. I think there are oonoly for administrator, sor they can be unlocalized. A solution is to use language file to display parameters but it’s need a link between parameter and string. I think is too heavy.

Use 2 files for each languages for Modx (not ressources) : it is not necessary to load all language strings if users are only on the frontend or on the backend (actually, I don’t know if english.inc.php are used in front and back).

Use language files for all ressources.
Templates must be use tag to replace after by localized string.

Each language files can be found easly with the session variable. I think the better solution is use the language identifier in the name of the file.

A modx core function could be added to load automatically language file with a simple call in the ressource. This core function can be automatically load 2 languages : in first the modx default language and in second the current language (thanks to session variable ). If the required string is not in the second file, the first will be automatically used instead (language files must used PHP array for this).

Use setlocale() to display date, monetary... correctly. It can be automatized with the session variable.

TV would make called to string in the database. All string can be used because TV are created by users. A file to store string is to hard to mantain and difficult to consult. To simplify the administration of this custom string, I think a table by language is required.

All ressources must be reconsider : final user can want to display only document in one language, without indicate that a version exists in an other language. Is an fats idea.. I don’t think more about this...

Default charset must be UTF-8 because many language use accented characters or other "special" characters.

Some functions must be added in modx core. Now, I think only to a function to format date (using strftime and utf8_encode). I’m sure there are other function which required this treatment. A list off this functions should be great...

To manage and display easly the different language, a table must be created with the name of the language (localized so that everybody can retrieve easly their language), string for set_locale (fr_FR, en_EN...) (with this, this is not obligatory to add set_locale in language file). Also, it can permit to automize addition of language.

To display content with multi language, a great functionnality is to indicate if traduction exists. For this goal, the key of localized table must be same in all calized table. To simplify it in the backend, a good way is to create a document in one language, and create after a 2nd document with a function "Translate" which get the table id and display the first document (read only mode). Also, all translated documents will have the same id. An other table must be created to count translation for optimize request, and still one to store every document id with every language id. With the MySQL index, as this tables contains only id, requests are very fast.

A structure of directory must be created to store language files. I think that :
root
|_ manager
| |_ lang
| |_ frontend
| | |_ modx.en.inc.php
| | |_ modx.fr.inc.php
| | |_ modx.it.inc.php
| |
| |_ backend
| |_ modx.en.inc.php
| |_ modx.fr.inc.php
| |_ modx.it.inc.php
|_ assets
| |_ snippets
| | |_ newslisting
| | | |_ php
| | | |_ lang
| | | |_ language.en.inc.php
| | | |_ language.fr.inc.php
| | | |_ language.it.inc.php
| | |
| | |_ newsfeed
| | |_ php
| | |_ lang
| | |_ language.en.inc.php
| | |_ language.fr.inc.php
| | |_ language.it.inc.php
| |
| |_ plugins
| |_ xxxx
| | |_ php
| | |_ lang
| | |_ language.en.inc.php
| | |_ language.fr.inc.php
| | |_ language.it.inc.php

Note : the project that I developped has 2 languages (french and englis) for the interface (frontend and backend) and documents can be write in each language needed (and configured in the database) (to my knowledge, if no modification were made, Greek, Czech, Dutsh, Italian, Portuguese and Spanish).

A great possiblity of modx should be parsed all ressources (I know that is not easy) and display in the manager all ressources which are not translate in user language : it permits to avoid to display english (if user language does not exist).

Only core ressources/modx messages can be hardcoded than "Can’t load default language" or "Can’t found a required file".



I think I have said all that I know. But I don’t sure.
I repeat : it is my view based on my experience.

All comments are welcome.

Thanks everybody for having read all my "english".

A problem I had using only SESSION variables in a multi-language site was that the WebLogin snippet clears the SESSION when the user logs out, so he loses his "language" choice and is sent to the default language page. This can be solved by hacking the weblogin.inc.php file.

Another was a problem with sessions timing out, and on mass-hosting plans there often isn’t a lot you can do about it. I worked out two other solutions, one to use a query string attached to every URL, but that required a lot of hacking of the core and various snippets.

I finally settled on using cookies to maintain the users’s language choice. The problem with that is that the user must have cookies enabled for your site.

Language displayed can be choiced in the user interface if is login else language can detect automatically.
So the language can be stored in variable session even if Weblogin clears all. Is not ?
In PHP there is solution to get the language use by the users but I don’t know how that is work. Probably with HTTP header or maybe with IP.

Query string a solution not very secure. It needs to used it only with not confidential data. Also, it can be a solution for the lang.

Excact for cookies. It can be used if enabled (I think when you set a cookie a boolean is returned). It can be use to store, if retriving language with PHP needs too many lines.

In short, Weblogin should be not cleared all session variables. With PHP, it is possible to get the "lang" of the user based on HTTP header (or IP ?) and to create a variable session with lang displayed (if Weblogin clears all). Cookie can be used to store interface preference for example to avoid treatment with PHP. Query string is great for non confidential data and often oblige user select language at his arrival on the site.


Note : $_SESSION can be store array. So you can use it like this :
$_SESSION[’confidential’][’user’] = $name;
$_SESSION[’not_confidential’][’lang’] = $lang;