Re: automake po / pot file integration: when to merge the PO files?

[Roger Leigh]

On Mon, Sep 06, 2010 at 11:25:44AM +0200, Bruno Haible wrote:
> Hi,
> 
> One issue still needs discussion within the planned po / pot file
> integration [1]:
> When should the PO files that are distributed be merged with the POT file?

Just a few comments from a long-time gettext+automake user which
I hope might be useful:

The number one problem for me (as you identified) is the huge churn
in po file content as you make source changes.  I'd like to suggest
that the best way to tackle the problem is to simply stop generating
the source file/line number comments by default; I'm already doing this
in some of my projects by adding "--no-location" to XGETTEXT_OPTIONS
in po/Makevars.  It's a massive improvement.

Making this small change has a huge impact.  po file changes are now
sensible: they match source string changes only, not massive line
renumbering because I added/removed some unrelated code.  This makes
merging between branches sensible because I don't have an entire po
file full of line number conflicts I can't hope to merge manually.

A question I have is "what purpose does having the line number and
source file serve"?  Do those benefits outweigh the massive
disadvantages?  And if the original source file(s) for a string
need to be found, grep(1) is pretty fast.  At least for me, the
translators get mailed the po file, and never look at the source,
so it's not of *any practical benefit* to anyone AFAICS; I've
certainly had no complaints since I turned them off.


With this change made, I would be fully in favour of having
"update-po" run by default so that the po files are always kept
up-to-date.  In this situation, it makes sense--the po file changes
are *entirely related* to the source changes, and can be committed
together.

Updating the po files by default also makes releases easier:
if I tag a release and then "make dist" and find all the po
files were updated, modifying the repository, I need to
detag, commit the changes and retag.  Updating by default means
the repository is always in a "releasable state" whereby any
revision can be tagged without doing additional sanity checks.


Regards,
Roger 

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

signature.asc
Description: Digital signature