Internationalization Use-Cases, Actors and Feature Requests

I am a web architect and a system analyst. Now, I've translated Drupal To Hebrew and initiated the creation of a drupal community in Israel. Following Gábor Hojtsy's request, Here is a use-case analysis of my expernece from the Hebrew Translation of Drupal, and with it's implementation on tens of sites, with indexation for search engine relevancy.

Recently, I've tried the Internationalization module on two of my sites, but gave it up and decided to wait for a later time. Problem is that i18n is not yet compatible with many other modules. I am a heavy user of taxonomy / category modules. The i18n module is a big step forward, but more work is needed. I need language specific taxonomy with menu integration. On one site, I have tried to use the taxonomy module, but found that the vocabulary names are not translated (nither in the node entery screens nor in the menu). On the other site, I tried to use the new category module but discovered that the node input form (and the menu) displayed all categories without language distinction.

My experience is also based on the earlier experience of creating a translation infrastructure for the translation of a proprietry CRM software to 10+ languages (including Hebrew and Japanese).

This post is expanded from a comment this morning, added some background, a new actor and new requirements

Needed Translation Actors:
* UI Translator
* End-User (Surfer)
* Content Translator
* Webmaster (Translates the site-speficic definitions)
* SEO Expert
* Drupal Developer

Needed Translation Use Cases:

==== Webmaster ====
* Webmaster (Translates the site-speficic definitions) must be able to easily translate vocabulary names, taxonomy terms, categories, and profile field names as well as the site-specific properties like default email messages ).
* Webmaster should be able to translate the name of a taxonomy vocabulary.
* Webmaster should be able to translate the name of a CCK field.
* Webmaster should be able to translate the name of a profile field.
* Webmaster should be able to Bulk-translate taxonomy terms in different languages.
* Webmaster (and End-users) must be able to easily see which content was already translated and which content still needs translation.

==== SEO Expert ====
* SEO Expert is responsible for entering friendly UTF-8 based URLs relevant to the content.
* SEO Export is also responsible for making the definitions needed to generate those URLs automatically.

==== UI Translator ====
* UI Translator must be able to get translations from other translators, review them, approve them, and upload them to the CVS (or to an Online Translation website).
* Modify an existing module translation to upgrade it to a new version.
* UI Translator should be able to easily upgrade a translated module POT file with all the new string fromthe new version of the module. It should be possible to fetch all new strings from a module and merge them with the current translation.
* UT Translator should be able to CHANGE translation of a single word across the site (for all the string which contain the word, the translator must see the ORIGINAL sentence and the translated string TOGETHER, in context, in order to decide about the best new translation in context.
* UI Translator should still be able to do offline translation, then merge it back.
* UI Translator should be able to merge several different translations and view a DIFF between them. Decide which translation to approve and which translation to deny.
* UT translator should be able to easily find the name of a settings field (e.g. site mission) in order to know how to define it.

==== End User ====
* End user should be able to view taxonomy terms in a selected language only.
* End user should be able to view a certain taxonomy hierarchy embedded in the menu.

==== Modules Developer =====
* Modules Developer must be able to use multilingual features automatically, built into the written code.

Missing Features:
* Language direction (ltr, rtl, or ttb) must be embedded in the lang table in core!
* Themes should be able to display an item correctly according to it's direction.
* Templates should merge misc/drupal-rtl.css (after the normal misc/drupal.css). drupal-rtl.css should only contain the missing defintions. Merging should only be done if the current I18n language is RTL. Same about drupal-ttb.css.
* Vocabulary names must be translated. Same about CCK fields, profile files, and other definitions.
* Have an option to allow UTF-8 URLs for all paths. The only characters which are not permitted are "?", "&", "=". All other characters are OK, and are good for SEO. Please remove the input check which limits the URL aliases to 8-bit. This requirement is obsolete

Known Bugs:
* There is a bug with the captured translation URL, - it must substract the base path from the recorded path. For example: http://www.example.com/~levavie/admin/setting must be recorded as admin/settings.