Bug 621946

Summary: msgfmt -C/--compendium gets confused by existing fuzzy translations
Product: [Fedora] Fedora Reporter: Nils Philippsen <nphilipp>
Component: gettextAssignee: Jens Petersen <petersen>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 13CC: i18n-bugs, petersen, tfujiwar
Target Milestone: ---Keywords: MoveUpstream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-06 18:55:42 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Bzipped tarball containing a testcase. none

Description Nils Philippsen 2010-08-06 11:22:58 EDT
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):
gettext-0.18.1.1-1.1.fc13.x86_64

How reproducible:
Reproducible

Steps to Reproduce:
1. Untar attached testcase: "tar -xjf gettext-msgmerge-compendium-problem.tar.bz2"
2. "cd gettext-msgmerge-compendium-problem"
3. "make"
  
Actual results:
nils@gibraltar:~/tmp/gettext-msgmerge-compendium-problem> make
msgmerge -C compendium-zh_TW.po /dev/null system-config-services.pot > devnull-zh_TW.pot
...... done.
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
......... done.
msgfmt -cvo /dev/null old-zh_TW.pot
55 translated messages, 2 fuzzy translations.

Expected results:
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.

Additional info:
Comment 1 Jens Petersen 2010-08-18 19:54:15 EDT
Thanks for the report.

Is it possible you can report it upstream at bug-gnu-gettext@gnu.org?
Otherwise I will do it...

Is this a regression relation to 0.17 or an old issue?
Comment 2 Nils Philippsen 2010-08-19 08:29:57 EDT
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[1]: *** [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.
Comment 3 Jens Petersen 2010-08-20 01:50:25 EDT
Thanks for testing.

I reported the issue upstream to the mailing-list.
Comment 5 Jens Petersen 2010-08-29 21:46:21 EDT
http://lists.gnu.org/archive/html/bug-gnu-utils/2010-08/msg00055.html

Bruno thinks this is not a bug.  So maybe we can close this?
Comment 6 Nils Philippsen 2010-08-31 11:53:33 EDT
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?
Comment 7 Jens Petersen 2010-08-31 19:31:17 EDT
Thanks - if you want to keep this open to track this RFE
that's fine.  Are you planning to submit a patch? :)
Comment 8 fujiwara 2010-08-31 21:17:12 EDT
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.
Comment 9 Nils Philippsen 2010-09-01 04:43:46 EDT
(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
> 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.

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.
Comment 10 Jens Petersen 2011-02-06 18:55:42 EST
Ok - time has passed.  I'm going to close this now
since it has been reported and discussed upstream.