Red Hat Bugzilla – Bug 621946
msgfmt -C/--compendium gets confused by existing fuzzy translations
Last modified: 2011-02-06 18:55:42 EST
Created attachment 437180 [details]
Bzipped tarball containing a testcase.
Description of problem:
When trying to update older versions of po files with translations submitted to a newer version I found that "msgfmt -C/--compendium <new_po_file> <old_po_file> <project_pot_file>" gets confused by fuzzy translations in the old po file and doesn't use the updated translations from the new po file for these msgids.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Untar attached testcase: "tar -xjf gettext-msgmerge-compendium-problem.tar.bz2"
2. "cd gettext-msgmerge-compendium-problem"
msgmerge -C compendium-zh_TW.po /dev/null system-config-services.pot > devnull-zh_TW.pot
msgfmt -cvo /dev/null devnull-zh_TW.pot
57 translated messages.
msgmerge -C compendium-zh_TW.po old-zh_TW.po system-config-services.pot > old-zh_TW.pot
msgfmt -cvo /dev/null old-zh_TW.pot
55 translated messages, 2 fuzzy translations.
When using the compendium file and the existing old translation file, it should use the translation found in the compendium file for all msgids, even those marked fuzzy.
Thanks for the report.
Is it possible you can report it upstream at firstname.lastname@example.org?
Otherwise I will do it...
Is this a regression relation to 0.17 or an old issue?
I've tried out gettext-0.17-16.1.fc13.x86_64 which has the same behavior.
I've also tried to build older versions of gettext (from v0.11 on), but apparently gettext has a rather byzantine build system -- autogen.sh and configure regularly failed with the most entertaining error messages:
*** YOU'RE USING automake (GNU automake) 1.11.1.
*** KDE requires automake 1.6
./xsmallpot.sh: line 24: configure.in: No such file or directory
make: *** [hello-c++-kde.pot] Error 1
checking for bison... bison -y
./configure: line 4369: gt_JAVA_CHOICE: command not found
./configure: line 4371: syntax error near unexpected token `1.3,'
./configure: line 4371: `gt_JAVACOMP(1.3, 1.1)'
configure: error: ./configure failed for gettext-runtime
=== configuring in gettext-tools (/home/nils/src/gettext/gettext-tools)
configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr/local' --cache-file=/dev/null --srcdir=.
./configure: line 2236: syntax error near unexpected token `gettext-tools,'
./configure: line 2236: `AM_INIT_AUTOMAKE(gettext-tools, $VERSION_NUMBER)'
configure: error: ./configure failed for gettext-tools
TLDR: I haven't been able to build the older versions and check with them, sorry.
Thanks for testing.
I reported the issue upstream to the mailing-list.
Bruno thinks this is not a bug. So maybe we can close this?
I've replied to Bruno's mail:
...[T]hat's probably because I used -C in a different way than originally intended, namely to merge new translations that are made in the master branch of a project into an older version (using SCMs to merge PO files is rather unpleasant). In this case, I'd rather have the non-fuzzy translation for the same msgid from the compendium file (which really is the same file, just from the up-to-date master branch) than the fuzzy translation in the older branch.
Would you accept a patch which lets users specify that msgmerge should prefer the compendium file (maybe using a different term than "compendium")? Perhaps rather using mostly the same code, but having a "--update-file" option which acts like "-C" except for the differences I described?
Thanks - if you want to keep this open to track this RFE
that's fine. Are you planning to submit a patch? :)
I'd think this is not a bug and '-C' would mean to a reference but not override.
If your original po includes 'fuzzy' and would like to remove it, you could use msgattrib for the original po before you would run msgmerge.
(In reply to comment #7)
> Thanks - if you want to keep this open to track this RFE
> that's fine. Are you planning to submit a patch? :)
As I replied to Bruno -- if they're willing to accept a patch, I'll give it a shot, it shouldn't be that hard. I think the most challenging thing is to decide whether a) an option should be added that affects the operation of other -C/--compendium options on the command line or b) an option should be added that uses a supplied file for translation, but prefers non-fuzzy translations in that file, i.e. not a compendium but a translation update file.
(In reply to comment #8)
> I'd think this is not a bug and '-C' would mean to a reference but not
> If your original po includes 'fuzzy' and would like to remove it, you could use
> msgattrib for the original po before you would run msgmerge.
Bruno has already described that in his mail, but it's a bit complicated and hard to remember in the few cases when you need it.
Ok - time has passed. I'm going to close this now
since it has been reported and discussed upstream.