Sven Neumann wrote:
> > It isn't up to you as the program maintainer to "merge" translations
> > from STABLE to HEAD or something like that.  Provide hints how
> > translators might proceed, but please don't change contents of the
> > files.
> I have always asked people not to touch po files in CVS HEAD at all.
> Until we change this rule, the po files are in the maintainers
> responsibility.

I do not agree.
Committing PO files to HEAD in any project is always risky business
(large frequent changes im messages), and time for translating is always
better spent in the stable branch, if there is one. HEAD is secondary at
best, and translators should know what they are doing if they touch the
HEAD branch. That I agree on.

But I think it's stupid to entirely forbid committing translations to
the HEAD branch, if the translators know what they are doing. Why?
Because of testing.

Testing translations is as needed as testing code - translations for
new/changed  messages in the HEAD branch might be wrong, and we'd like
to spot and fix those before any release. Also, having a complete or
near complete translation in HEAD helps finding i18n bugs - If I know my
translation is complete, a message that appears in English almost
certainly indicates that a developer forgot to gettextify a message, and
those bugs can be reported/patches made/fixed before a release. This is
not an uncommon situation for many applications.

GTK+ has/had a similar policy for HEAD - Translators were strongly
encouraged not to translate HEAD. I chose to ignore that and committed
an updated complete UTF-8 translation for HEAD anyway (stable is of
course still my top priority). I knew about the danger of translating a
rapidly moving target, and I decided that I still wanted to try it. What
happened? A month later a GTK+ developer thanks me for the translation
because it gave him something to test UTF-8 cleanliness in new GTK+ code
A month later the once complete HEAD translation is at only 50% because
of added/changed messages, but I knew that this would happen at some
time, before I started working on the HEAD translation. But the net
result is still that this GTK+ HEAD translation helped others, including
a GTK+ developer.

So, please, advise translators to put their efforts in the stable
branch, but please don't forbid those translators that feel that they
can afford it to also commit translations in HEAD.

> > PO files are translators land.  Maintainers don't have the right to
> > convert them into another charset.  Leave these files alone, please.
> as said above, I consider po files in gimp CVS HEAD maintainers land.
> Translators have been asked not to enter this area multiple times.

PO files are translators' land. They maintain them. Don't touch them.
The translators know the language, developers in most cases don't.
Translators know what charset is best suited for the locale, and works
with the translation tools they use, developers don't. If you want to
maintain a translation, you are free to translate yourself¹. ;)

I myself would probably convert the sv.po in Gimp HEAD to UTF-8, like in
GTK+, if I was kindly asked to, and it was recommended, but I still
don't want others to touch the PO file.
I think I could live with having to run iconv back and forward every
time I touch the file, maybe I could also live with the different
charset breaking the translation memory I use. But please let me still
maintain the file, and don't touch it!

> For the HEAD branch, we should try to find a responsible translation
> maintainer for each language. The language maintainer should have CVS 
> commit access and is responsible for coordinating his/her team of 
> translators.

You've just described the GNOME Translation Project.


¹ I know you are translating de.po. But that's only 1/27 of the
Gimp-developer mailing list

Reply via email to