[development] Seeking help internationalizing Views (and Panels and maybe other modules for D6)

[Daniel F. Kudwien]

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 at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of 
> Eric-Alexander Schaefer
> Sent: Sunday, April 27, 2008 4:23 PM
> To: development at 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
>