First of all, i’m not a core developer, but i’m working hard on some areas and use Xaraya extensively. These are my ideas as a developer, theme creator and admin of various Xaraya installs.

I’ve read John Cox and Marcel’s posts and i’m very pleased to see that they think more or less about same thing as me, but I have some additional ideas.

Following John’s idea of using templates to manage all GUI functions and all my recent work to get a full MLS in Xaraya (for gui and content) I would like to propose a very radical idea: split off MLS, at least as we know it today. Yeah! I know, it sounds very radical, but i’ve very good reasons and solutions for all problems I’ve found, and i’ll try to show you how.

Localization of templates

First use of MLS is localization of interface into diferent languages, through xml files and blocklayouts tags.

Is well know that this paradigm slows down the whole system, and the only solution is delete all <xar:ml*>tags</xar:ml*> in templates and translate all strings, usually overriding module templates. But there is a problem. A lot of modules have diferent strings hardcoded in api or user functions, and if you want to have it translated you must use actual xml system.

But, if all display content is going to be rendered with templates, like John proposed, the need of a xml translation file is dead. All translations could be done directly in theme files. Now someone could see some problems:

It’s more work to translators!

No, it’s the same work, even best. My reasons are:

1. If you create a new theme, you must translate all new strings, and the only work you can reuse are modules and core templates translation (if you doesn’t customize it). If you override all module and core templates, you only need to do it once, and reuse in every theme you create.
2. Sometimes is hard to know the context of a translated string, and i think that it’s best to see it in context in order to create best translations.

How to handle more than one locale?

The system simply will load one or another theme depending of the language. It also allows an easy handle or rtl and ltr languages, as well complex sentences structure in languages like chinese, russian, etc…

And i see a lot of advantages:

• Speed boost: less code to work with and cache boost
• Cleaning of a lot of template tags
• Deleting of a core function, with a reduction of complexity in all system.

Localization of content

Ok, now we have deleted MLS from core, but what if we want to have a multilanguage site?. We need an optional MLS module that handles ML options (themes to call, locales avaliables, etc…). Althought it can also be defined in a config xml file

But we’re in the same place… ok, with a speed bost and a complexity reduction, but now we also need a bit more. We need the option to translate content for some modules.

I’ve thought of various options, but i think the best one is to allow it though new MLS module, adding, for example, a structure like <xar:mlvar>$var</xar:mlvar>. It could be done thanks to DD.

Each time a mode is hooked to MLS module, it creates a DD subform object with the same structure of the item it’s hooked. The only need is that the original module has a lang var (like articles).

When system find <xar:mlvar>$var</xar:mlvar> it check current user language and module and DD items, and have various options:

1. If item have translation in current locale, show it.
2. If item have not translation in current locale, doesn’t show it.
3. If item have not translation in current locale, show it in an avaliable locale, following an order defined in MLS module.

… I have a lot of other ideas, but now i have a great headache and i’ll leave it for the second post…

Esta entrada fue publicada el Monday, 5 de December de 2005 a las 2.33 pm. Puede hacer un seguimiento de los comentarios de esta entrada gracias al feed RSS 2.0. Puede dejar un comentario, o enviar un trackback desde su sitio.