Multi-language in Revolution

Hi there,
I was wondering how to achieve multi-language content in Revolution. In the past, I was one of the contributors for the multi-language site in 0.9.5. I think that we can achieve multi-language front-ends by using the same techniques, but I am not able to understand benefits and drawbacks of these techniques in Revolution.

1) each language in a different "directory" of resources, webpages (and the whole "directory" structure of the website) are duplicated accross these directories; some scripts handle the language switching (session, cookies or whatever); the main benefit is that it is easy to create this structure, but difficult to maintain (e.g., copies of webpages results in duplicated information, that is usually better to avoid)... moreover, it is not easy to maintain pages that do not have a translation in one of the language (fallback temporarly to a default language?)
2) use different template variables to keep the different language contents: this is easy to create and maintain (there is actually only ONE page for each content, that contains different translations), I’m not sure of the drawbacks of this solution
3) what are contexes? can they help with multi-languages (I read a previous message in this forum that seemed to assume that contexes can be used for multi-language)

Thanks! (and Merry (late) Christmas)

Hello MadMage,

Did you took http://svn.modxcms.com/docs/display/revolution/Internationalization" target="_blank" rel="nofollow">a look at lexicons?

Quote from: lossendae at Dec 26, 2009, 02:25 PM

Hello MadMage,

Did you took http://svn.modxcms.com/docs/display/revolution/Internationalization" target="_blank" rel="nofollow">a look at lexicons?

It doesn’t seem to fit the requirement of a multi-language CONTENT: lexicons seems to be more related to snippets/plugins/backend translations.
Since lexicon entries are indexed by key, the only way to use this feature for multi-language content is to have a different key for each webpage, but website content pages are not supposed to be in lexicons, but in resources. Am I right?

Quote from: madmage at Dec 27, 2009, 04:57 AM

It doesn’t seem to fit the requirement of a multi-language CONTENT: lexicons seems to be more related to snippets/plugins/backend translations.
Since lexicon entries are indexed by key, the only way to use this feature for multi-language content is to have a different key for each webpage, but website content pages are not supposed to be in lexicons, but in resources. Am I right?

You are partially right; the mode of thought you subscribe to says that each Resource should have a translated version stored somewhere in the database.

However, this is only one method of i18n, and tends to create problems with URL writing.

For example, let’s say you’re editing mysite.com/news/article.html. You want to have an EN, FR and ES translation of that page. By your mode, you would simply load the Resource, and via dropdown toggle between the different languages.

However, in principle, this is much, much more complex. A few problems that occur with your method:

- How is the URL written for each different language? Is it the same URL? If so, how do users get straight to the FR content? Or the ES content? If it’s subdomains, how is that rewritten or setup? This is usually best solved by having subfolders; ie, mysite.com/en, mysite.com/fr. Which would lend to doing separate Resources - not one Resource.

- In your method, how would Template Variables, Chunks, Snippets, and more, be translated? What about Chunks nested in a Snippet nested in a TV? How would the language selection persist? Would TV edits need to be i18n aware? Would all snippets need i18n support? This adds a _lot_ of overhead and development to 3rd party extras.

So far we’ve decided on the string-based i18n solution, which states that you would do your i18n editing via Lexicon Topics (or collections of Lexicon Entries, rather), and then plug the Lexicon Tags into your resources. Then you can load the language however you want - via subdomain or folder - via a TV, snippet or plugin. You decide the method. This method allowed the least resistance, as it wont cause URL conflicts, will avoid multi-lang editing issues for TVs/Chunks/Snippets and nested tags, and solves the 3rd party extras problem.

We’re open to other ideas, but the route we’e chosen seems to have the least problems.

Quote from: splittingred at Dec 27, 2009, 05:46 PM

(snip)

- How is the URL written for each different language? Is it the same URL? If so, how do users get straight to the FR content? Or the ES content? If it’s subdomains, how is that rewritten or setup? This is usually best solved by having subfolders; ie, mysite.com/en, mysite.com/fr. Which would lend to doing separate Resources - not one Resource.

Ok, you are right with the URL, although cookies can be useful here: a resource is a webpage content, that means that if I am looking for a webpage that is about the moon, I want a webpage about the moon, the language is just a matter of presenting that content. The presentation should be a choice of the user.

Quote from: splittingred at Dec 27, 2009, 05:46 PM

- In your method, how would Template Variables, Chunks, Snippets, and more, be translated? What about Chunks nested in a Snippet nested in a TV? How would the language selection persist? Would TV edits need to be i18n aware? Would all snippets need i18n support? This adds a _lot_ of overhead and development to 3rd party extras.

I do not know exactly how this work in other environments, but this seems to me to be related to something else, rather than multi-language content: pieces of software (snippets, TV, etc.) that need a translation of their textual messages. For this, I think that the lexicon stuff is the best choice (that is a variant of the well-known "gettext" solution).

However, I am talking about multi-language resources, rather than snippets, TV, etc.

Quote from: splittingred at Dec 27, 2009, 05:46 PM

