Applications installed in containers don't have the same localization as what is used on the host system

There's likely an environment variable that we simply need to forward to get localization working correctly. Otherwise, this could be a tough problem.

@einarmostad,

Thanks for entering this bug report.

On the m10, we have X apps localization preinstalled for en_US, en_GB, es, fr, de, pt, it, and ru. It was determined by Canonical and BQ product management to include these languages only in the Puritine/Desktop Applications click package preinstalled on the m10 to keep the size of the click package down. These languages were chosen as they were deemed the most likely languages being used for the intended sale areas. If we included all language packs in the click package, it would be over 1GB in size!

That being said, anyone can create their own Libertine container on the m10, install whatever apps they want and also install the language packs for the language they choose.

Thank you for the explanation! :-) Will this localisation policy (and/or how it works technically) change when snap packages come to Ubuntu touch? Is it up to the OEMs? Will this be fixed at some point in the future? What about Xapps in Unity 8 on the desktop?

People would expect the already installed apps to just localise themselves after setting the language at first run. I still think this is a bug worth considering. These things matter the most to people of smaller languages where keeping the language and the culture alive is not necessarily a given. I would suppose the Catalonians and the Basque would be annoyed at Bq and Cannonical for not including their languages in a Spanish product by default...

I am not a coder, so this might not be technically possible, but maybe you could ship only en_US and have a script that fetched the right localisation files upon first run and when localisation was changed in the settings app. There should probably also be a check for the right localisation whenever the Xapps update themselves. Then only the relevant localisation files would be installed, files sizes would be smaller and everybody would get their localisation. Or is it not possible to install things inside the Puritine wrapper from the outside of them once on the tablet/phone? Are the containers themselves read only or just the system underneath?

I really have no idea how localization is going to work for Snap packages. Last I heard, and this was a few months ago, so I'm sure things have changed, is that each snap package is responsible for providing all of their own localizations in the package itself. Of course, that will cause grief, so again, I'm not sure what the thinking on this is now.

Right, when someone selects a new language on say, the Unity 7 desktop, it will download and install language packs for the selected language for different packages on the system. On Touch, most language packs are already preinstalled for touch, since it's a much smaller system. Then click packages from the Store are supposed to provide their own localizations. I'm pretty sure most Store apps aren't localized for every language.

As far as Puritine, it is a read-only container since it's a click package, so being able to add localization to that is not possible. However, for user created Libertine containers, maybe we can think of some ways to be able to add new localizations to the container based on what the user selects for their language.

I'll reopen this bug for considering how best we can handle adding language packs to the container based on the user's chosen language.

Thanks for all of your input!

Thank you for a fast and interesting reply and for all the work going into Ubuntu touch! :-)

Fix committed into lp:libertine at revision 372, scheduled for release in libertine, milestone Unknown

This bug was fixed in the package libertine - 1.5.1+17.04.20170118-0ubuntu1

---------------
libertine (1.5.1+17.04.20170118-0ubuntu1) zesty; urgency=medium

  [ Chris Townsend ]
  * Remove the /tmp/.X11-unix umount during LXC container start for operations
    as it seems it's not needed. (LP: #1654650)
  * Remove extra finish_application() in chroot backend.
  * Set container's locale and language based on the host including installing
    necessary language packs. (LP: #1609982)
  * Bump version to 1.5.1.

  [ Larry Price ]
  * Manually execute lxd bind mount script to fix /run/user and remove
    service. (LP: #1654647)
  * Convert results to dicts on operation/application collision in container
    lifecycle managers.
  * Stop bind-mounting /usr/lib/locale and let environment do all the work.
    (LP: #1654648)
  * Mount lxd home directory in $HOME/.local/libertine-container where it
    belongs.
  * Manually wait for lxd container to stop when specified after calling the
    service. (LP: #1655980)
  * Ask for container user password when creating lxd containers. (LP: #1655977)
  * Bind-mount lxd container applications and icons directories into user's
    home directory.

 -- Christopher Townsend <email address hidden> Wed, 18 Jan 2017 14:50:33 +0000

Thank you for your work on this fix! :-)