[development] Drupal and i18n, the holy grail?

[Khalid B]

I think an approach worth considering is having hooks in core for
multilingual content (e.g. a lang column in nodes, menus, blocks,
...etc.), and let contribs handle those hooks in  multiple ways.

I met Eric Gunderson of Development Seed at DrupalCON and  talked
about that a bit.

Jose Reyero, the author  of the i18n module has a plan on keeping
up with 4.7.

It is described here
http://www.developmentseed.org/blog/internationalization/drupal4-7

There is also the tr module
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/tr/

It is worthwhile that Ber coordinates with Jose and/or Eric, et al
for a  unified solution.

On 2/25/06, Bèr Kessels <ber at webschuur.com> wrote:
> 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
> implementations.
> 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
> Bar'
> 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.[1]
> 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
> being:
> 1 content (terms, nodes, comments, profiles. oh if only they all were
> *cough* :))
> 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
> various types.
>
> 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?
>
> Bèr
>
> [1] 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.
>