Babel or migxmultilang?

How is the actual translated material managed with Lingua?

With Lingua the translated material is handled by the Lexicons. Our process is to make the templates without any hard coded languages and then make a master English dictionary spreadsheet. We then hand the spreadsheet to our translator and then generate the additional language lexicon files.

Our lexicon dictionaries have all the general words like "yes, no, continue, submit, cancel, login, etc" and then the resource itself holds the content and page-specific translations.

In your template you use something like:

Then you can use the lingua.selector snippet on the front-end to change the languages; or pass ?lang=en to the URL to change the linguaCultureKey.

Then for the content translations setup some additional TVs so translations can be edited quickly in the Resource. Something like this can be used for WayFinder or getResources too:

We prefer this method of keeping all the internationalisation on the resource/lexicons rather than how Babel handles it with contexts. I don't agree on using contexts for internationalisation since they're useful for managing multiple websites or mini-sites from within one manager login. Seems like using contexts for multi languages goes against what contexts were created for.

The only current downside with Lingua is all the lexicon strings need to be called uncached, and if a page has more than 10 lexicon strings a speed reduction can be noticed. However, we need language caching on another project so I've been planning a version 2.0 of Lingua with GoldSky to improve this.

with migxMultiLang, every field is translated on the same page, too.
And you don't need any special tag-constructs or output-filters to get the translated field.
migxMultiLang does determine the translated value automatically, it there is a translated value.
Otherwise, there is a fallback to the default - language.

you just need to have

and it gets translated into the current language.
This is working with all pdoTools snippets like pdoResources, pdoMenu, pdoCrumbs and so on and you can add as many languages as you like and it does just work.

switching between languages is also done either with /en/ in the url or with &cultureKey=en, if FURLS are off

lexicon-string translations do of course also just work.

so you would just have



with the coming version language-caching is allready working. [ed. note: Bruno17 last edited this post 10 years, 3 months ago.]

What exactly is required to add another field, for example if I want to make a duplicate of the sample config to add menutitle to the four fields already in the sample config?

currently, you need to do this steps:

create a new MIGX-configuration lets say with name: my_translations
On the configuration 'mml_translations' do 'import/export' and copy the whole thing
On the new configuration 'my_translations' do 'import/export' and paste that copied json-string
Add your fields to the formtabs, for example name of the field: 'mml_menutitle'

don't forget to create a TV with the same name 'mml_menutitle'

and change the configurations in input-options for your 'translations' - TV to:
my_translations,mml_translate

the second configuration (mml_translate) is a php-configuration-file (mml_translate.config.inc.php) which does add the checkboxes 'published' and 'to Translate' to every field
[ed. note: Bruno17 last edited this post 10 years, 3 months ago.]

How to handle the ID numbers? It looks like those must be coordinated between the two configurations?

Which ID numbers are you talking about?
I had nothing to do in addition to the steps above.

Thanks everbody for the comments (I'm the one who started the discussion above). I'm not wrong to say this is a hot topic, so why no put it on the table on a next Modx Event (I don't know when the next one is)? For the moment I still use Babel because I didn't find the proper time to check out any other solution (the hard world of a webdesigner ;-)), but I will for sure check out the alternatives.

It'll definitely be on the MODX Weekend in the Netherlands in August? September? I can't remember now exactly when. If nobody else does it, I will.

I just briefly tried migxMultiLang out and I think the ideas there are really good. I don't like the idea of being forced to use pdoTools, however. What I also really don't like is working in a javascript pop up box. I would prefer if if my clients could write in the original MODX input form, that i can then control with form customization. The feeling of setting it up and the user experience in the backend is for me personally, too far removed from MODX itself.

I haven't built a site with it yet, I have just only installed it and played around. Also, setting up the input form needs to be better explained. It is similar to MIGXdb in that there are lots of options, but not much explanation for how to use it. Few people I think will really use it, partly because of this.

My 2 cents. I will be showing it however at our meetup in Munich tomorrow night.
http://www.meetup.com/modx-meetup-munich/