Re: committing updated po files

[Christian Rose <menthos gnome org>]

ons 2005-09-28 klockan 15:31 +0200 skrev Tomasz Kłoczko:
> > Le mercredi 28 septembre 2005 à 13:56 +0300, Tommi Vainikainen a écrit :
> > > On 2005-09-20T18:44:55+0300, danilo gnome org wrote:
> > > > Tomasz, why did you need to do this everywhere? :(  I really hope
> > > > there are some good reasons for this. Anyway, please revert all these
> > > > changes.
> > > 
> > > Was there ever any conclusion for this thread? I see that Thomas has
> > > done more this kind of commits after last message in the thread as can
> > > be seen from
> > > <URL: http://cia.navi.cx/stats/author/kloczek >
> > 
> > I've been getting bounces for all messages to
> > kloczek container gnome org ; it appears the cvs-commits-list mails have
> > an invalid From: address :(
> 
> How can I change this alias ?

As Ross said; http://live.gnome.org/UpdatingEmailAddress


> > Trying to CC the @cvs.gnome.org address now, but last time I tried that
> > one (for someone else) it didn't work either...
> 
> Anyway .. resons:
> 
> 1) Many .po files have incorrect content of c-format translated entries. 
>    Keep not updated this files *creates real risk from security point of view*.

None of your ChangeLog entries listed this as a point of action.


> 2) Many translators do not run "make update-po" before completting 
>    translations and bring them (for example) one time per release
>    updated all .po files makes possible finish some work.
>    Many .po files have content not updated (update-po target)
>    by *year, two or ven more* and this plain proof of this kind problems.
>    Two years ago widely was used gettext without c-format entries 
>    checking (this is why risk described in point 1) still is real).

If you find any problematic translations, you should bug report this
kind of problems to either the author of the translation, the team
coordinator for the translation team for that language, or directly to
the maintainer of the affected application. You should never ever commit
any "fixes" *whatsoever* without approval.

And even if you would have happened to have said approval to fix that
type of problems, you should never ever alter any files that didn't have
the problems in them. Because that was what your changes were doing -
modifying all files, including perfectly valid files.
	

> 3) Number of outdated lines with translations in some projects makes dist 
>    tar balls larger by megabytes (example: evolution). In some cases it 
>    takes around half of some files (usualy few procents).

There are many perfectly valid reasons why some translators leave some
unused messages in by purpose. Some of the reasons include that the
translators may suspect that these messages are likely to be reused and
do not want to translate them again from scratch. This can for example
be when the original message had a typo and when that is likely to be
corrected some day and the translator doesn't want to redo his work by
then, but instead arranges a translation of the correct spelling right
now, which then of course becomes a unused translation for the time
being. Or this can happen when a similar message is likely to appear in
the future for other reasons, or in order to help fuzzy matching in
general.

In many cases a few kilobytes of extra tarball size is a small price to
pay for hours of saved work. Some kilobytes of disk space is cheap; man
hours isn't.

In any case, this is not up to you to decide. Maintainers may complain
if specific tarball sizes are becoming a problem, and then a solution
might be worked out with affected translators. Then, and only then, some
course of action might be taken.


> 3) Many GNOME projects have po/ directory ~up-to-date because 
>    maintainers before release runs "make -C po update-po" and commit 
>    changes (example: glib, gtk+, gnimeric, gimp ..) ~one time per release.
>    Seems noone says "it is incorrect" and/or "it makes translation harder".

In that case you must have ignored any mailing list traffic for the last
few years:

http://mail.gnome.org/archives/desktop-devel-list/2003-May/msg00896.html
http://mail.gnome.org/archives/gnome-i18n/2004-August/msg00161.html

If you are claiming that noone complains, then you have not been
listening for years.


> 4) In case not commiting same changes by translators before someone will 
>    commit changes added by update-po target translator only must merge 
>    own/not commited yet changes using msgmerge command from 
>    #<lang>.po.<rel> file created by cvs client and without loosing single 
>    line can continue tranalation work.

It's you who shouldn't touch other people's work without permission in
the first place.

If you feel otherwise, or feel that it's so simple to undo your changes
if needed so there was no real harm in committing those changes in the
first place, then you have totally misunderstood the rules of behavior
for any write access repository, and should not be allowed write access
to any repository within lightyears of range.


> 5) update-po target do not trash any translations. Only comments not used,
>    adds some new entries and marks some entries as fuzzy.
> 
> Now is used habit for stop few days before release chages around itroduce 
> new strings for translate. IMO best will be mark this point by "make -C po 
> update-po" and commit changes performed by project maintainer.
> 
> Run "make -C po update-po" each time when something is changed in .c files 
> will be of course very stupid (will create big "noise" aroud po/*po files) 
> but one time per relase, and one time per three or two releases cuting 
> outdated string will allow keep this resources in good form (and possiby 
> comfortable for translators).

Four points:
A) Any such policy should be discussed first.
B) Any such policy should be given approval by those affected
(translators, maintainers).
C) If there was any such policy, and you were the one chosen to do it,
then that should be made clear beforehand.
D) None of A), B), or C) applied in this case.


> Q: reverte my changes ?

Yes, "reverting" is the action of immediately undoing unauthorized or
otherwise unwanted commits in the repository. The revertion is to be
done by the person who erroneously committed the stuff, so as to not
waste other people's time more than necessary.
Not reverting when asked to is generally not an option: Committing
unallowed changes is bad enough in the first place; not reverting the
changes when asked to is a guarantee for being banned for life.


Speking for myself,
Christian