While debugging why xdg directories don’t show as translated in e.g the gedit snap I found out that we are having an issue with translations and the gnome-platform snap and it’s used today.
That let gedit looks for its translations under /snap/gedit/current/usr which is where they are in the snap environment.
The issue is that the trick only applies to gedit but not to the libraries included in the gnome-platform (e.g gtk), gtk is coming from the Ubuntu deb with a prefix of /usr, which means it’s looking for its translations under /usr/share/locale … which is where not where they are.
Since the platform is mounted under the snap using it, e.g /snap/gedit/current/gnome-platform we can’t use the prefix trick for those libraries.
Discussing with James on IRC he suggested that using a base snap for desktop apps might be the right way to go to solve that issue.
Does that sound something we can achieve for this Ubuntu cycle? If not does anyone has an idea of another possible solution? Without resolving that problem apps installed as snaps are going to miss translations for any standard widget like the file selectors…
For libraries copied from Ubuntu .deb packages, the compiled in path will probably be /usr/share/locale.
While we could recompile everything in the platform snap with a different prefix, the current recommendation for using the platform snap is to mount it at $SNAP/gnome-platform, so it ends up in a different location for each application.
Maybe with all of @zyga-snapd’s work on layouts and general mount namespace construction improvements we could switch this to a fixed location.
Another option we could use that would avoid the need to recompile all the libraries would be to create a “GNOME desktop base snap”. This would mean all the libraries and translations would appear in the expected locations. The main downside to this is that the desktop team would be on the hook for releasing updates in response to security holes in system libraries.
I think we can reasonably safely put new things into /usr/share/locale/<langcode>/LC_MESSAGES/<catalog>.mo. We don’t have a way to magically overlay additional locale on top of existing one so we’d have to write more logic to either pick the right locale file (easy but very verbose) or do something else.
Note that snapcraft could generate those based on what is in the snap.
One workaround Didier suggested would be to let /snap/gnome-platform/current to be available to the snaps using the platform and to build gtk&co in the gnome-platform using that prefix
