[development] Drupal and i18n, the holy grail?
ber at webschuur.com
Sun Feb 26 20:09:08 UTC 2006
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
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
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.
 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:
More information about the development