bugGNU gettext - Bugs: bug #50910, Makefile.in.in should produce...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #50910: Makefile.in.in should produce up-to-date .mo files even when target 'update-po' is never invoked

Submitter:  Claude Paroz <claudep>
Submitted:  Tue 02 May 2017 07:34:40 AM UTC
   
 
Category:  Programmer tools Severity:  4 - Important
Item Group:  None Status:  Fix Released
Privacy:  Public Assigned to:  haible
Open/Closed:  Closed

Jump to the original submission

Thu 09 May 2019 07:28:29 PM UTC, comment #9: 

The fix is contained in the gettext-0.20 release.

Bruno Haible <haible>
Group administrator
Thu 25 Oct 2018 06:32:29 AM UTC, comment #8: 

Thanks, great work!

Claude Paroz <claudep>
Thu 25 Oct 2018 01:55:50 AM UTC, comment #7: 

Implemented through https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=c08db47a43a55646d94e5ffa082891a718346520

The DIST_DEPENDS_ON_UPDATE_PO option turned out to be unrelated to this issue, after all.

Bruno Haible <haible>
Group administrator
Mon 15 May 2017 12:26:43 PM UTC, comment #6: 

The DIST_DEPENDS_ON_UPDATE_PO option is also relevant to this discussion.

Bruno Haible <haible>
Group administrator
Wed 03 May 2017 10:51:28 AM UTC, comment #5: 

Thanks for the reply.

Changing the subject. We need a Makefile.in.in that invokes msgmerge lazily, on the fly, right before msgfmt. (But it should ensure that the POT file is up-to-date.) This msgmerge invocation should be fast; this is feasible because it does not need to do fuzzy matching.

Bruno Haible <haible>
Group administrator
Wed 03 May 2017 07:09:37 AM UTC, comment #4: 

For me, that's clearly b).

I also understand the possible confusion concerning the build process. I think that during the recent years, build toolchains in the GNOME world partially lost the habit/interest to do more than compiling the .po to .mo files for app's i18n (to be confirmed, I'm not a desktop developer). This is partially due to the fact that developers are trusting po files committed by translators which are generally up-to-date, thanks to our l10n.gnome.org-offered workflow. So they may not run a .po/.pot merge process during their build stage (which would have resolved our original use case). An other factor to take into account is also a growing diversity of build tools (cmake, meson, ...).

Claude Paroz <claudep>
Tue 02 May 2017 09:25:33 PM UTC, comment #3: 

Thanks for explaining. Now I understand.

The point of keeping the history is precisely to save some work from the translator in such situations. The question is how much work you want to save her:

a) If you think the translator should review the reappeared message with its translation, then what we need is a new msgmerge option that, when transitioning a message from the "obsolete" state to the "active" state, marks it fuzzy. This option should then be used both in "Damned Lies" and in po/Makefile.in.in.

b) If you think the translator should have no work at all with the reappeared message, then the current behaviour of "Damned Lies" is fine, and the problem is that what you put or commit into the po/ directory is the UNMERGED PO file from the translator.

It was never the intention that .mo files get generated from the UNMERGED PO files.

The po/Makefile.in.in has a target 'update-po' that merges the PO files with the current POT file. Possibly you don't invoke this target? (Either because your testers work off the version control repository? Or because this 'update-po' target causes trouble with version control?) In this case, what you would need is a Makefile.in.in that invokes msgmerge lazily, on the fly, right before msgfmt.

a) or b)?

Bruno Haible <haible>
Group administrator
Tue 02 May 2017 07:32:20 PM UTC, comment #2: 

OK, I'll try!

Time t: a module is translated at 100% in language ll. The committed ll.po contains some unused obsolete strings (from previous history).

Time t+1: the source code changes and adds a new string which maps exactly to one of the ll.po obsolete strings.

Damned Lies is our tracking application at https://l10n.gnome.org which always provides up-to-date po files by merging them with the latest pot file. As the merged file was able to reuse an obsolete string, the stats are still at 100%, so the translator doesn't care to update and commit ll.po.
However, the compiled .mo file will not contain the "missing" new string until the translator commit a fresh ll.po (with the obsolete string "de-obsoleted").

If msgmerge would tell in its verbose output that some obsolete strings we reused during the merge operation, our application would be able to detect that issue and add a notice to translators that the merged file needs to be committed in the software repository, albeit it shows stats at 100%.

I hope I was able to clarify the issue!

Claude Paroz <claudep>
Tue 02 May 2017 07:15:03 PM UTC, comment #1: 

Please, can you explain the use case in your own words? I read through https://bugzilla.gnome.org/show_bug.cgi?id=781933 and still don't understand it:

How does the workflow look like? (What are the files that get transmitted between different persons? What are the operations that are performed by the different persons?)

Who is "Dammed Lies"?

Where are obsoleted messages manipulated?

What decision is taken based upon the "Read 1 old + 1 reference, merged 325, fuzzied 0, missing 0, obsolete 65." output?

Bruno Haible <haible>
Group administrator
Tue 02 May 2017 07:34:40 AM UTC, original submission:  

When merging an old def.po with a new ref.pot, the msgmerge verbose output (e.g. "Read 1 old + 1 reference, merged 325, fuzzied 0, missing 0, obsolete 65.") doesn't indicate when an obsolete string (prefixed with #~) is reused from def.po.

This would be very helpful so the merge tool could detect if the resulting po file still needs to be committed by the translators, even if the stats of that merged file shows that it's 100% translated.
Read about our use case here: https://bugzilla.gnome.org/show_bug.cgi?id=781933

Claude Paroz <claudep>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by claudep (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-04 haible StatusFixed Fix Released
    2018-10-25 haible StatusConfirmed Fixed
        Assigned toNone haible
        Open/ClosedOpen Closed
    2018-01-06 haible Severity3 - Normal 4 - Important
    2017-05-03 haible CategoryNone Programmer tools
        StatusNeed Info Confirmed
        SummaryIndicate reused strings in msgmerge verbose output Makefile.in.in should produce up-to-date .mo files even when target 'update-po' is never invoked
    2017-05-02 haible CategoryPO, POT None
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code