Incorrect Russian translation of "apt list --upgradeable" results

[Andrei Borzenkov]

bor@bor-Latitude-E5450:~$ apt list --upgradeable
Вывод списка… Готово
build/неизвестно 20161025 all [может быть обновлён до: 20151105]

In Russian this means "version 20161025 can be upgraded TO version 20151105)

While original English says exactly opposite:

bor@bor-Latitude-E5450:~$ LC_ALL=C LANG=C apt list --upgradeable
Listing... Done
build/unknown 20161025 all [upgradable from: 20151105]

Literal translation (that does not require serious phrase change) would probably be

"может быть обновлен с"

although it sounds also artificial, as in Russian subject is package that is being updated (currently installed), not new version.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apt 1.2.12~ubuntu16.04.1
ProcVersionSignature: Ubuntu 4.8.0-25.27~16.04.1-generic 4.8.1
Uname: Linux 4.8.0-25-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Sun Oct 30 09:39:47 2016
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-trusty-amd64-20140620-0
InstallationDate: Installed on 2015-07-02 (485 days ago)
InstallationMedia: Ubuntu 14.04 "Trusty" - Build amd64 LIVE Binary 20140620-04:25
SourcePackage: apt
UpgradeStatus: Upgraded to xenial on 2016-10-29 (0 days ago)

[Maxim Taranov (png2378)]

I can confirm that current translation is incorrect.

[Julian Andres Klode (juliank)]

And JFTR, I can confirm that the translations we ship with apt itself are correct, so this really is a language pack-only issue.

[Sergey Alyoshin (alyoshin-s)]

It is already fixed.

[Gunnar Hjalmarsson (gunnarhj)]

On 2016-10-31 07:42, Sergey Alyoshin wrote:
> It is already fixed.

Hmm.. So it seems, but still:

On 2016-06-02 the string was changed to "[возможно обновление с: %s]" in Launchpad:

https://translations.launchpad.net/ubuntu/xenial/+source/apt/+pots/apt/ru/100

The language-pack-ru-base package in xenial-updates was built on 2016-06-27, so that change ought to be reflected on an updated Xenial install.

However, for some reason it's not:

$ dpkg-query -W language-pack-ru-base
language-pack-ru-base 1:16.04+20160627
$ echo $(LANGUAGE=ru gettext -d apt '[upgradable from: %s]')
[может быть обновлён до: %s]

Upgrading the language-pack-ru package to the one in xenial-proposed does not help:

$ dpkg-query -W language-pack-ru
language-pack-ru 1:16.04+20161009
$ echo $(LANGUAGE=ru gettext -d apt '[upgradable from: %s]')
[может быть обновлён до: %s]

@Martin: I think this is something for you to take a look at.

[Maxim Taranov (png2378)]

Well, I converted /usr/share/locale-langpack/ru/LC_MESSAGES/apt.mo to po-file and I see this string:

msgstr "[возможно обновление с: %s]"

It is correct translation and I have no idea why apt doesn't use it.

[Gunnar Hjalmarsson (gunnarhj)]

Thanks for pointing out that, Maxim. (I should have thought of doing so.) So this is not a problem with the language pack generation, after all.

At this time I think the explanation is a combination of a few things.

To begin with, the apt package installs MO files in /usr/share/locale.

$ dpkg -L apt | grep ru.*mo$
/usr/share/locale/ru/LC_MESSAGES/apt.mo

Those MO files are apparently not updated in Xenial. At the same time gettext seems to pick those files at first hand, while using /usr/share/locale-langpack as fallback. (I thought that gettext should do it the other way around.) So the result is:

$ echo $(LANGUAGE=ru gettext -d apt '[upgradable from: %s]')
[может быть обновлён до: %s]
$ echo $(LANGUAGE=ru TEXTDOMAINDIR=/usr/share/locale-langpack \
> gettext -d apt '[upgradable from: %s]')
[возможно обновление с: %s]

If this gettext behavior is wrong, I suppose this should be fixed in gettext. If not, there is a need to update the translations in the apt package for Xenial.

[Julian Andres Klode (juliank)]

Ah right. It's fixed in 1.2.13 and newer, so see the relevant SRU bugs for those.

[Julian Andres Klode (juliank)]

SRU bugs = bug #1595177 and bug #1638021

[Gunnar Hjalmarsson (gunnarhj)]

