[development] Drupal and i18n, the holy grail?

[Jose A. Reyero]

Bèr Kessels wrote:

>The interface: And a good default?
>
>We are collecting some great ideas here, and i expect actual work and actual 
>code too. :)
>
>One particular issue, though is still unclear.  We already discussed the three 
>areas of translation: interface, configuration, content.
>
>The interface for the content translation is highly dictated by the workflow, 
>so I doubt we can say something good about it. Two forms next to eacother for 
>two languages? Tabs? fields under eachother? All possible solutions, but none 
>can be *the* solution.
>  
>
Agree. That's why we need some basic support in core but then swappable
modules that can use that mechanism and provide whatever interface
people likes.

>However, for the configuration translation, we will need one single solution. 
>
>  
>
Sure. However, the configuration interface is only for site
Administrators, and I think not for everyday use.
So this one only has to be functional and be somehow consistent with the
case when we have a single language.

>Untill today, I tried three interface ideas, both have their pros and cons. 
>1) simply use the active language for generating the current object.
>if you add a menu-entry "About us", with the active language being "English" 
>then you will create the english menu item. If the language is "German" you 
>will add an entry that you call "Über uns" to the german copy of the menu[1]
>Pro: quite clear for end users. in your theme or a block You can even add a 
>Visual thing like a big flag of the current language.
>Con: Connection between Menuitem-german and menu-item English is virtually 
>impossible. Meaning that it is very hard (if not impossible) to track that 
>"Über uns" is the translation of "About us".
>BTW: this is virtually the same as adding tabs!
>
>2) dedicated interface. Somwhere else, under admin/translations/ for examlpe 
>you can search for elements abnd tanslate them.
>Pro: Simple, effective. 
>Con: Our objects are not consistent. This will therefor never work completely. 
>There will always be objects (from contribs) that do not fit in this 
>interface.
>
>3) duplicated interface. I did this trough theme functions; we can now do it 
>with form_alter: just add a second (and their and fourth and so on, one for 
>each language) field for each element that wants to be translated. 
>Con: severe hacking required. Hard to track what watns to be translated and 
>what not. Very hard to expand beyond core. 
>Pro: simple interface. 
>
>The current i18n uses some combination of 2 and 1, I, and my clients found 
>this very unuserfreindly. However, the code was written, then, to minimise 
>core changes, which require these often a bit odd interfaces.
>  
>
Yes. It is unuserfriendly or even user unfriendly but it just a) works
b) needed no core patches

For a good inteface, in the long term I'd go for (3) because of a number
of reasons:
- I think it provides the best usability -a variable could be changed
for every language in a single page and even if there are too many
languages, translations can be hidden with that nice javascript...
- I don't think patches would be that big, as we'd need only some Forms
API 'magic' and the variable management functions to be aware of this
multiplicity.

However it doesn't mean this nice interface needs to be implemented in
core, just the 'variable management part'.
So we could provide the hidden functionality -multilingual variables,
menus, etc..- with some simple -as for coding- way to manage it, that
could be option (1) and then if you want a nice colorful interface some
contrib modules can be available. Same for translations, translation
workflow, etc...

>Bèr
>
>[1] Note that copy does not yet have to be a copy. We are still discussing and 
>brainstorming about that in another thread.
>  
>