So far we’ve decided on the string-based i18n solution, which states that you would do your i18n editing via Lexicon Topics (or collections of Lexicon Entries, rather), and then plug the Lexicon Tags into your resources. Then you can load the language however you want - via subdomain or folder - via a TV, snippet or plugin. You decide the method. This method allowed the least resistance, as it wont cause URL conflicts, will avoid multi-lang editing issues for TVs/Chunks/Snippets and nested tags, and solves the 3rd party extras problem.

We’re open to other ideas, but the route we’e chosen seems to have the least problems.

I am not sure to have understood how you propose to do the multi-language content. What should be Lexicon Topics in my case? If I have 100 articles in one language, do you propose to have 100 lexicon topics or 100 lexicon tags or...?

Quote from: madmage at Dec 28, 2009, 08:08 AM

Ok, you are right with the URL, although cookies can be useful here: a resource is a webpage content, that means that if I am looking for a webpage that is about the moon, I want a webpage about the moon, the language is just a matter of presenting that content. The presentation should be a choice of the user.

Right; it should be a choice - but making i18n Resources *a part of the core* means that that presentation is predetermined by the core, rather than the user’s implementation.

Now, Revo as it stands does actually allow you to do i18n Resources should you want - you’d have to do some plugin coding, but I could see ways it could be done.

Quote from: splittingred at Dec 27, 2009, 05:46 PM

I do not know exactly how this work in other environments, but this seems to me to be related to something else, rather than multi-language content: pieces of software (snippets, TV, etc.) that need a translation of their textual messages. For this, I think that the lexicon stuff is the best choice (that is a variant of the well-known "gettext" solution).
However, I am talking about multi-language resources, rather than snippets, TV, etc.

Right; Resources are linked to TVs and Chunks; therefore, TVs would need to be i18n-aware, and so would Chunks (you’d need to have separate Chunk data stored for each language.

This isn’t available in 2.0. We’ll look into it for 2.1.

Quote from: splittingred at Dec 27, 2009, 05:46 PM

I am not sure to have understood how you propose to do the multi-language content. What should be Lexicon Topics in my case? If I have 100 articles in one language, do you propose to have 100 lexicon topics or 100 lexicon tags or...?

Whatever you want; you can put all your articles in one topic, or per-article. Up to you.

Quote from: splittingred at Dec 27, 2009, 05:46 PM

I am not sure to have understood how you propose to do the multi-language content. What should be Lexicon Topics in my case? If I have 100 articles in one language, do you propose to have 100 lexicon topics or 100 lexicon tags or...?

Whatever you want; you can put all your articles in one topic, or per-article. Up to you.

It’s not so easy to maintain articles/resources using the Lexicon Topics, is it?

Just an idea: How about a plugin that creates resources between different language context? Having each resource in a context, one can use the full power of resources (including independent aliases). The only issue I see is crosslinking to the same resource in an other context, but that could be handled by the plugin as well.

When a new resource is created or published in the main lang context, it could duplicate and place it unpublished into each language context. The administrator of each context would then see a new document that he has to translate and publish.

I am not sure what event would be suitable. Maybe OnDocPublished?
Is there OnDocCreate?

Additionally it could create a reference id to to the original resource (id in a tv) for cross-links between context. i.e. find document with origin "xy" in context "de"

OnContextCreate it could duplicate all resources from the main context, marked as unpublished and copy it to the new created context.

What do you think?

Quote from: eerne at Jan 01, 2010, 07:06 AM

Just an idea: How about a plugin that creates resources between different language context? Having each resource in a context, one can use the full power of resources (including independent aliases). The only issue I see is crosslinking to the same resource in an other context, but that could be handled by the plugin as well.

When a new resource is created or published in the main lang context, it could duplicate and place it unpublished into each language context. The administrator of each context would then see a new document that he has to translate and publish.

I am not sure what event would be suitable. Maybe OnDocPublished?
Is there OnDocCreate?

Additionally it could create a reference id to to the original resource (id in a tv) for cross-links between context. i.e. find document with origin "xy" in context "de"

OnContextCreate it could duplicate all resources from the main context, marked as unpublished and copy it to the new created context.

What do you think?

I think this is a good idea. Actually, one of the "multi-language solutions" for Evo was something similar to this (but the cross-links were manual). I am wondering why we need a different context (I do not know actually what a context in Revo is :-P) and if it could be possible to have automatic crosslinks (e.g., by duplicating the "directory" structure in all the "language" folders, or contexts or whatever, we can guess where the corresponding page is).

hello
if someone will explain further about multi language content that will be helpfull for us
i dint find a best way to do handle multi-lang content in revo
all are talking about multi-lang strings with lexicons and unique Urls for all languages
but can anyone tell how to handle this with content (i mean the content we write in a document)

creating folders for every language is not optimal solution i think
some pages do not exist in all language folders and trslation also a bit hard
presently iam trying with a snippet to switch the language but i dint liked it

from the forum messages i understood we can manage this with contexts but not sure how to do that
may be there will be many ways to handle multi lang content
but there will be a specific way to handle to this in a CMF like joomla component handles with TV like variables
documentation on this will be more helpfull and i guess it is high priority for users like me

Thanks
venu