[development] Drupal and i18n, the holy grail?

[Jose A. Reyero]

Benson Wong wrote:

>FYI: I've adding some links to http://del.icio.us/tag/drupal+i18n
>
>I rather like Jose's approach to i18n support, and that is having it
>in core. I'm a little skeptical that having i18n as modular
>functionality. It should really be a part of core, and not something
>that can be turned on and off.
>
>Jose broke down the challenges pretty well:
>
> 1. i18n - being able to switch between content
> 2. l10n - being able to localize content (dates, times, currency, etc)
> 3. Multi-lingual content
>  
>
I have explained this better  here
http://www.developmentseed.org/blog/internationalization/coremodules

>The first two that tough to fix, it's #3 that would require some
>revolutionary changes to the system.
>  
>
The main changes accross the system would be.
a) Having a language field for all the translatable objects that can be
just ignored or:
b) Joining simple language conditions when you want 'multilingual
features enabled', that would be 'enabling i18n module'

>The i18n module, despite the excellent work, is really just a hack.
>Essentially with the i18n module you're building 2 sites, they're just
>mashed together through some PHP wizardry. This implementation is not
>good. If you're buildilng a multi-lingual website on 4.7, you're
>better off creating separate Drupal installations for each language.
>  
>
I have to agree that current i18n module is plenty of hacks -that
resulted from the need to avoid extensive patching to Drupal core-.
But I insist the data model is quite clean, and the hacks are only in
the module's code, thus allowing for a future core module to reuse
existing data and be implemented in a clean way

>Why? It'll accomplish exactly what the i18n module does, but with more
>simplicity. Unfortunately it is essentially two sites, which means two
>of everything, and double the maintenance. Any data sharing will
>simply be hacks/middleware to synchronize things. This is an
>unavoidable fact of using 4.7 to build an i18n, multi-lingual site.
>  
>
But about 'building different sites' I have a different view, actually
it is more like 'namespaces'. I mean you have a lot of objects -nodes,
comments, etc...- that are all of them stored in a single table, and
then you can enable/disable i18n module to have the ones for the current
language selected or to have all of them mixed together -i18n disabled,
no languages-
The pre-4.6 versions of i18n module were using this multi-site approach
which proved to be unpractical and a pain when it came to
synchronization and relations between objects in different languages
-translations-. That why it was dropped..

>This is where I think multi-lingual support should be part of core (as
>it is in other CMS systems). I'll use i18n to refer to all 3 issues
>above.
>
>  
>
Agree, whatever the implementation is some support is needed in the core.

>(brain dump...there are probably more points)
>
>1. i18n functionality should be a native part of core.
>2. An i18n API for  handling multi-lingual content (more on this below)
>3. An l10n API for themes/modules/contribs to easy localize data
>(time, currency, etc)
>
>Some more details on point 2:
>
>The i18n API would be used by pretty everything that needs to save
>content in different languages.   This is built on the idea that the
>meaning of something is constant but the language may be different.
>The challenge is creating a general use API that allows nodes to be
>created with their elements (title, body, teaser, etc, etc) to be in
>different languages.
>
>Why all that work? Usability.
>
>So we can have this:
>
>(URL method)
>http://drupal.org/en/node/32
>http://drupal.org/fr/node/32
>
>or (same thing, virtual host method)
>http://en.drupal.org/node/32
>http://fr.drupal.org/node/32
>
>And this for translating:
>
>http://drupal.org/en/node/32/tr/fr (translate from english to french)
>http://drupal.org/fr/node/32/tr/de (translate from french to german)
>
>  
>
I think the current i18n.module -with that lots of hacks- handles this
url problems better than this.
a) Objects have language, so xx/node/32 will be in whatever language the
node is
b) Interface has language, so the language prefix will determine the
interface language and the language to select the node listings.

All the urls would be just as current ones but with language prefix:
xx/node, or xx/node/32

We dont need that complex ones above for translations, as the
translation relations can be worked out before printing the links for
navigating the content.

>Accomplishing this: Before we start firing out code, I think we need
>to ask the right questions first.
>
>How will we store all this new data?
>Do we have a single set of tables, or a set of tables for each language?
>What is the ideal implementation for Drupal's node system?
>What about versioning?
>How do we make it easy for contributed modules to support i18n?
>etc.
>  
>
If we provide some generic mechanism in core for handling I.e.
multilingual nodes, the contributed modules don't need to worry at all
about it.
Same for whatever other object -menus, blocks, etc..- provided that we
provide in core some 'object abstraction' -I.e.
taxonomy_get_vocabulary()- or 'query rewriting' - current
db_rewrite_sql-  mechanism for selecting collections of objects, and the
contrib modules are using them

>  
>