Follow-up Comment #3, bug #50910 (project gettext):
Thanks for explaining. Now I understand.
The point of keeping the history is precisely to save some work from the
translator in such situations. The question is how much work you want to save
her:
a) If you think the translator should review the reappeared message with its
translation, then what we need is a new msgmerge option that, when
transitioning a message from the "obsolete" state to the "active" state, marks
it fuzzy. This option should then be used both in "Damned Lies" and in
po/Makefile.in.in.
b) If you think the translator should have no work at all with the reappeared
message, then the current behaviour of "Damned Lies" is fine, and the problem
is that what you put or commit into the po/ directory is the UNMERGED PO file
from the translator.
It was never the intention that .mo files get generated from the UNMERGED PO
files.
The po/Makefile.in.in has a target 'update-po' that merges the PO files with
the current POT file. Possibly you don't invoke this target? (Either because
your testers work off the version control repository? Or because this
'update-po' target causes trouble with version control?) In this case, what
you would need is a Makefile.in.in that invokes msgmerge lazily, on the fly,
right before msgfmt.
a) or b)?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?50910>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
