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
