[development] Drupal and i18n, the holy grail?

[Benson Wong]

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

The first two that tough to fix, it's #3 that would require some
revolutionary changes to the system.

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.

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.

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.

(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)

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.

One approach, that I've been mulling over (with some ideas from
eZpublish), is to have an abstracted content creation layer that sits
on top of the database layer. I don't know what's been going on with
the CCK, but perhaps that may be a good foundation for this stuff.

(wrrrr...geek mode)
#1. When configuring your site you _HAVE_ to choose a default language.
#2. Additional languages can be added.

Handling Nodes:

To define a new node, we have a simple definition (in code, in a text
file, whatever). I prefer this so I can source control them. The forms
api is a good example of using arrays of arrays to define something
complex. We can apply this to nodes:

1. A node already has default fields (title, body, teaser), and a
contrib can add custom ones.
2. The attributes and handling of fields is be defined as an associative array.
3. The system will handle all the database stuff auto-magically,
making these obsolete node_insert(), node_update(), node_load(), etc.
4. Added benefit (psst..Adrian), this will also allow us to create the
MVC system,  RPC access to anything/everything...droolz.

It should be fairly easy to tie together the FAPI with the node def,
to create a web form.

When nodes are created, they are in the default site language. So,
some work flow off the top of my head:

1. We have a site that is French/English.
2. node/story/add
3. Creates a new node (nid:34), (ver:1), (lang:en)
4. Translate to french: node/34/tr/fr
5. Does this, automagically...
creates: (nid:34),(ver:2),(lang:en)
creates: (nid:34),(ver:2),(lang:fr)

Notice that version 2 has an English and French version, where as
version 1 only has an English version. This would undoubtly create
lots of data as copies, but we're smart, we can find a better
solution.

Anyways, I've been typing this for like 2hours, and gotta pick up the
wife. I'll write more ideas about handling menus, system variables, if
I find some more time this weekend.

I would like to be able to create i18n menu paths as well...
eg:

http://en.drupal.org/view/32
http://fr.drupal.org/vue/32
http://de.drupal.org/ansicht/32

to be all be contextually the same
(I used google translate for the above, so if it's wrong... :)

Ben.