Bug#360141: po4a: --force does not update the PO file's header

2006-04-04 Thread Robert Luberda
On 3 Apr 2006 at 9:15, Martin Quinson wrote:

Hi,

   
   The po file must be updated against the day2 pot version, even if hte po
   file itself is more recent.

Yes, you're right. However when writing my report, I was pretty sure 
that po4a makes use of POT-Creation-Date - the documentation says so!
Let me quote the po4a man page:

The default behavior (when --force is not specified) is the
 following:
[snip]
The PO files are re-generated based on the POT-Creation-Date of the 
POT and PO files.

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

I would consider it as a bug in msgmerge. But since po4a doesn't use 
the field, the bug is not as important as I had thought. 

 
 Robert, what do you think of all these new elements? Do you still consider
 this as a bug?

Please update the docs, and close the bug.

Regards,
robert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#360141: po4a: --force does not update the PO file's header

2006-04-03 Thread Martin Quinson
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


Bug#360141: po4a: --force does not update the PO file's header

2006-04-02 Thread Nicolas François
And the archive now.
-- 
Nekral


po4a-360141.tar.gz
Description: Binary data


Bug#360141: po4a: --force does not update the PO file's header

2006-04-02 Thread Nicolas François
Hello,

Here is an archive to reproduce this bogue.

$ md5sum test.fr.po
84d518729f3d3d125ea5b9f41853ea89  test.fr.po
$ LC_ALL=C po4a -vf test.conf
Updating test.pot:
 (5 entries)
 Updating test.fr.po:
 . done.
 0 translated messages, 5 untranslated messages.
 Discard test.fr.1 (only 0% translated; need 80%).
$ md5sum test.fr.po
84d518729f3d3d125ea5b9f41853ea89  test.fr.po

test.fr.po should be modified because the POT-Creation-Date changed in the
POT.

-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#360141: po4a: --force does not update the PO file's header

2006-04-02 Thread Martin Quinson
On Thu, Mar 30, 2006 at 10:16:20PM +0200, Robert Luberda wrote:
 Package: po4a
 Version: 0.24-1
 Severity: normal
 
 Hi,
 
 `po4a --force' updates the POT-Creation-Date field in the POT file, 
 but does not change the field in PO file:
 
 $ LC_ALL=C po4a -vf fdim.3.cfg 
 Updating pot/fdim.3.pot:
  (17 entries)
 Updating po/fdim.3.pl.po: 
 .. done.
[snip]
 $ grep POT-Creation-Date pot/fdim.3.pot po/fdim.3.pl.po
 pot/fdim.3.pot:POT-Creation-Date: 2006-03-30 22:04+0200\n
 po/fdim.3.pl.po:POT-Creation-Date: 2006-03-30 20:46+0200\n
 
 Consequently all the following calls to po4a (without --force) try 
 to update the PO file:
 
 $ LC_ALL=C po4a -v fdim.3.cfg 
 Updating po/fdim.3.pl.po: 
 .. done.
 17 translated messages.  
 
 Best Regards,
 robert


Actually, it is not as easy as it seems to be.

First of all, you can do po4a -v fdim.3.cfg several times, they will
always update the po file. The story is that it is not trivial to detect
when the po file should be updated and we decided to update them
inconditionally. 

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

Bye, Mt.

-- 
The tragedy of modern man is not that he knows less and less about the
meaning of his own life, but that it bothers him less and less.
  --- Vaclav Havel


signature.asc
Description: Digital signature


Bug#360141: po4a: --force does not update the PO file's header

2006-04-02 Thread Denis Barbier
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.

Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#360141: po4a: --force does not update the PO file's header

2006-03-30 Thread Robert Luberda
Package: po4a
Version: 0.24-1
Severity: normal

Hi,

`po4a --force' updates the POT-Creation-Date field in the POT file, 
but does not change the field in PO file:

$ LC_ALL=C po4a -vf fdim.3.cfg 
Updating pot/fdim.3.pot:
 (17 entries)
Updating po/fdim.3.pl.po: 
.. done.
   [snip]
$ grep POT-Creation-Date pot/fdim.3.pot po/fdim.3.pl.po
pot/fdim.3.pot:POT-Creation-Date: 2006-03-30 22:04+0200\n
po/fdim.3.pl.po:POT-Creation-Date: 2006-03-30 20:46+0200\n

Consequently all the following calls to po4a (without --force) try 
to update the PO file:

$ LC_ALL=C po4a -v fdim.3.cfg 
Updating po/fdim.3.pl.po: 
.. done.
17 translated messages.  

Best Regards,
robert


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (100, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/pdksh
Kernel: Linux 2.6.16
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)

Versions of packages po4a depends on:
ii  gettext   0.14.5-2   GNU Internationalization utilities
ii  libsgmls-perl 1.03ii-31  Perl modules for processing SGML p
ii  perl  5.8.8-3Larry Wall's Practical Extraction 
ii  perl-modules  5.8.8-3Core Perl modules
ii  sp1.3.4-1.2.1-47 James Clark's SGML parsing tools

Versions of packages po4a recommends:
ii  liblocale-gettext-perl1.05-1 Using libc functions for internati
ii  libterm-readkey-perl  2.30-3 A perl module for simple terminal 
ii  libtext-wrapi18n-perl 0.06-4 internationalized substitute of Te

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]