[development] Seeking help internationalizing Views (and Panels and maybe other modules for D6)
Daniel F. Kudwien
news at unleashedmind.com
Sun Apr 27 16:35:29 UTC 2008
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
> >> 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:
> 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.
More information about the development