LP refuses to import plural strings where e.g. msgstr[0] entries in PO file miss %d

The template provides two alternatives in those cases, a singular and a plural, while some upstream Czech translator has provided three alternatives, for instance:

msgstr[0] "před minutou"
msgstr[1] "před %d minutami"
msgstr[2] "před %d minutami"

So LP refuses to import, and is apparently confused also when you try to fix it via the LP GUI.

I think you should resolve this with the upstream Czech translator(s).

In the meantime you may want to make an experiment: Download the Czech PO file, add translations for msgstr[0] and msgstr[1], remove the lines with msgstr[2], and upload the modified PO file manually.

I think this is rather a Launchpad issue. The msgstr[2] is commonly used in GNOME pofiles in our (Czech) language and for example in this case the msgstr[1] and msgstr[2] for "%d years ago" are different. I manually edited and uploaded the pofile, feel free to review it.

I approved, and it was imported with the very same errors.

It may well be a LP problem. Can you please file an issue at <https://rt.ubuntu.com>?

I opened a bug task for Launchpad itself.

I also picked the Czech .mo file, which was stripped during the build of gnome-shell, and uncompiled it. And indeed it includes msgstr[2] entries.

There was a long IRC discussion about this issue yesterday:

https://irclogs.ubuntu.com/2018/03/28/%23ubuntu-devel.html#t12:21

I proved to be wrong about what has been causing the import failures: It's not the msgstr[2] entries, but the missing %d in the msgstr[0] entries.

However, the latest gettext version allows such missing %d, while the xenial gettext version does not, and that has been preventing these strings from being imported.

The plan is to upgrade the xenial gettext version in LP and with that solve the problem for both gnome-shell and other affected packages. Hopefully that can be done in due time and proved to work. If not, we also identified a possible workaround which would require certain modifications of the .pot files in all affected packages.

Assigning myself to the Ubuntu Translations bug task for now to more easily monitor the progress.

William, I guess you set as incomplete for launchpad before the IRC discussion? Seems the consensus was to try to backport the newest gettext and make launchpad use it, Colin started poking at that it seemed?

The build of gnome-shell 3.28.0-0ubuntu4 was not sufficient to fix this. The POT file without javascript comments was imported, but LP still complained about the PO files for the affected languages.

The upstream PO files have those javascript comments too. As a test I took the upstream Czech file, removed the javascript comments, and uploaded manually. Imported without errors.

Next thought: Was the first failure about timing, i.e. did LP use the info in the old template to validate the PO files? To test that I took the upstream Serbian file and uploaded it manually without removing the javascript comments. Imported without errors.

Conclusion: A no-change rebuild ought to be sufficient to fix it in gnome-shell for the other affected languages.

@AsciiWolf: Do you have an idea which other packages besides gnome-shell suffer from this kind of translation import problem?

This bug was fixed in the package gnome-shell - 3.28.0-0ubuntu4

