Thu 22 Dec 2011 03:48:36 AM UTC, comment #4:
Oops, I now see that the original post of this problem came from the POEdit problem http://www.poedit.net/trac/ticket/415
And that the POEdit folks have accepted the documentation bug solution as final, and are trying to figure out another way to use the gettext tools. Apparently the only real downside they've seen to removing the use of --use-first in the msgcat invocation is that it keeps accumulating more junk in the po file's header.
So I guess POEdit usage isn't a valid rationale for changing the behavior instead of the documentation. But I still don't understand why it wouldn't be at least mildly preferable in all use cases if it worked as originally documented :-)
|
Thu 22 Dec 2011 03:25:07 AM UTC, comment #3:
I understand the words in the resolution of this as a documentation problem, but I don't follow the rationale.
Translations, comments, and extract comments are produced by translators, and so it is logical that the "--use-first" option would take these items from the first PO file to define them for a given msgid: that gives a precedence order to the work produced by the translators. But the list of source code locations at which a given msgid was detected by xgettext has nothing to do with the work of the individual translators; it is a property of the collection of text files being translated. Why does it make sense to ignore some of the locations containing a given msgid just because they were not seen by the preferred translator? I would think that knowing all of the locations containing a particular msgid is important to judging the quality of a translator's work.
The reason this is important to me is that I'm using POEdit (1.4.6) on Windows. When POEdit performs a scan of the source trees for new and obsolete msgids, it invokes xgettext with the --force-po option on list-length-limited groups of files to produce one .po file per group of sources. And then it invokes msgcat with --use-first to merge the several new .po files into the existing one. I had been relying on being able to context-click a particular message in the final resulting po in order to bring up a list of all occurrences of the message, and browse each one as needed to decide if the translation was appropriate in all circumstances. With msgcat --use-first not cumulating the file location information, the list of locations I see for browsing is sometimes incomplete. And in fact it's somewhat arbitrarily incomplete, as it depends on the total number of files being scanned and the order in which they're scanned, as to which length-limited list of sources being scanned by one invocation of xgettext will contain the first occurrence of a given msgid, and which other sources containing that msgid will get scanned in that same invocation of xgettext.
I hope that makes sense. If so, it represents one reason why not cumulating the location information causes a real-life practical problem for the use-case of using POEdit. In the documentation-bug description, it sounded like the reasoning was that cumulating the location information didn't seem to be important for the expected non-POEdit use-case; but I didn't understand it to say that cumulating the location information would cause a real-life problem in that expected use-case, either, so changing the behavior to match the documentation might be better for users...
I guess I could try hacking the msgcat invocation in POEdit not to pass the --use-first option to msgcat, but I suspect that the authors of POEdit used it for a reason; so I'm a little concerned I might start losing or regressing translations if I do that. And of course I could try modifying the behavior of --use-first myself, but I'm totally unfamiliar with the code base, am on Windows with Cygwin and haven't built anything from source, and am a little rusty with C coding; so that seems high risk :-) Plus I suspect that other users of POEdit may be being impacted by this but just haven't noticed yet - the translation behavior is fine, you just sometimes get an incomplete list of sources containing a given msgid.
|
Wed 13 Apr 2011 10:26:24 PM UTC, comment #1:
Thanks for the report.
It's actually a documentation bug. The use-case for
"msgcat --use-first" is to merge two translations by
different translators (or different versions of translations),
giving priority to one of them. Cumulating the file positions
is not needed here.
For POT files, it is better to use "msgcat" instead of
"msgcat --use-first".
So, the program works right. Just the documentation was wrong.
Fixed through the attached patch.
(file #23236)
|
Wed 13 Apr 2011 05:43:41 PM UTC, original submission:
Hi folks,
I seem to have found a problem in msgcat. When merging two files, that contain a duplicate message, using --use-first flag, only the file positions from the first file get used. Unless I'm reading the manpage wrong, the resulting file should contain the translation, comments, etc. from the first file only, but the file positions merged from both files. This is what msgcat(5) says:
> Translations, comments and extract comments will be
> cumulated, except that if --use-first is specified, they
> will be taken from the first PO file to define them.
> File positions from all PO files will be cumulated.
Here's a quick way to reproduce the problem. Note that both file positions are present when calling msgcat without --use-first, but only one when calling it with --use-first.
matthijs@grubby:~$ echo 'gettext("foo");' >> a.c
matthijs@grubby:~$ echo 'gettext("foo");' >> b.c
matthijs@grubby:~$ xgettext -L C -o a.pot a.c
matthijs@grubby:~$ xgettext -L C -o b.pot b.c
matthijs@grubby:~$ sed -i s/CHARSET/ASCII/ a.pot b.pot
matthijs@grubby:~$ msgcat -o - a.pot b.pot
# <header removed for bugreport>
#: a.c:2 b.c:2 msgid "foo" msgstr ""
matthijs@grubby:~$ msgcat -o - --use-first a.pot b.pot
# <header removed for bugreport>
#: a.c:2 msgid "foo" msgstr ""
I'm not completely sure if this is really a bug in msgcat, but if not then it's at least a documentation for the manpage :-)
|