[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Sven Neumann

Hi,

Karl Eichwalder [EMAIL PROTECTED] writes:

 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.

Some people working on the po files don't have CVS commit access, 
so I can't simply ask them to do the conversion. Here is what needs 
to be done, so we can work out a plan how it can be done best:

(1) Some new languages have been added to the stable branch. These
need to be added to the unstable branch.
(2) Updates to translations from the stable branch need to be 
merged. Merging in this context means copying the po files
from the stable branch to unstable and running msgmerge on
them. Since we haven't changed many strings yet, this should
give reasonable results.
(3) We need to handle the UTF-8 problem somehow. GTK+-2.0 solved
this by keeping UTF-8 encoded po files in the tree and I do
like this solution but I'm open for suggestions.

 But that's not a valid reason to force the translators to deal with
 UTF-8 if they don't want to.  GTK developers think they need .mo files
 using UTF-8 (why?) convert them at installation time, please!

what benefit does this give? Converting at installation time is not
possible since we can not require the user to have the appropriate
tools installed. We could do it at release time, but this wouldn't
fit into the 'make dist' scheme. I see no real alternative to UTF-8
encoded po files in the tree.

 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.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Sven Neumann

Hi,

Karl Eichwalder [EMAIL PROTECTED] writes:

  what benefit does this give? Converting at installation time is not
  possible since we can not require the user to have the appropriate
  tools installed. We could do it at release time, but this wouldn't
  fit into the 'make dist' scheme.
 
 release time sounds good to me.  I'd recommend to modify the 'make
 dist' target and send a feature request to Bruno Haible.  There's at
 least one project which goes this road since a year(?).

I don't think release time is a good solution. First, we need this
feature now and I don't want to require gettext from CVS. Second,
we want to have useable po files in the tree all the time so gimp
from CVS is useable even if LC_ALL != C.

  I see no real alternative to UTF-8 encoded po files in the tree.
 
 I'm all for UTF-8, but every single language team should decide when the
 time has come.

do you really think the additional step of converting to UTF-8 before
committing is too much for our translators? I don't think so.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Sven Neumann

Hi,

Karl Eichwalder [EMAIL PROTECTED] writes:

 Sven Neumann [EMAIL PROTECTED] writes:
 
  I don't think release time is a good solution. First, we need this
  feature now and I don't want to require gettext from CVS.
 
 Sure, but a simple script calling iconv or recode will do it.

we can not assume that iconv or recode is available on all target platforms.

  Second, we want to have useable po files in the tree all the time so
  gimp from CVS is useable even if LC_ALL != C.
 
 I don't understand this argument.

I don't understand your argument either, but let me explain mine. The 
GIMP should work as checked out of CVS, so either we have UTF-8 po 
files in CVS (like GTK+ does) or we need to convert to UTF-8 during
generation of the mo files. This would require the availability of the 
necessary tools on the build platform which we can not safely assume.

IMO the easiest solution is to go for UTF-8 po files in CVS.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Christian Rose

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
with.
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.


Christian



¹ I know you are translating de.po. But that's only 1/27 of the
translations.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Sven Neumann

Hi,

Christian Rose [EMAIL PROTECTED] writes:

  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. 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. 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?

 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.

  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.

hmm, not all of our translators are part of the GNOME translation 
project and GIMP != GNOME. For that reason, I'd like to maintain a list
of language maintainers in the GIMP source tree. If the GNOME 
translation project wants to take this job and thinks such a list is a
waste of time, this is something we can and should consider, but it 
needs to be discussed. I really appreciate all the help I can get here
and don't feel comfortable maintaining GIMP translations, but at the
moment people send po updates to me. I'd prefer if this job could be
taken by someone else and if the GNOME translation project stands up
and wants the job, just tell me to whom I should send people with 
translation updates in the future. I would really love to be able to
concentrate on real hacking again.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Christian Rose

R.I.P. Deaddog wrote:
  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!
 
 There are two kind of people that commit po files into HEAD branch; one kind
 is so stupid that they can't even distinguish between HEAD and stable
 branch, and another kind knows very well what they're doing. So how about
 a method distinguishing these two kind of people?

I don't think it has anything to do with stupidity. It's probably just
that people don't know about branches and/or how to check out different
branches. Every other project using its own system with branches
probably doesn't help either. I guess we've all been there, not knowing
how to properly use branches, unless we were born with knowledge about
CVS.

I have no good solution for solving this. I think that information helps
though. Every translation request mail to gnome-i18n should contain
information about what branch(es) to use IMHO, and if the maintainer is
really worried that translations will go to the wrong branch, including
instructions in the mail on how to check out the correct branch(es)
probably doesn't hurt. Also, some projects use files named
TRANSLATORS_READ_THIS or similar in the po directories in the wrong
branch, with information about the right branch to use. It's buttugly,
but effective, I think.

Also, once the maintainer sees a translation go to the wrong branch,
replying to the translator as soon as possible and ask if it wasn't
really meant for the stable branch probably also helps.

Again, I don't think this solves this problem completely, and I also
suspect GIMP in particular does many of these things already, but I
think it helps.


 For example, send a piece of email to committer/last translator. If they do
 reply and acknowledge/reject the overwriting of HEAD branch po files, then
 one knows they are still actively maintaining the file; otherwise one can
 safely assume the file is not actively maintained, and can be overwritten
 freely.

Agreed, but it should be done soon after the commit. I don't think
reverting a translation update because the translator happens to be away
from his mail for a week some time during the summer is a good thing.
But yes, I agree, Communication is King.


Christian
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Christian Rose

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
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Translating The GIMP

2001-08-29 Thread Sven Neumann

Hi,

OK, here's what I came up with as a (preliminary?) solution.

I've added a link to the GNOME Translation Project's homepage to
README.i18n and will refer all people willing to contribute to 
GIMP's localisation to the GTP. I'll do the same with people
sending me translations and I ask everyone to do the same. The 
people from the GTP have CVS commit access and some coordination
on the i18n front is most probably a good idea.

I have added a note to README.i18n in the unstable branch 
explaining that GTK+-2.0 requires UTF-8 strings and that we 
require UTF-8 encoded po files (and tips files) for that reason. 
We do not do any implicit conversions so any po files that are 
not UTF-8 encoded will not work. If someone comes up with a 
reasonable way to do on-the-fly conversion, I'll consider adding 
it, but first I want to hear a good reason from an active 
translator why she thinks dealing with UTF-8 encoded files in 
CVS is too much of a burden. 

I hereby encourage translators to convert their po and tips files 
in gimp HEAD to UTF-8. The gnome-i18n module in CVS has some 
scripts that help with this task. If you feel like updating the
translations in the HEAD branch, feel free to do so, but expect
lots of strings to change. Your main concern should however be 
to finish and polish translation of stable gimp as found in the 
gimp-1-2 branch.

I will not touch any po files except the german ones any more 
except for trivial fixes that break the build.

Please excuse if I may have sounded harsh during this thread; 
I didn't want to step on anyone's feet.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: translating The GIMP

2001-07-19 Thread Sven Neumann

Hi,

looks as if I have not been detailed enough (I'm referring to 
the latest addition of a new language to The GIMP that happened
after my first email).

Please do _not_ use gimp.pot files from any other source than 
GNOME-CVS module gimp branch gimp-1-2.

Ask before you add a new translation to The GIMP.

Run 'update.sh lang.po' before committing.

You have to provide po files for all po directories as explained
in README.i18n.

Thank you.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer