Re: committing updated po files

[Tomasz KÅoczko <kloczek zie pg gda pl>]

On Wed, 28 Sep 2005, Christian Persch wrote:

> Hi,
> 
> 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 ?

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

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

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

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

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.

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

Q: reverte my changes ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie majÄ problemÃw, tylko sobie sami je stwarzajÄ*
-----------------------------------------------------------
Tomasz KÅoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek rudy mif pg gda pl*