Handling content in multiple languages.

Quote from: TimGS at May 05, 2012, 06:39 PM

Do you envisage the code itself still being in the form of a module and plugin?

Do you mean whether your addition is going to be implemented in the core or left as an addon? I don't know, I'd personally like it to be in the core as I use multilanguage a lot, others may think differently.

Do you mean snippet-specific text e.g. a search snippet would have 'search results' ?

Many snippets have language parameters e.g. Ditto, so a call could be of the form [!Ditto? &language=`[:language:]` ... ... ... !] Note the new placeholder delimiters for [:language:] - as far as I can see such a language placeholder does not correspond to any existing placeholder type. This placeholder probably should be one of the first things replaced by parseDocumentSource().

Future extras could just access $_SESSION['language'] directly, or probably more sensibly via a new property e.g. $modx->language.

This way, If a prevnextjump snippet had a placeholder [+next+] then those placeholders can remain as they are, and the snippet justs replaces them with the correct text as according to the language.

Yes, this should be ok!

Chunks and templates

If I have some non-content managed text, I'd prefer not to have to jump between template/chunk and a separate editing table. Ideally then, I'd like to have something like:

[:en|Good Day|fr|Bonjour|de|Guten Tag:]

This may get a bit unwieldy if you have lots of languages, in which case your suggestion becomes more practical. I'm inclined to suggest both are implemented, and subject to any other comments and suggestions may well do that as the next step.

-- Tim.

I agree, there are some very small websites where there is no need to use an external module for editing the text, but for big websites it becomes tricky to find and translate all.

Hi Susan,

I have taken a look at YAMS.

My implementation does require a few changes to the core as detailed above. However in return existing functionality works automatically with new languages as long as db table names are generated via $modx->getFullTablename(), which is true for the core and in most Extras (it should be all, but some people bypass the API). This is the strength of my implementation - it does not only not break existing code, but automatically has existing code use the translations.

Sure, such as http://rtfm.modx.com/pages/viewpage.action?pageId=13205618 can make Ditto work with YAMS, but if every snippet needs extra code or extra configuration its hardly an out of the box solution. Without using views as I have done to map columns so that they appear to be the existing db fields i.e. the same field names, appearing to be in the same place in the db, most snippets can not be expected to work out of the box - YAMS in using TVs makes the db structure for the translations fundamentally different to the 'normal' fields in modx_site_content. Even translation TVs is done by making differently names TVs (which is unavoidable with the present core).

The only changes to existing Extras that my own solution could require is where search snippets need to access all languages - but these snippets will need changing in any implementation.

As a bonus, in my own solution developers are not presented with a mass of new TVs - it all should work seamlessly as if both modx_site_content fields and TVs magically exist in different languages without clutter. I'm also not presenting developers with a complex UI. It took me a few head scratches while I wondered why YAMS wasn't 'working' - but I hadn't found the option to switch on multilingual functionality per template. Similarly it wouldn't 'work' out of the box with my site in subdirectory e.g. localhost/yams. It was quicker setting up a virtualhost i.e. yams.localhost than finding the option to enable this (which should be automatic anyway). Basically, I found the UI too complex - I certainly wouldn't expect a client to use it.

Probably a minor point for most, but caching with my own implementation will be more efficient as each language has separate cache entry per page. If then you have five languages, YAMS fetches five times more information than it needs from the cache.

-- Tim.

How does editing each language work? Does each language have its own page that has to be edited? The clients I've set up YAMS for love having all languages edited in the same place.

PMS was working on a beta version when he dropped out of development, and it had some nice features but is buggy about only saving/loading its configuration file in latin-1, resulting in garbage configuration values for non-latin-1 charsets. I never was able to figure out why it was doing that.

Install it (on a fresh clean modx install) and see. Add in my sample db dump and you'll have at least one page to edit with IIRC three languages.

Basically at the top of each manager page you have links to change the current language. They could be styled as tabs if preferred. When editing documents/resources this just changes the view to a different language.

See also the front end (which in the absence of front end code shows the same language as the backend) and also /assets/cache.

-- Tim.

PS. I'll set up a demo site later on.

This is going to be great!

Development code now at https://github.com/sjstoelting/evolution/tree/1.1.multilingual

A very basic SQL site dump is included in the root as an example.

-- Tim.

@Tim, I have added icons for switching the language in the manager. See demo.

The HTML:


The CSS:

I have changed the code, now it is like this:
[ed. note: microcipcip last edited this post 11 years, 11 months ago.]

Branch now updated at https://github.com/sjstoelting/evolution/commits/1.1.multilingual . Now includes changes to the install script so that the required plugins/modules/snippets are installed if you require them.

Note that by default no columns are translated - go to the Language tab in Tools->Config to select which columns in modx_site_content to translate, and whether or not to translate TVs.

-- Tim.