[translations] Limitations of the source-string-centric approach (was: proper way to translate complicated ...)

[Konstantin Käfer]

On 19.07.2007, at 13:54, Cog Rusty wrote:
> Several times I have needed to abandon a good translation of an
> English term string to my language and use an awkward one instead,
> because in English the term happens to be common in two different
> contexts while in my language it is not and I have to accommodate both
> cases. And contributed modules join the party later to exacerbate such
> a problem.

This is indeed a common problem. For the same reason, we changed the  
generic "Submit" to "Save" for Drupal 6, but that only solves one  
small problem.

> I suspect that in the center of these issues is the gettext system
> which allows an English string to have only one translation. (Perhaps
> the lack of context parameters in t() as well. I am not sure about
> that).

Maybe, we could add such context parameters (plain strings), for the  
case of the abbreviated word "May" the context parameter could be  
"month abbreviation", for the full month "May" the parameter would be  
"month full" (or something in that direction). Translators would have  
to advice programmers to use contexts for strings so that homographs  
can be separated in a clean fashion.

> Some time ago, for example, there was an unsolved issue with the month
> "May", which in English happens to be same as its abbreviation,
> therefore it can't have an abbreviation different from the name of the
> month in any other language. Or, a sting as simple as "Active" can
> have genders (male, female, neutral) depending on what it refers to,
> but here we have to choose one gender for everything (which wouldn't
> impress the occasional intellectual visitor of a site).

That's also an issue I have discovered, for example with the string  
"Your @type has been created." (with @type being the name of a  
content type).

I'll explain the problem for people who don't understand the problem:
Content type names have a specific gender in most languages; let's  
take "story", which translates to "Artikel" in German. The word  
"Artikel" is male, thus the sentence should be "Ihr Artikel wurde  
erstellt." (Ihr = Your). However, if we use page = Seite, we end up  
with "Ihr Seite wurde erstellt." The problem here is that "Seite" is  
female, thus requiring "Ihre" in the German language. This results in  
grammatically incorrect sentences. A wrong gender is not a minor  
issue for a native speaker, it really disturbs the reading flow and  
may shed a bad light on the site creator.

A possible solution to that problem could be to:
a) remove variables that are embedded in a sentence (strings like "Do  
you really want to delete %title?" are perfectly fine since the %  
indicates that this is user supplied text dropping out of the regular  
reading flow)
b) Provide a way to override translations for specific variable  
contents. The site administrator could for example override "Your  
@type has been created." for @type = 'Seite' and replacing it with  
"Ihre @type has been created"

> The rest of the time, a little bigger chunks of text, case sensitivity
> or even occasional differences in the html markup of a string allow as
> to hack our way to a better translation.

I can't agree with that. If we split up long texts to paragraph  
length texts, the context is absolutely clear and the likelihood that  
an entire paragraph should be translated differently in different  
contexts converges against zero.

> Does it seems a viable idea for the future to automatically add
> optional hidden text into the original English strings to identify
> different context, and then filter it out in the output? At least for
> common strings which come from a different t()
>
> I am also curious if anyone knows of any project anywhere in the world
> which one day might enhance or replace the gettext system to address
> better the issues of the single translation of a source string.
> _______________________________________________
> translations mailing list
> translations at drupal.org
> http://lists.drupal.org/mailman/listinfo/translations



Konstantin Käfer – http://kkaefer.com/