Hi,
I'd like to know your oppinions about the current and the future state of the i18n possibilities in Drupal.
The main problem: a company/community/blog/etc want's to be support more than one language. They wan't to give information for their homies and for the World at once.
I suspected three modules, which provide i18n functions:
localization module: it provides the user interface support. It's good for that but not capable to help the content/menu/taxonomy/etc translation
i18n module: helps to translate a node, but there's no real relation between the original and the translated node. You're not able to translate the taxonomy and the menu system. It needs core-patching.
tr module: you can translate the node/taxonomy/menu , but it's in experimential state now, you have to patch the core to use it. you can use special hostname to handle the different languages, but it's not able to handle it as a part of query string as i18n module does.
Features I'd like to see (in random order):
- a statistics page about which node aren't translated...
- Localization API support for modules. These modules can use the region/currency/etc functions or extend them. Eg: ecommerce
- I'd love to see one module for UI translation and one useful for the content translation. I don't really know why Rob started a new project. The goals are seems to me same.
- Forget patches. Try to force core developers to implement much more i18n functions :]
- Handle languages by QUERY_STRING (because of cookies). Rob told me, his tr module made for especially anonymous users.
- Special rights for translators. Who can translate a node? The translator group.
- There should be API functions for modules, with them the modules will be able to tell which fields should be translateable. The main i18n module should (or tr, I don't know :)) recognize this.
Do you have an idea? Tell us!
Bests,