Please correct me if I'm wrong, but I thought we were discussing translation of user generated contents, not fixed UI strings. By speaking of context, I meant the context in hierarchically structured objects; in the given use-case - Views. Small addition to the approach taken by #translatable: Since translation forms *are* the original forms, this system is able to provide the correct UI for each translatable content (string/option/file/etc.) without the need to re-define how a translation form for a certain object needs to be built. IMHO, this is the key for a translation system that needs to be as flexible and modular as Drupal is.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Eric-Alexander Schaefer Sent: Sunday, April 27, 2008 4:23 PM To: development@drupal.org Subject: Re: [development] Seeking help internationalizing Views (and Panels and maybe other modules for D6)
Gerhard Killesreiter schrieb:
KDE's i18n() function (same as t() for Drupal) has an optional "context" parameter that the developer specifies in order to help the translators out. (That context later appears as comment in the .pot file, I believe.)
Maybe it would be an option to include something like this in some way, in order to provide an actual middle ground between "no UI-related context in the .pot file" and "no code-related context in the UI string".
Drupal already does something similar if you do not use pre-built PO files. The PO comments are filled with the URLs of the places the string was encountered first. Not perfect of course, but maybe someting to build on.
I am using a very simple i18n-System in an application, where the argument to translate() is not an english text, but a text token. The token is itself text an it can contain context. I did that not only for easing translation but for creating "namespaces" for text. In most application including drupal one word might sometimes be translated diffent depending on the context. A simple example is the german word "Himmel", which can be translated to "sky" as well as "heaven", depending on context. So the tokens could look like this: "ADMINISTRATION_SITE_BUILDING_MODULE_CONFIGURATION_MENU_ITEM_CAPTION". If you define a token naming policy carefully, the translator knows the context just by looking at the token (Thats the caption of the menu item pointing to the module configuration section.). With this translate-function, every string in every language must be contained in a translation file, which could be considered flexible.
HTH, Eric