Bug 621946 - msgfmt -C/--compendium gets confused by existing fuzzy translations
Summary: msgfmt -C/--compendium gets confused by existing fuzzy translations
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gettext
Version: 13
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-06 15:22 UTC by Nils Philippsen
Modified: 2011-02-06 23:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-06 23:55:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Bzipped tarball containing a testcase. (4.82 KB, application/x-bzip)
2010-08-06 15:22 UTC, Nils Philippsen
no flags Details

Description Nils Philippsen 2010-08-06 15:22:58 UTC
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 23:54:15 UTC
Thanks for the report.

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

Is this a regression relation to 0.17 or an old issue?

Comment 2 Nils Philippsen 2010-08-19 12:29:57 UTC
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 05:50:25 UTC
Thanks for testing.

I reported the issue upstream to the mailing-list.

Comment 5 Jens Petersen 2010-08-30 01:46:21 UTC
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 15:53:33 UTC
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 23:31:17 UTC
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-09-01 01:17:12 UTC
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 08:43:46 UTC
(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 23:55:42 UTC
Ok - time has passed.  I'm going to close this now
since it has been reported and discussed upstream.


Note You need to log in before you can comment on or make changes to this bug.