custom (pgk) translations preempted by lang pack

[Kyle Nitzsche]

Binary package hint: grub2

Lucid.

I needed to customize translations to pick up new strings introduced into source.

My customized version of grub2 was based on 1.98-1ubuntu6.

I made changes to pot & po files in po/. My expectation was that on install of grub-pc, those po files would become mo files here: /boot/grub/locale/<lang>.mo, thus making the custom translations available at run time. However, I found that if there is a grub.mo file installed by lang packs (in /usr/share/locale-langpack/<lang>/LC_MESSAGES/grub.po, then it would be copied during install to /boot/grub/locale/<lang>.mo. This causes custom package translations to be overriding by lang packs, which is not desirable, I believe. Instead, the package should be able (like other packages) to install its own translations with them overriding any that may be delivered by language packs, and in this way, enabling package customization.

I traced the problem down to a script: util/grub-install.in

This script gets mo files if they exist in the lang packs or the package dir and copies them over.

The solution (see patch), is to split this into two movements:
 1) first copy lang pack mo files, if any
 2) then copy package mo files, if any
Thus the package will preempt language packs.

[Colin Watson (cjwatson)]

No, this is precisely backwards from how the language pack system is designed and how it works elsewhere in Ubuntu. Language packs are supposed to beat packaged translations.

Now, this works in Ubuntu because packaged translations are imported into Launchpad and then circle back to language packs. For customised projects, I would say that it's appropriate to make this sort of change, but I would rather not do so for Ubuntu.

I'd consider something that msgmerged the two translations so that you got language-pack translations in preference where they exist but also got a fallback to packaged translations where the language pack simply doesn't have the strings at all, although grub-pc doesn't depend on gettext at the moment and I'm slightly worried about introducing a dependency on a development package. Still, I think this would be a better approach.

[Kyle Nitzsche (knitzsche)]

Generally, language pack-delivered translations are pre-empted by packaged translations at run-time.

That is, if you install a deb that has mo files, they install to /usr/share/locale/.

mo files installed by lang packs go here: /usr/share/locale-lanpack/.

(mo files are stripped from pkgs in main, so they don't land in the 'pkg' dir: /usr/share/locale/.)

gettext (through a modification to glibc, I think) in Ubuntu looks in the pkg location first, then, if not found, falls back to the langpack location.

This enables users to install customized or non-Ubuntu versions of packages that may have different strings and get the corresponding customized translations. While in the vast majority of cases, where no customized pkg is installed but just the from main is, the lang pack translations are used. (This is the mechanism OEM has relied upon for years.)

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]