[development] Drupal and i18n, the holy grail?
ber at webschuur.com
Sat Feb 25 13:56:01 UTC 2006
Or, how to get the i18n project rolling.
online here too http://www.webschuur.com/node/525
First of all we need to recognise that there is no Ultimate i18n solution.
There are many, all depending on the different needs, cases and
So, I really do not believe in a single i18n module. Or in a holy grail.
Therefore I torn the problem apart, and made Lego blocks out of it. That way
the problem becomes rather clear.
On the top level there are a few types of i18n sites:
1 Mixed content. Sometimes I blog in English, sometimes in Dutch.
2 Mirrored translations. For *every single item* in a "normal" site, you now
need X amount (X being amount of active languages). this can be reduced by
saying 'I need admin areas only in language A, admin is defined as Foo and
3 Growing translations. For every piece of content there may, or may not, be a
translation. Think about freetagging (a tag beer and a tag bier). Or about
community efforts to get pages translated. interlingual connections (read
this in langB) lay, or may not be required.
4 A few pages in langA to explain what its about. Simple, just maintain a few
pages in another language.
5 Inline translations. Only certain elements of content have to be translated.
Example: a photogallery with only English and Dutch "descriptions". They may
appear on one page even. Other elements may not be translated like the title,
that can be the same for both languages.
We can also differentiate some other translations areas. The clear difference
1 content (terms, nodes, comments, profiles. oh if only they all were
2 interfaces (PO file import export)
3 admin submitted configuration (think menu-titles, or user roles, or
flexinode types, or profile fields)
The good news, is that all the types have one common denominator: language
switching. Except maybe for site type 4.
The bad news is that both workflow and interfaces differ a *lot* between the
So here is what I propose:
* locale.module+locale.inc, current implementation MINUS language
choosing/switching interface and code! handles "translate area 2".
* lang_switcher.module. A *simple* API/library module containing only APIs and
a block to select languages. No editing interfaces or forms should be in
there. Should also contain the three methods of storing the language in APIs.
$SESSION, url prefix /en/node/12 /fr/node/12 and url postfix ?lang=en.
* config_translation.inc. the toughest part: a contrib that allows us to
translate missions, blocks, menu-items etc. handles "translate area 3". I
have a fuzzy vision of some form_alter, combined with table prefixing (ugh!)
and variable_get/_set prefixing. Needs clear thought.
* Loads of modules and or themes using these APIs and systems to allow a
variety of cases and workflows. Node_translator.module,
comment_lang_switchers (yes, ever thought of how to avoid EN comments
appearing under the DE version, heh?). oh and, off course a contrib
user_profile_lang.module, containing the part from locale.module, where you
store your language preference in your profile.
And now? Fists in the air and *ffoooorwaaaaaaard* :)
Serious: if we think these Lego blocks are well defined, we only need to make
them, the blocks. Most of this is ripping stuff from existing modules,
putting that in other modules and finetune that. Oh, and occasionally we need
to build non-existing stuff, like config_translation.inc/.module.
Starting here, IMO is better then writing down that the industry needs i18n,
not? Or developing yet another module for translating the 60% your specific
case needs translated (and no-one else will ever need).
BZR? CVS? bright SVN? Drupal.org issues? where to start?
 unfortunately not /that/ simple, because if you want to have poor SEO and
so, you need to add the lang="" entity to the surrounding XHTML.
More information about the development