Drupal: going multilingual

Update: see Multilanguage in Drupal:i18n

I am in the proccess of adding full multi language support to Drupal. So far, I have contributed a module -i18n- which can be downloaded from Drupal repository.

It was my first try and kind of an experiment, so I just got surprised by the number of people using it and am getting lots of e-mail asking about it.

Now I am redesigning the whole thing to do a clean implementation that I hope some day can get into the Drupal core. This new approach is outlined here and some proof of concept can be found here.

It is a module -i18n redesigned- and some small patches. Provides multilingual nodes, taxonomy and variables, for the moment, but it is enough to make a site look 'multilingual'. It is intended only as a developer's preview but I think it already is quite usable.

Although there's still a lot of work to do, I think this works fine, seamlessly integrates with the rest of Drupal, the overhead when disabled is negligible and the patching required is minimal . Also you can enable/disable i18n module with zero impact in the rest of the content. - I hope so ;-)

While I feel possitive about the node language implementation, I still have some doubts about the taxonomy. For the moment, languages have been added at the term level but maybe it would be better to have them also -or maybe instead of- for vocabularies. Any idea?

Whatever, I hope to have it working in some live site in a few weeks. Only I would like to get some feedback and fresh ideas from you and test chances of getting it -only hooks and db patches- into the core -someday :-)

For the moment I'm taking care of nodes and taxonomy only, but other modules should be also made 'multi language aware' -though I think i18n system won't interfere at all with them, at least with core modules; they just work as expected, only ignoring languages.

Here you are some details,

Functional Overview:
---------------------
- Added languages to nodes and taxonomy terms
- Clear separation of interface and content. Allows mixed interface/content languages.
- You can have language dependent variables
- Language can be added selectively to some node types
- Language field is not mandatory, so you can always have language-less nodes and taxonomy terms. These will show up for all languages.
- Basic interface for nodes and taxonomy -terms- translation
- When the module is disabled, you have all the content and terms, only without separation for languages.
- Path aliases can be defined with and without language preffix. They will work someway ;-)
- Initial language is taken from: url, user, browser, drupal default -in this order-
- The language code is added *always* to the url, thus incoming links should work smoothly
- Integration with locale's defined languages.
- About term translations, well, I just implemented them before thinking too much :-( . Hope we will find some use for them. :-)

Some Implementation Detail:
-----------------------
- Added 'lang' field to node table and 'term_data' --- I think it is just some tiny little harmless field which won't hurt anybody, whether you use it or not ;-)
- Translation relations are kept with a 'translation id' -'trid' field- which identifies different language translations for the same object. This field is kept in a separated table for nodes 'i18n_node' -to which some info about translation status can be added- and in the 'term_data' table itself for taxonomy terms
- Language initialization and initial path rewriting is done in the init hook, so if any other module uses arg() or $_GET['q'] in the init hook it can cause some trouble --thinking of moving it to the common.inc.
- Added a hook to module.inc::url to rewrite all outgoing urls: 'i18n_url_rewrite'
- The selection of current language nodes and terms is done with a 'node_i18n_where_sql' and 'taxonomy_i18n_where_sql' functions which I think are quite straightforward and introduce minimal overhead when i18n is disabled.
- As the language is in the node/term table itself, only a simple where clause is required -no need for complex join conditions-. This should be added -I just did some- to all the queries retrieving nodes and terms.
- Permissions are not defined yet, but will be something like: 'administer translations', 'create translations'...
- Language dependent tables -having some tables duplicated for each language- are not required anymore. But the functionality will be kept -it's just 10 lines of code- for some future use. It will remain as a low-level configurable option.

Cheers,
-feedback is awaited