[development] Drupal and i18n, the holy grail?

[Bèr Kessels]

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.

However, for the configuration translation, we will need one single solution. 

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.

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.
-- 
[ End user Drupal services and hosting | Sympal.nl ]

Gebruik geen CVS, tenzij je zeker van je zaak bent:
 http://help.sympal.nl/gebruik_geen_cvs_tenzij_je_zeker_van_je_zaak_bent