Re: Updating po files on make dist

[Christian Rose <menthos gnome org>]

fre 2003-05-23 klockan 21.05 skrev Miloslav Trmac:
> > > So, fix cvs(1) :-)
> > 
> > You're joking, right?
> > Otherwise I don't understand why we should try to go through the pains
> > of getting the behavior of cvs changed in order to make the symptoms of
> > the problem easier to cope with, rather than fixing the root of the
> > problem, which is make dist and a thing that we from a GNOME side of
> > things can much easier fix. Should be obvious to anyone which thing is
> > both better in the long run to fix *and* easier to fix.
>
> I don't think it is that obvious that shipping current files instead
> of updated ones is a problem.

Noone's claiming that either. It's the committing of regenerated files
into cvs that's the problem, since it causes cvs conflicts. In most
cases totally unnecessary ones.


> > Also, from a GTP perspective, I believe that it is in our interest to
> > make the entry barrier for volunteering translators lower, so as to get
> > more contributing translators, translations for more languages, and more
> > complete translations. We still have a lot of room for improvement in
> > those areas.
>
> The entry barrier argument cuts both ways. If you have very limited
> access to the Internet (which might be very rare nowadays, but
> there are translators working on *many* languages), it might be
> advantageous to get the .po files from e.g. CDs in computer magazines.

They need some sort of Internet access anyway to be able to submit their
work, so I don't see that downloading a fresh po/pot file from the
status pages is a problem. If they go through a friend with Internet
access to submit their work, that friend could just as easily provide
said person with a fresh po/pot file from the Internet too.

Translating from po files in tarballs or on magazine CDs is almost
always a dead race anyway, as those bits are per definition more or less
obsolete and don't match the latest state in cvs in any case. So I don't
really see how that argument would apply.


> In that case, you want the .po files to be accurate so that the
> translators can just start translating without having to
> intltool-update.

As said, if they start from a po file on a magazine CD their work is
most likely to be more or less obsolete from start anyway. Plus, it's
not like intltool is a heavy piece of software with lots of nasty
dependencies and unlikely to be found on any Linux system these days.


> > Thus, not requiring translators to have anything but the 
> > most basic knowledge of cvs when they start contributing to cvs is a
> > natural consequence of that, especially since we can expect some
> > translators to be more fluent with languages than with deeper technical
> > tools and issues.
>
> You don't need that much knowledge of CVS. If the team members know
> who is working on which package, you can just commit your translation
> regardless of the updates because you know they are not translation
> fixes.

No, I cannot. Sometimes the maintainers or other hackers/translators
need to fix syntactic errors in the po file that prevents building, so
translators cannot just blindly commit their changes anyway, even if
they know how to resolve a conflict by just using the backup.

Also, a problem that I have experienced is that sometimes I have missed
the part that there even was a cvs conflict to begin with, so I
unknowingly go on and continue to work and spend a lot of time updating
the (diffed) file, only to later find out that msgfmt will puke on the
file and realize that I'll spend quite a bit of time sorting out the
mess, trying not to lose my translation updates and still getting back
at a valid po file that I can commit. There's much cursing going on when
that happens, believe me, especially when the cvs conflict was seemingly
unnecessary to begin with and this need not have happened at all.

One could argue that that's just me being so "clumsy", but since it's
reportedly not uncommon for maintainers to revert such committed diff
files that break building, one can guess that it's not that uncommon of
a problem among translators that don't expect others to touch their po
file without prior warning.


> > With time, contributors ususally get more familiar with cvs, but how cvs
> > works in every detail is not a trivial thing to grasp right from the
> > start. In particular not the behavior when there is a conflict, with the
> > file you worked on having its content altered to neither be the content
> > of what's in cvs nor the content you entered, but rather something
> > inbetween with cryptic cvs diff syntax, and that in addition makes an
> > invalid po file. Neither does it help the intuitiveness that the content
> > you entered has instead been placed in a hidden file with mostly
> > unhelpful, cryptic naming.
>
> If the translators can handle intltool-update and format strings
> (including the %1$ syntax), they surely can handle this too. All it
> needs is a bit of documentation.

Obviously we can't expect or require translators to know everything.
Some things are necessary to know, some others shouldn't be. The issue
of how to resolve unnecessary cvs conflicts certainly belongs in the
later category.


Christian