Multi-language in Revolution

Maybe a variation of YAMS would be possible for REvo....??

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 believe this would be a great idea.Fist you would have to define the languages needed ( eg. English -default and Spanish -extra ) in the system settings and after that each time you generate a new document, there will be an extra tab with the spanish definitions( Create /edit document in Spanish - the title,long title,content ,TVs )

may be a component similar to joomfish for joomla will be more helpfull

all these questions here remained unanswered...

i would really love to see a tutorial of some best-practices using the lexicon-solution, since this seems to be the suggested method of the core-devolopers.

but everything is still very foggy...

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.

Being based in Hong Kong, we quite often build multi-lingual sites. Although the above statement is an ideal, I’ve found that it’s significantly more practical to have one resource per language (using contexts to separate sitemaps). This has come into conversation for us recently over and over. I don’t disagree with the need to cater to the ’ideal’ of the statement above, but I will present some practicality issues that we have come across:

1) Translations take time. On a live site (i.e. one that has been launched already), it’s usually better to release an article as soon as it is ready, and then release the language variants of it as and when they are received after translation. Translations take time, and if *all* translations are required before an article can be posted online, then you will soon feel the effects of a bottleneck, and rather than naturally releasing content onto your site, you end up batch-releasing it and effectively instantly burying your content (or, you could unnaturally stage the release of the content, thereby losing time).

2) If you have comment threads, then they should be language specific - translations aren’t always made word for word literally and so can provoke a very different response for readers in different languages & cultures. Essentially, a comment made on a resource in Chinese does not necessarily relate to the equivalent resource in English.

3) In 99.9% of cases, users toggle to their preferred language upon entrance to the site. E.g - As an Englishman in Hong Kong, whenever I land on a Chinese website, I’ll look immediately for the English button and click it to be taken to the English homepage. I won’t navigate through the site three levels deep and then toggle to English, because I’d already be lost. Although the homepage won’t always be the entrance path to a site (e.g. an inner page linked from google), in a majority of cases, if google can index a site correctly then it will find you a result in the language you searched for it in.

4) Depending on the kind of site you’re running, the content of the site in two different languages may actually be different - you may have different editors who are pursuing different ways of writing, or a different marketing strategy for different languages etc. If that’s the case, then your content will be very different, and you’ll need a different sitemap - language targeted contexts is the way to go.

Naturally, as a developer or as a client, the expected behavior when playing with a site in development is that by toggling language, you’ll simply toggle the resource content. But I suggest that that is because we’re developing, proofreading, and hunting for holes in the site - not because we are behaving like normal end users.

For all the above reasons, I would suggest that if you really do need to have translated resources and interlink them with their language variants, you *could* achieve the best of both worlds by using language targeted contexts, and tying resources together with TVs to define the ’siblings’ by ID. However, this wouldn’t be very scalable beyond two (or pushing it at three) languages because of all the combinations of data entry required, and it’s certainly not very elegant.

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.

I can see a need for this - but I do think it is rare. Wikipedia would be a good example of a site that would benefit from this, where all my above points are irrelevant. I’d love to see if there are thoughts for a tidy solution for it, but I imagine there’s only a complex one.

On a side note - we are working on a series of tutorials for revolution and will be touching on lexicons for those interested. I will post back here when the link is ready in a couple of weeks.

Thanks.

Quote from: hk_modx at Jul 08, 2010, 01:04 PM

For all the above reasons, I would suggest that if you really do need to have translated resources and interlink them with their language variants, you *could* achieve the best of both worlds by using language targeted contexts, and tying resources together with TVs to define the ’siblings’ by ID. However, this wouldn’t be very scalable beyond two (or pushing it at three) languages because of all the combinations of data entry required, and it’s certainly not very elegant.

I think having context and lexicon for each language will be most flexible and totally agree to all the points you made.

I’m not a big fan of interlink between language variants and am not suggesting to do so, but technically one id to the main context should be enough. A resource could then pull documents with the same main-id from each context and would get all siblings for each lang.

This id reference to the main-context could also be used as fallback if the page hasn’t been translated (just an idea).

Quote from: eerne at Jul 09, 2010, 07:43 AM

I’m not a big fan of interlink between language variants and am not suggesting to do so, but technically one id to the main context should be enough. A resource could then pull documents with the same main-id from each context and would get all siblings for each lang.
This id reference to the main-context could also be used as fallback if the page hasn’t been translated (just an idea).

Actually it happens a lot (to me, at least) to search for something and find it in some blog in a different language. I am really grateful when finding the button for english and not having to go to the top of the site and to search for a language that I understand.

If you want to consider that that the translations are in fact different sites, then it’s OK to have different resources. Although in this case I would choose two different domains. But if you want to make, let’s say, a multilingual blog, juggling with multiple resources and lexicon strings is far from ideal.

I see two needs here:
1. one includes the translations of the interface - templates, snippets, chunks, and so on. These translations are reusable so it makes perfect sense to use lexicons.
2. the other one include multi-language content - the resources’ content, which is certainly not reusable (at least this is what Google tells you ). It goes from different sites, where the content has vague connections between translations, to multi-lingual blogs, where ideally the content is translated ad-literam. I don’t see any use for lexicon here. But, then again, I’m not very good at it.

The main problem, as I see it, is the interface.
The actual lexicon management is just listing some variables. Not very practical, as the purpose of it would be translating some strings instead of redefining variables. It would make more sense to have two "Value" columns, one for a language you choose as a reference and another one to work on. Also, I couldn’t find a way to define new lexicon entries from the Lexicon Management. I mean, I create a new entry in the lexicon file and then I go to the Lexicon Manager to override it. Why bother? I like files more, anyway.
The same goes for resources. A translation interface would have to give a reference beside the translation you’re working on. Although I understand that most of the sites will not be multi-lingual, so the need for such an interface is not great.

I think that the Lexicon Management default interface can be improved towards its purpose. And I think I’ll have to make my own resource content interface. I just have to learn to alter the Manager interface.

Also, the "context" concept is not quite what I hoped for, because one cannot "apply" contexts to resources. One resource is tied to one context. Or maybe there is something else working that way? I saw "culture" somewhere here, but my searches were fruitless.

Anyway...

We shall go on to the end.
We shall fight in France,
We shall fight on the seas and oceans,
We shall fight with GROWING confidence and GROWING strength in the air.
We shall defend our island whatever the cost may be.
We shall fight on beaches, we shall fight on the landing grounds,
We shall fight in the fields and in the streets.
We shall fight in the hills,
We shall never surrender.

Best regards.

Oh, and don’t beat me. I’m a fan. I keep wrestling MODx because I know it can be done (whatever is it): D.

*Push*

Are there already any solutions for this "problem" at the moment?
Have you heard something from the yams crew if they will make a pakage for revo?

Greetza

Yes, it would be simple!

For all who haven’t seen, there is now the babel plugin 1.1 rc1 by saerni

http://modxcms.com/extras/package/757

(which approaches to solve all issues: adding translation button to manager, automatically crosslinking between resources in the frontend as well as in the manager, also has ability to share specified tv’s)