Fehér János wrote:

I'd like to know your oppinions about the current and the future state of the i18n possibilities in Drupal.

I will give a short overview of what I know, but I'd like to keep technical discussions away from this list. Technical stuff should be discussed on the developer mailing list, even if it is i18n related.

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.

This is a common problem, that Drupal can currently not solve out of the box. Also, there are a variety of ways to deal with the problem. A commercial site woulld want to show only content in a specific language, whereas some other sites would be happy to mix it.

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

Right, the locale module in Drupal core only allows you to translate Drupal's strings. it does not translate user input.

i18n module: helps to translate a node, but there's no real relation between the original and the translated node.

There is a table which keeps track, I think. But there is probably no workflow.

You're not able to translate the taxonomy and the menu system. It needs core-patching.

It will no longer need patching for 4.7.

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.

This module is very new and I have not tried it.

Features I'd like to see (in random order):

• a statistics page about which node aren't translated...

This would require some workflow. Did you look at the workflow module? Maybe it can be extended.

• Localization API support for modules. These modules can

use the region/currency/etc functions or extend them. Eg: ecommerce

this obviously needs some thought.

• 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.

I don't know either.

• Forget patches. Try to force core developers to implement

much more i18n functions :]

Forcing a core developer is easy: Whip up great patches that he cannot resist to commit. :)

• Handle languages by QUERY_STRING (because of cookies). Rob

told me, his tr module made for especially anonymous users.

i18n can do that as well, I think.

• Special rights for translators. Who can translate a node?

The translator group.

Shoudl be easy enough to add once you got a module for the workflow.

• 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!

Posting ideas here won't get anything done, I am afraid. You could try filing feature request against i18n module.

Jose (the author maintainer of i18n) and myself have discussed i18n issues at DrupalCon in Amsterdam, unfortunately, we did not agree on too much. We will both write a report, though. I just need to do that...

Cheers, Gerhard