On Tue, 2014-04-15 at 21:40 +0200, David Planella wrote:
> The situation right now is that translations come from the Store, > where there is support for editing them via a form. It should also be > soon possible for clients (e.g. the click scope) to fetch those > translations when online. I don't think the server is filtering on Accept-Language yet to send translated values in the JSON for app metadata, however the click scope is now sending the Accept-Language header, so this should start working as soon as the server starts filtering on that value and sending translated values where appropriate. > 1) Where: options to implement offline translations include adding > internationalization support to either .desktop or click manifest > files, and from a talk with dobey, it seems the manifest files would > be a good candidate. When online, translations could be downloaded and > refreshed if necessary. There is a branch up which adds support for translations of apps in the click scope. This includes translation of the Name and Comment fields in the .desktop file (the only translated fields which are being loaded by the scope at the moment). For apps packaged as clicks, this means the translations will need to be merged back into the .desktop file, as the click scope has no way to know where to load the translations from for click packages via gettext domain. This includes the pre-installed click packaged core apps. For the pre-installed apps which are not click packages, we are currently supporting the use of the gettext domain loading, but these apps should be converted to clicks at some point, and have their translations merged back into the .desktop file where necessary. This also does not resolve the issue of having translated screenshots for app previews, nor translated icons (in cases where metaphors do not translate to other cultures). I'm not sure how we could fix these issues exactly. > 3) Inline translations or MO files: for performance reasons, the > suggestion is to include the translations inline in in the manifest or > desktop files, as they could be read while listing all available apps > without having to additionally open each app's .mo file. Thoughts on > this? Not only for performance reasons, but also for practicality. There is no way for the click scope to know where on the filesystem the .mo files might be for a click package. So click packages will need to have their translations merged back into the .desktop files. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