Thanks for letting us know, Julian. That will hopefully bring more up-to-date translations, installed by apt in /usr/share/locale, into Xenial.

I'm going to follow up why gettext ignores the apt.mo files in /usr/share/locale-langpack.

[Julian Andres Klode (juliank)]

Yes, the translations are updated to relatively recent ones from 1.3~rc3 in 1.2.15. I still need to write down a "merge translations" script, as I forgot how I did it when I did that (otherwise we'd have the 1.3.1 translations already).

Basically what I'm doing is merge the 1.2 template with the 1.2 translations *and* the 1.3 translations, thus giving us updates for existing translations and adding any previously untranslated strings that exist in 1.2.

[Gunnar Hjalmarsson (gunnarhj)]

I talked with Martin Pitt, who let me know that it's intentional behavior that gettext gives precedence to /usr/share/locale over /usr/share/locale-langpack.

apt is one of those 'special' packages in main where the translations shipped with the source package are not stripped at build time. It means that the apt.mo files installed by the language packs are not effective (as we have already figured out). So in case of apt (and a few other special packages) translation updates need to go into the package to make a difference to the users.

@Julian: The Xenial template in Launchpad seems to have been updated 2016-03-25 (attached). The easiest (I think) way to get the actual translations is to download them from Launchpad, and simply replace the PO files in the package.

https://translations.launchpad.net/ubuntu/xenial/+source/apt/+pots/apt

There shouldn't be a need to manually merge as you described. (Possibly I have missed something.)

[Julian Andres Klode (juliank)]

The correct approach is to have gettext look into the langpack translations first, and then fall back to the package's translations. That's also the way it was explained to work: Packages ship initial translations for bootstrapping purposes, and those can be updated via language packs.

I have no intention to ship translations from Launchpad in apt. That would mean diverging from the upstream packaging, which I have no intention to, I'm happy we got that working without a diff now. If people want to help with the translations apt ships, they can do that _upstream_ (talk to the previous translators, and take over if they don't respond).

That said, even if I wanted to, merging the translations from launchpad would be a pain in the ass:

First of all, the translation templates are not remotely up-to-date (only since 1.3 there's a chance for Launchpad to import them, previous versions only had templates without any of the headers). Thus, Xenial does not have templates suitable for the apt version it ships with, but rather for 1.0something or similar.

Secondly, the translation templates in launchpad are the split ones - APT's build system requires a merged translation file of all domains.

What we can do, if neccessary, is fix translations in the stable branches for strings not in master. But that really needs review by the appropriate channels upstream as well. And especially for 17.04 and 17.10 - those will get the same release series as the next Debian stable release. For Ubuntu-only branches, we can probably relax the translation-ML-must-review requirement, but it seems a bit rude.

[Martin Pitt (pitti)]

> The correct approach is to have gettext look into the langpack translations first, and then fall back to the package's translations.

No, it's not. Normal/released Ubuntu packages get their translations stripped out of the debs. But if you install a backport, third-party package, or self-built package, you want to see the translation that it ships, not the Ubuntu translations as they now apply to an older version only. Hence /usr/share/locale/ must have precedence over /usr/share/locale-langpack/.

There are just a handful of packages which you need for upgrading and *installing* langpacks which have their translations built-in, like apt or language-selector.

[Julian Andres Klode (juliank)]

It might have been mixed up with additional translations. That is, a language missing in the package can still be translated by the language pack. I'm not entirely sure what the argument was back then anymore, but something like that was how it was explained to me.

OK let's be clearer: I want the ability to have translations in apt prefer those from the langpack, if we ever manage to properly import templates into launchpad (nobody seems to really respond to my inquiries about that in IRC).

Or rather: Give me an option to tell gettext to prefer the translations file with more translations: At the beginning, apt will likely ship a more complete one, but as time goes on, the language pack can be easily updated.

[Gunnar Hjalmarsson (gunnarhj)]

On 2016-11-04 10:01, Julian Andres Klode wrote:
> I want the ability to have translations in apt prefer those from the
> langpack,

I suppose it would be possible to special case apt in Ubuntu by patching bindtextdomain() in apt-pkg/init.cc. Not able to tell if it's a good idea.

[Julian Andres Klode (juliank)]

That sounds like an interesting idea.

[Julian Andres Klode (juliank)]

This should actually be fix released. It's also fixed in xenial now with 1.2.15 being in -updates now