Snapd localisation

snapd
1

With @zyga-snapd’s work on adding desktop notifications for cases where pending refreshes are blocked by running apps, the issue of localisation becomes a even more important, since these will be visible to non technical users.

While snapd has made some effort towards localisation via Launchpad, there are a few important gaps:

  1. The translation template uploaded to Launchpad was generated in April 2018. Any strings added since then are not being translated. The templates for the Ubuntu packages are more up to date, and getting close to twice the size.
  2. The in-tree translations were last synchronised from LP in November 2019.
  3. The snapd build process does not install translations. Translations are distributed through Ubuntu’s language packs, but that doesn’t help anyone on other distributions.
  4. We extract strings from the polkit .actions file, but do not merge them back in.
  5. We don’t extract or merge strings from .desktop files.

And some minor issues:

  1. The translation domain is called snappy, which is a deprecated name for the project.
  2. The template generated by update-pot does not contain file name information, which would be useful to translators looking for context.
  3. snapd itself generates translations. It’s not uncommon for it to be running with different locale settings to the user, which could result in the wrong language being displayed to the user in some cases.

Here are some ideas about how we could improve matters:

Import templates to Launchpad

It looks like the only automated translation import process LP supports right now is to extract templates from the default Bazaar branch of a project. Currently the default branch is set to a Git mirror of our Github branch, and I’m not sure how much relies on that being set as default.

If we could change it, or if it was possible to concurrently set a default Git and Bazaar branches, one option would be to create a bzr branch containing only translation template. We could then have a Github Actions workflow that triggered on pushes to snapd master that would run update-pot and commit the resulting template to the Bazzar branch on LP.

Exporting translations from Launchpad

It is possible to configure Launchpad to automatically commit translation updates to a Bazaar branch. We could configure a second Bazaar branch to receive translations from Launchpad, and then have a scheduled Github Actions workflow to check out the Bazaar branch and update the translations in Git. This could either directly commit to master (risky), or generate pull requests (e.g. using peter-evans/create-pull-request@v3).

Installing translations

The update-pot script currently builds the in-tree translations. It shouldn’t be difficult to have it (or a related script) install them too. In the specific case of Ubuntu packages, the translations should be stripped out of the .deb packages. We probably want them included for all other distros.

We probably want translations included in the snapd and core snaps.

Translations in polkit and desktop files

Gettext’s msgfmt utility can merge translations into XML and desktop files. We’d just need to integrate the appropriate calls into the Makefiles. Of course, this relies on having up to date translations in tree.

5 Likes
2

I made a small PR to address minor issue (2), adding file information to the generated translation template:

https://github.com/snapcore/snapd/pull/9586

As far as translation import goes, it seems that a Launchpad project using Git can have Bazaar branches associated with its series. At present, snapd’s trunk series is associated with lp:~snappy-dev/snapd/master, which is an import of the Github branch that last successfully synchronised in April 2018. That explains the date of the last template import.

So it probably wouldn’t cause any problems to reassociate the series with a Bazaar branch owned by some bot account that could be written to by a Github Actions job.

As for minor issue (3), the best option is probably to have the client indicate what language it wants messages presented in and have snapd comply. There is some precedent for this, with @robert.ancell coding snapd-glib to send an Accept-Language HTTP request header:

https://github.com/snapcore/snapd-glib/commit/1a7f29a1

I don’t think snapd has ever done anything with this, but it might make sense for the Go client send a similar header, and then use this when generating text in snapd.

That means there would no longer be a global locale for translations within snapd. Maybe this could be implemented by stuffing the request’s language preferences into a context, and add context aware versions of i18n.G and i18n.NG. This would also require changes to xgettext-go to extract strings marked with these alternative functions.

1 Like