Re: i18n done with gettext

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 17 Nov 2005 15:47:20 +0100, in gmane.linux.vdr you wrote:

> Iwan Davies wrote:
>> You could still get collisions within a single plugin, unless you use
>> unique string IDs (assuming this is how gettext works?).
> 
> The current implementation of VDR - and the typical use of gettext - use
> the English translation as a key, with the option to pass through this
> text if no translation is found. (gettext: or no language file found)
> 
> There may be a way to 'tag' in gettext, so that in case of pass-through
> at least the tag gets removed, don't know. VDR's i18n allows such tags
> in form "tag$english text", where everything up to $ will always be
> deleted on output.
> 
>> Sharing strings even within a plugin is /a bad idea/ - you never know where
>> the string might be reused next time, and the translator may need to
>> inflect, conjugate or decline the term differently in each context.
> 
> Plugins are usually maintained by one person, so this shouldn't be as
> problematic as with all plugins in one context.
> 

I'm thinking particularly of problems I've experienced in the past in 
various localisation projects, where, for example, the phrases "von" and 
"bis" have been reused in different contexts wth represent different 
meanings ("von Datum"/"bis Datum" and "von Uhrzeit"/"bis Uhrzeit"). In 
French, for example, the first "von"/"bis" would be translated 
"du"/"jusqu'au" and the second "de"/"jusqu'?". 

In English there is no problem in this particular example, but another 
situation could see the German use the same noun as a command an an option 
setting, whereas English would require the command to be translated as an 
imperative and the setting as a noun. The point is, the plugin developer 
has no way of knowing how reuse of strings (and duplicate use of string 
IDs) will affect the quality of the translation, so the safest approach is 
to assign each string a (G)UID. Incorporating the plugin name in this UID 
ensures it is globally unique for vdr. On the other hand, judicious use of 
the tag system in vdr would have the same effect, as long as you could be 
sure that each tag is unique and none are reused.

As I say, redundancy is dealt with during the translation process by using 
translation memory, which at least gives the translator the option of 
deciding whether to reuse an existing identical term or not.

Cheers

Iwan


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux