Re: Ensuring Translation Quality

On Fri, Sep 23, 2011 at 6:13 PM, Morten Juhl-Johansen Zölde-Fejer
<mjjzf@syntaktisk.dk> wrote:

> Feel free to skin me for my ignorance on this one, but if one was to
> make a variation on English, wouldn't you just copy the strings that
> did not need translation in order to keep a full translation status? I
> have never come across a translation tool that did not have
> copy-from-original function.

No skinning needed. If a translation is not supplied, the standard
default action is to provide the base-language (typically English,
usually en_US) string. This is why (for example) it may never make
sense for an English variant to reach a high level of coverage, but
still be completely correct for it's intended purpose (changing color
to colour and -zation to -sation)

The Gnome folks even have a script for doing a first pass conversion
from en_US to en_GB

http://git.gnome.org/browse/gnome-i18n/tree/en_GB/en_GB.pl

I must admit I'm not sure how I feel about a scripted conversion, I
feel it is a lost opportunity for i18n quality assurance review.. One
of the great advantages of having an en_GB project is that it creates
an opportunity to review the strings carefully and a motivation to
report i18n errors, instead of just correcting them in the (say
Danish) translation you provide, without bothering to file a bug on
the typo you've compensated for in the translated string.

In other words, since the en_GB localizer has such an easy time
translating (being able to use the copy-msgid features of their chosen
tool with high frequency or simply skipping past a string), they have
extra time to devote to i18n improvement. All in all, a nice
arrangement.

cjl
Received on Sat Sep 24 02:26:28 2011