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.