Re: shishi-0.0.30.pot file

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Hello Simon,
>
> Thanks for explaining.
>
>> Right now, I keep the *.po files in CVS (or Git), and often when I make
>> code changes, the *.po file changes too, modifying the line numbers.  I
>> don't know whether to commit the modified files or not to cvs.
>> Committing them will lead to an extremely large amount of silly commits
>> to my source base in *.po, just changing line numbers.  Using
>> --no-location removes most of the superfluous mofications.
>> ...
>> Is there some guidelines on how to use *.po with CVS?
>
> We don't have a perfect solution so far: I am committing PO files into
> CVS occasionally, whereas Paul prefers to fetch them from the TP site as
> part of "autogen.sh".

Since I'm often offline, and often rebuild from clean CVS/Git, fetching
them during autogen.sh would not work for me.

>> I have considered not putting *.po into VC at all, but instead having
>> *.po.in or similar in VC, copied to *.po before autoreconf is run.
>
> Can you try this patch? With this patch, and of course the removal of
> --no-location from po/Makevars, the POT file will contain the line number
> references, whereas the PO files in your source distribution won't.
>
> Since the shishi project is using the TP, translators will usually fetch
> the PO files from there; there the msgmerge process is done by the TP robot,
> and since you will submit a POT file with line numbers, the translator will
> get a PO file with line numbers. This means, the PO files in your source
> distribution don't really need to contain line number references.
>
> Bruno
>
> *** po/Makefile.in.in.bak     2006-10-24 22:52:10.000000000 +0200
> --- po/Makefile.in.in 2007-06-07 14:39:21.000000000 +0200

I don't store Makefile.in.in in CVS.  I tried adding

MSGMERGE = msgmerge --no-location
MSGMERGE_UPDATE = msgmerge --no-location --update

to Makevars instead, though, and it seems to work: shishi.pot contains
line numbers, and the translated files doesn't contain them.

I'll experiment with this for a while and see how it goes.  If it works
out well, I'll use the same approach in all of my projects.

/Simon