---------------
gnome-shell (3.28.0-0ubuntu4) bionic; urgency=medium

  * debian/rules:
    - Drop javascript comments in gnome-shell.pot so the currently used
      version of gettext in LP gets more permissive wrt cases where
      the number of %d modifiers in a translation differs from what's
      in msgid (LP: #1756547).

 -- Gunnar Hjalmarsson <email address hidden> Fri, 06 Apr 2018 15:58:00 +0200

@gunnarhj: Sorry, no idea. The only package where I have seen this issue is gnome-shell.

To the sponsor: Another upload needed; a no-change build is sufficient.

This bug was fixed in the package gnome-shell - 3.28.0-0ubuntu5

---------------
gnome-shell (3.28.0-0ubuntu5) bionic; urgency=medium

  * No-change rebuild for translations (LP: #1756547)

 -- Gunnar Hjalmarsson <email address hidden> Sat, 07 Apr 2018 15:58:00 +0200

Could we also add gettext to this bug so that we can monitor when it will be fixed on that side and thus remove the ubuntu workaround?

@Marco: The issue was caused by the fact that LP used an older (xenial) version of gettext. So as soon as they upgrade, it should be possible to drop the workaround. Can't tell if they have done that yet; easiest to ask Colin or William.

Re-opening — see bug #1941954

Sorry for taking so long to get round to this; it had entirely fallen off my list. We haven't upgraded gettext from xenial's version yet, but I've started preparing a backport in https://launchpad.net/~cjwatson/+archive/ubuntu/launchpad/+packages.

https://portal.admin.canonical.com/C132790 (internal ticket)

This should now be fixed on Launchpad's end: we're running the gettext backport that you can see in https://launchpad.net/~canonical-is-sa/+archive/ubuntu/launchpad/+packages. Could you please try reverting the workaround and make sure that things work properly now?

I uploaded gnome-shell without the workaround.

The original problem, i.e. refusal to import msgstr[0] strings without %d, is not present any longer.

It complains about the Turkish PO file, but those complaints are probably motivated due to absent msgstr[1] lines in the upstream PO.

Other complaints, which were there also when the workaround (i.e. deleted "#, javascript-format" lines in the POT) was in place, are about strings which are no longer in the POT, and hence don't matter much. @Colin: Does LP really try to import such strings?

I'm not sure I'm really following the exact question here. Could you attach the message you got with the complaints?

Go to:

https://translations.launchpad.net/ubuntu/impish/+source/gnome-shell/+imports

and open the info for e.g. po/kk.po. It tells you that this part from the PO file was not imported:

#~ msgid "%d new message"
#~ msgid_plural "%d new messages"
#~ msgstr[0] "%d жаңа хабарлама"

#~ msgid "%d new notification"
#~ msgid_plural "%d new notifications"
#~ msgstr[0] "%d жаңа ескерту"

But those entries are marked with '#~', i.e. they are old entries from a previous version of the template. So what I'm wondering is if it's sensible that LP validates and tries to import such entries.

Launchpad intentionally imports even obsolete messages, although they're tagged internally as obsolete and filtered out for various purposes. I think this is so that they can be used as suggestions in some cases (for example, a similar message might still be used in another context). For that sort of purpose it can still be useful to know that the messages don't parse correctly, because they couldn't be used directly as suggestions without fixing the mistakes.

This is likely part of some work that was never completed, e.g. https://bugs.launchpad.net/launchpad/+bug/281165 and https://blueprints.launchpad.net/launchpad/+spec/rosetta-fuzzy-merge.

(Note that I'm reverse-engineering this from the code and from my general understanding of translations, rather than with direct information from the people who wrote the code.)

I can see that it might be useful to at least exclude errors about obsolete messages like this from translation import failure emails. If you agree, could you file a separate bug about that?

This bug was fixed in the package gnome-shell - 40.2-1ubuntu6

---------------
gnome-shell (40.2-1ubuntu6) impish; urgency=medium

  * d/rules:
    - Drop dh_translations workaround. gettext used by LP has been
      updated (LP: #1756547).
    - Fix Lintian warning about DEB_HOST_ARCH assignment

gnome-shell (40.2-1ubuntu5) impish; urgency=medium

  * Fix translation issues (LP: #1941954):
    - Really fix translation import problem as reported in LP: #1756547
    - Add libgtk-3-bin to Build-Depends for dh_translations

gnome-shell (40.2-1ubuntu4) impish; urgency=medium

  * debian/rules:
    - Skip tests when building for ppc64el to fix FTBFS (LP: #1941792)

gnome-shell (40.2-1ubuntu3) impish; urgency=medium

  [ Daniel van Vugt ]
  * Add layout-Make-starting-in-the-overview-optional.patch:
    - So that extensions like Ubuntu Dock have the option of preventing
      the shell starting in the overview. (LP: #1940925)

gnome-shell (40.2-1ubuntu2) impish; urgency=medium

  [ Daniel van Vugt ]
  * Add workspace-Remove-skip-taskbar-windows-while-the-over.patch to stop the
    desktop icons window appearing like an app window in the overview on
    startup (LP: #1936643)

 -- Gunnar Hjalmarsson <email address hidden> Wed, 01 Sep 2021 15:44:38 +0200