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

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

( Jump to the original submission)

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>
Project 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>
Project 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>
Project 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>
Project 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>


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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.3