Support installing localization data from click packages

[Alberto Mardegan]

It would be nice if it were possible to add support to a new language/locale by just installing a click package.
This would have several benefits:
1) People could easily add support for non officially supported languages
2) Languages would be updated independently from the system image
3) Some space could be freed from the image, if some languages get moved to click packages

I'm entering this bug against ubuntu-ui-toolkit, because I guess it would need some change to get the correct path where translations are installed (it now calls bindtextdomain with /usr/share/locale, while it should fallback to ~/.local/share/locale/ if the language does not exist in the system path), but there surely are other projects that would need to be changed.

For sure, we would need a click hook to move the translations in ~/.local/share/locale/, as well as changes to the apparmor policy to read from that directory.

[Cris Dywan (kalikiana)]

Would it be possible to add symbolic links to /usr/share/locale? Short of that we probably need to set TEXTDOMAIN in the environment, as I'm not aware of any API call that allows changing the default search directory.

[Launchpad Janitor (janitor)]

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

[Seth Arnold (seth-arnold)]

I'm concerned about adding translations from potentially untrusted sources -- format strings are a ripe source of security issues in some languages and allowing any random person to provide translated strings for programs that handle private data is potentially highly dangerous.

Python, Ruby, Perl, PHP, all make it easy to dump arbitrary variables this way; Lua looks like it can easily be configured to do so as well, if authors choose to use such functionality. C, C++ format strings can read and write data into and out of memory nearly arbitrarily.

Thanks

[David Planella (dpm)]

I'm guessing the click language packs would be provided by a trusted set of contributors: Ubuntu Translators, in the same way they provide the .deb language packs today.

Perhaps the click language packs could have their own policy that triggers a manual review to ensure only those from a trusted source get uploaded?

[Cris Dywan (kalikiana)]

What we possibly could do also is to exclusively support %1 style formatted strings as supported by QString http://doc.qt.io/qt-5/qstring.html#arg and QML strings. The type is never part of the translated string here and the worst outcome is error messages. This would require some sort of lint for .po files so that only %1 style strings are allowed.

[Kyle Nitzsche (knitzsche)]

I wonder whether frameworks is a feasible approach here, since IIUC, their point is to install something via a click package that is accessible to other click packages.