[translations] i18n possibilities in Drupal

[Gerhard Killesreiter]

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