[translations] i18n possibilities in Drupal

[Fehér János]

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,
-- 
Aries