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