Snaps built from deb can't be gettext translated

Status changed to 'Confirmed' because the bug affects multiple users.

help2man ships a little hack (http://paste.ubuntu.com/16923611/) to preload a modified bindtextdomain() over the original one ... while this is ugly, it actually seems to work ... http://paste.ubuntu.com/16925059/

Applications written in QML using the ubuntu UI toolkit and the desktop/qt5 part should be covered: the desktop-launch script sets the APP_DIR environment variable to the value of $SNAP¹, and UbuntuI18n::setDomain(…) calls bindtextdomain() with $APP_DIR/share/locale².

However I’m not seeing this work. Testing with a snap of webbrowser-app, the compiled translations are correctly packaged under $SNAP/share/locale/[lang]/LC_MESSAGES/webbrowser-app.mo, however the UI appears untranslated.

¹ https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific#L29
² https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/src/Ubuntu/Components/plugin/i18n.cpp#L117

I’ve managed to get translations loaded by my application, doing the following two things:

 - added locales-all to stage-packages

 - "export LOCPATH=$SNAP/usr/lib/locale" in launcher script

And I’ve submitted this workaround against the desktop-helpers so that all desktop apps using them can benefit from it: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/12.

Status changed to 'Confirmed' because the bug affects multiple users.

Re-iterating what I said in the proposed work-around: locales-all weighs in at 127M. I think we need to have the language pack discussion rather than blowing up the size of the platform snap(s).

@christian can I ask you to drive this langpack discussion

I stumbled into this issue via <http://askubuntu.com/q/836483>, and if I understand it correctly the issue is primarily not due to Ubuntu's language packs. In the case of VLC, the accepted answer at Ask Ubuntu indicates that modifying bindtextdomain() when building the program would be sufficient.

It's both. LOCPATH needs to be set when launching the application because otherwise an absolute path will be used. And locales-all contains data such as time and date formats or how to deal with numbers.

I created a proof of concept snap providing the same languages available on the click-based phone images. That brings the 127M of installed size down to 34.5M - the snap (as noted in https://github.com/ubuntu/snapcraft-desktop-helpers/pull/12) is indeed a mere 3.5M, which is nice for OTAs, but it grows when unpacked. Just to highlight why there's different numbers being talked about.
https://code.launchpad.net/~ubuntu-sdk-team/+snap/ubuntu-language-pack-base

note that snaps do not get unpacked, they get mounted as-is (compressed) ... so the unpacked size should not really matter..

Perhaps I'm thinking about it wrong - but the uncompressed data has to reside in memory at least? Even if it's not "on disk" per se. So having an extra 100M in memory could still be quite bad.

Responding to my own comment: indeed we only need to count the memory used by individual files accessed by a snap on top of the compressed size on disk. Which for a single locale is negligible. So it's worth re-considering including the locales with each platform snap.

This will be in the next UAP edge upload, which is though delayed for other reasons.

(in edge these days)