Re: Translating The GIMP

[Christian Rose <menthos menthos com>]

Sven Neumann wrote:
> > > 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.
> 
> I didn't forbid it, I only tried to encourage people to concentrate on
> the stable branch.

Ok, that sounds sensible. I misinterpreted it, sorry.


> Now I want to weaken this policy since we are
> approaching a developers release. I had the idea of helping translators
> by bringing the translations in the unstable tree uptodate with the
> stable tree so they have something to start with. I think I am now
> convinced that I shouldn't do this.

Ok, good.


> The problem is however that some
> of our translators don't have commit access and have been promised that
> their translations will be added to the unstable tree when the time has
> come. Well, the time has come, so what am I supposed to do?

Ask them. :)
Ask them if they want you to do this for their translation. I think you
should ask this individually, for every translator, because the
responses and wishes might be entirely different.


> > Translators know what charset is best suited for the locale, and works
> > with the translation tools they use, developers don't.
> 
> well, I do know that we need UTF-8 encoded strings for GIMP since we
> use GTK+-2.0. IMO the best solution is to enforce UTF-8 encoding for
> our po files just like GTK+ does.

I'll try to stay out of the technical merits. I've been wrong before.

What matters to me is that I get to decide what encoding to use in my
translation. I'll be happy to take advise and recommendations, and would
probably switch to UTF-8 if it helps (I'll take your word that is does),
but I want the final say on what encoding to use in my translation. I
believe most other translators also want this, since a charset change
often breaks existing translation tools and procedures.

Some people have said that gettext already supports runtime conversion.
Even if this introduces a performerance penalty, I'd argue that any
other decision a translator makes on how to localize the application
into his locale, *also* effects the look and feel of the application. I
don't see how an informed decision on charset, that possibly affects
performerance, would be very much different. It affects the
look/feel/performerance of the application in that locale.
All this is of course given that runtime conversion works, and as I
said, I've been wrong before. But I'd really like this possibility to
get investigated.

Forcing is bad. Encouraging is good. If you have the possibility to just
encourage instead of force, I think you should do that.


Christian