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