retitle 360141 po4a regenerates po files inconditionally thanks On Sun, Apr 02, 2006 at 11:01:34PM +0200, Denis Barbier wrote: > On Sun, Apr 02, 2006 at 10:28:49PM +0200, Martin Quinson wrote: > > Here is an example of problem: > > Imagine three times: day1 < day2 < day3 > > POT gets updated on day1 and day2 > > Translator works on day3, but based on pot of day1. > > > > The po file must be updated against the day2 pot version, even if hte po > > file itself is more recent. > > > > > > Then, you could argue that we have to use the POT revision dates from the > > header instead of trusting the file modification date, but it will not help > > us much here. We rely on msgmerge to do the merge, with the -U flag to > > update the po file. Unfortunately, the documentation says: > > -U, --update > > update def.po, do nothing if def.po already up to date > > > > It does not even update the POT revision date of the po file (just tested). > > > > > > So, in summary, I think that we should: > > - use the POT revision date to decide whether we update the po file or not > > - bug msgmerge for not updating this when the other fields do not change > > or not rely on "msgmerge *-U*" here > > PO files should always be updated when they need to be updated, otherwise > translators may work on outdated files, so these solutions are IMO not > satisfactory. With po-debconf (more precisely in the GeneratePOTemplate > function of /usr/share/intltool-debian/intltool-update) the POT file is > generated into templates.pot-update, and if templates.pot does already > exist, the header field of both files is removed, and remaining files are > compared (note to self: maybe msgcmp could be used instead?). If they > differ (or if templates.pot does not exist), templates.pot-update is > renamed into templates.pot. This solution works pretty well.
Actually, I'm not far from thinking that this is not a bug here. Trying to over-optimize stuff and only rebuild the po file when mandatory may lead to some strange effects. But as usual, I leave up to nekral (as upstream main developper) to decide what to do here. Robert, what do you think of all these new elements? Do you still consider this as a bug? Bye, Mt. -- For every complex problem there is a solution which is simple, neat and wrong.
signature.asc
Description: Digital signature
