Red Hat Bugzilla – Full Text Bug Listing
|Summary:||msgfmt -C/--compendium gets confused by existing fuzzy translations|
|Product:||[Fedora] Fedora||Reporter:||Nils Philippsen <nphilipp>|
|Component:||gettext||Assignee:||Jens Petersen <petersen>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||i18n-bugs, petersen, tfujiwar|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-02-06 18:55:42 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 firstname.lastname@example.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: *** [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 4 Jens Petersen 2010-08-20 03:42:06 EDT
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.