Snaps built from deb can't be gettext translated

Bug #1576282 reported by Sebastien Bacher on 2016-04-28
82
This bug affects 17 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Christian Dywan
Snapcraft
Undecided
Unassigned
Ubuntu App Platform
High
Christian Dywan
snapcraft (Ubuntu)
Undecided
Sergio Schvezov
unity8 (Ubuntu)
Undecided
Unassigned

Bug Description

Currently it seems not possible to have working gettext translations without included a patched glibc build in your snap

- the core image doesn't have locales definition

that can be worked around by including locales definitions in the snap, though that's tedious, ideally snapcraft would help there

- traditional desktop applications are built with calls to 'bindtextdomain ("domain", LOCALEDIR)', where LOCALDIR is defined at buildtime and so pointing to /usr

there seems to be no way to redirect to another directory at runtime

- desktop applications needs system library translations sometime which means langpacks need to be included in snaps

tags: added: snap-desktop-issue
summary: - Snaps built from deb can't be translations
+ Snaps built from deb can't be gettext translated
Launchpad Janitor (janitor) wrote :

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

Changed in snapcraft (Ubuntu):
status: New → Confirmed
Oliver Grawert (ogra) wrote :

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/

Olivier Tilloy (osomon) wrote :

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

Olivier Tilloy (osomon) wrote :

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

Olivier Tilloy (osomon) wrote :

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.

Bill Filler (bfiller) on 2016-10-21
Changed in snapcraft (Ubuntu):
assignee: nobody → Sergio Schvezov (sergiusens)
Tim Peeters (tpeeters) on 2016-12-06
Changed in ubuntu-app-platform:
assignee: nobody → Tim Peeters (tpeeters)
importance: Undecided → High
Changed in ubuntu-app-platform:
status: New → In Progress
tags: added: personal
Changed in canonical-devices-system-image:
importance: Undecided → High
milestone: none → p2
status: New → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in unity8 (Ubuntu):
status: New → Confirmed
Christian Dywan (kalikiana) wrote :

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).

Pat McGowan (pat-mcgowan) wrote :

@christian can I ask you to drive this langpack discussion

Changed in canonical-devices-system-image:
assignee: nobody → Christian Dywan (kalikiana)
Gunnar Hjalmarsson (gunnarhj) wrote :

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.

Christian Dywan (kalikiana) wrote :

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

Oliver Grawert (ogra) wrote :

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

Christian Dywan (kalikiana) wrote :

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.

Christian Dywan (kalikiana) wrote :

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.

Tim Peeters (tpeeters) on 2017-02-08
Changed in ubuntu-app-platform:
assignee: Tim Peeters (tpeeters) → Christian Dywan (kalikiana)
Timo Jyrinki (timo-jyrinki) wrote :

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

Changed in ubuntu-app-platform:
status: In Progress → Fix Committed
Timo Jyrinki (timo-jyrinki) wrote :

(in edge these days)

Changed in ubuntu-app-platform:
status: Fix Committed → Fix Released
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers