Internationalization in MODx Revolution

Just to the i18n community know, we’ve started documentation on the internationalization process for Revolution, as well as usage:

http://svn.modxcms.com/docs/display/revolution/

Note that the &namespace/&topic properties for Lexicon Tags are is for SVN/beta-2 and onward, beta-2 will be released very shortly, so we felt it apt to go ahead with the docs.

If you have any questions, or would like further documentation on a subject related to i18n in Revo, please let us know here.

Just wanted to say thanks!

It is preferable not to use the ’language’ property for every tag should you be changing languages; this is best done through a System or Context Setting for the entire site or context. The best option is different contexts for each language. But again, MODx leaves you with the preference.
Lexicons in Code

Using lexicons in code is fairly simple; first off you’ll want to make sure the modLexicon class is loaded by instantiating it as a service:
view sourceprint?
1.$modx->getService(’lexicon’,’modLexicon’);

Then we’ll want to load the Topic using the load() method.
modLexicon::load()

The syntax for the modLexicon::load method is pretty simple:
view sourceprint?
1.$modx->lexicon->load(’topicname’);

The load() function supports Namespace-specific loading. So, say you had a Lexicon Topic named ’default’ in a Namespace called ’school’. You’d simply load it like so:
view sourceprint?
1.$modx->lexicon->load(’school:default’);

This would load the ’default’ Topic in the ’school’ Namespace. If the Namespace is not specified, it defaults to ’core’, which is the default Namespace for the MODx Revolution backend.

The load() function also takes an infinite number of parameters; each parameter loads a separate Topic. Example:
view sourceprint?
1.$modx->lexicon->load(’chunk’,’user’,’school:playground’);

This would load 3 Topics: ’chunk’, ’user’, and the ’playground’ Topic from the ’school’ Namespace.

Furthermore, the load parameter supports language-specific loading, should you want to override the default language that is being loaded (which defaults to the current value of $this->modx->cultureKey, which is set differently depending on the Context loaded, and can be set via Settings), you could load it like so:
view sourceprint?
1.$modx->lexicon->load(’es:school:playground’);

This would load the Spanish version of the ’playground’ Topic for the ’school’ Namespace. Fun, huh?
modX::lexicon()

Now we can use the lexicon() method on the MODx object to get our Entry with key ’school.basketball’:
view sourceprint?
1.$modx->lexicon(’school.basketball’);

-


http://svn.modxcms.com/docs/display/revolution/Internationalization-


I’m super lost with the way one is supposed to handle mutli-lingual sites..

The code in the included excerpt, do we have to place it on the document we create, snippet, chunk, or the template?

I just want to create a site with three languages without having to duplicate all the pages, like I used to do before revolution..

The PHP code in the examples could go in a snippet or plugin. The *tags* in the docs could go in a resource (document), a template, or a chunk.

I’ve been wondering about internationalizing 3PCs. SPForm, for example, has a bunch of language strings that are automatically loaded during the install. At present they are all in English, but I’m wondering what is supposed to happen when there are multiple language files.

Are we assuming that the transport package will load the ones consistent with the manager_language setting? Or that the user will be offered a choice of languages during the install? That seems like asking a lot from component developers and the internationalization docs are silent on this topic as far as I can tell.

Otherwise, though, it seems like the user is going to have to manually load the correct language strings with "import lexicon" for every 3PC that uses language strings. That doesn’t seem good either.

Am I missing something?

You can distribute your add-ons as transport packages with as many translations as you want included, and you can even add options to the install to only install specific ones (up to you as component packager). You can even distribute the translations as separate transport packages; this is how I expect to distribute translations for core so that releases are not dependent on completion of particular translations that are included in core (the current situation with Evo).

I hadn’t thought of releasing a language pack as a separate transort package. That would make life a lot easier for everyone.

The only down side I see is that you might have to reinstall the language pack after updating the component.

Quote from: BobRay at Aug 28, 2009, 03:46 PM

I hadn’t thought of releasing a language pack as a separate transort package. That would make life a lot easier for everyone.

The only down side I see is that you might have to reinstall the language pack after updating the component.

Or install an updated version of the language pack, if necessary. tbh, devs can do it either way - package in the lang strings all in the package, a la Evo-style, or do separate language transport packages for the package itself. It’s up to them.

How is it possible to change the Language of the Lexicon.
Say a Visitor wants to changes the language of the entire website by a language chooser from EN to DE.

I’m just asking:

Is this document useful also for ModX Revolution: http://wiki.modxcms.com/index.php/Make_Multi_Lingual_Site