On Tue, Jun 28, 2005 at 07:44:23PM +0200, Francois Gouget wrote:
Currently the po references contain the file and line number:
#: ../wine-user-en-sgml/wine-user.sgml:82
../wine-user-en-sgml/glossary.sgml:171
What this means is that if someone adds a line near the beginning of
wine-user.sgml we will get thousands of lines of diff the next time
po4a-updatepo is run.
I know po tools can probably hide this issue from users (though that
doesn't help me since I use xemacs) but this is still going to be a
problem when comparing two CVS version of the po file. This is also a
big nuisance when trying to merge CVS branches. Look at the output of
the following command to see what I mean:
cvs diff -r1.4 -r1.5 po/pod/fr.po
Also I feel that references that include the line number are less useful
when translating documentation than when translating the strings used in
a program. The strings in a program are often pretty short, sometimes a
single word like 'Close' and searching for such strings is difficult due
to false positives. Thus for programs the line number information is
quite useful. But, when translating the documentation, each msgid is a
paragraph which usually contains at least a full sentence. So it's easy
to find the relevant place in the source SGML file by searching for a
sequence of two or three words.
I always play with -I^#: but I agree that this may be suboptimal, and with
your point in general.
So I propose to add a 'porefs' option to po4a-updatepo which
would allow
the user to control the addition of references. It would have three
possible values:
* none
No references are added
* noline
References are added but all line numbers are set to '1'. I'm
keeping a line number for compatibility with po tools let the user open
the relevant file by double clicking on the reference.
* full
This would be the default and work just as it does today.
Now, the logical place to implement this is the Po.pm module but it was
not possible to pass options to it. So I added a -O option which passes
options to the Po.pm module (via TransTractor,pm) instead of the format
module.
I don't really like it. Users shouldn't really care about whether the option
is for this part of the code or that one. Couldn't we seed the option set of
each modules from the transtractor code or such?
Let me know if this sounds ok or if another approach should be used.
I was about commiting this as is, and I then thought that I'll never have
the courage to do it right if I don't do so right now.
Mixing module options and "general" ones (ie, for Po.pm or so) would also
allow to add this feature to all binaries, not only updatepo. The price to
pay should only be to come up with a common way to handle options accross
modules and binaries (unless I missed something). That sounds doable.
I'll try to give it a spin tomorow.
Mt.