Getting translated snap metadata via snapd

snapd
#1

Currently all snap metadata received by snapd clients is untranslated. Here is a strawman proposal on how to fix this:

  • snapd clients send the HTTP Accept-Language header when sending requests to snapd.
  • The languages will be populated automatically from the LANGUAGE environment variable by snapd-glib.
  • snapd will pass this header through to the store which will send translatable metadata (title, summary, description etc) back matching against the requested languages.
  • snapd will pull out appropriately translated fields from locally installed snap YAML (format TBD) and pass these back to it’s clients.
  • clients (e.g. GNOME Software, snap command line) will behave as they do currently, but now show translated metadata where available.
1 Like
Snap interface metadata (i.e. descriptions)
Mechanisms for converging store and snap metadata
#2

I’m going to go ahead and implement this behaviour into snapd-glib as I think it’s a suitable standard.

#3

So is this implemented on the client side rather than snapd? From the proposal I understood it would be reflected in the values snapd returns, which would make sense so that all clients get the same behavior.

#4

snapd is a system service and does not know about a users locale so this would need some protocol extension to have the snap command give that info to snapd at execution time …

#5

I thought that’s exactly what the proposal is about. Via HTTP-Accept-Language. But this is also why I was asking because it seems a little unclear who’s responsible for what part.

#6

well, snap is the CLI tool while snapd-glib is used by programs (i dont think the snap tool links to snapd-glib today). what i meant to say is that we should make sure it gets implemented across the board, not only in -glib …

#7

I’m just planning on implementing Accept-Language support into snapd-glib. That way if snapd becomes aware of this header then it can send back appropriately translated strings. If the solution turns out to be something different, then no problem as this is a standard HTTP header anyway. I’d prefer to get it released earlier in snapd-glib rather than later so we don’t need to update snapd-glib everywhere.

The CLI tool doesn’t use snapd-glib, so it would have to set Accept-Language itself. As would any other clients that access snapd directly or use another library (none known).

#8

With the Accept-Language header passed through snapd I’d expected the following store request:

$ http -v --json https://api.snapcraft.io/api/v1/snaps/details/store-test-ubuntu-desktop Accept-Language:de X-Ubuntu-Series:16 fields==description

to give the output (i.e. the description in German):

GET /api/v1/snaps/details/store-test-ubuntu-desktop?fields=description HTTP/1.1
Accept: application/json, */*
Accept-Encoding: gzip, deflate
Accept-Language: de
Connection: keep-alive
Content-Type: application/json
Host: api.snapcraft.io
User-Agent: HTTPie/0.9.8
X-Ubuntu-Series: 16



HTTP/1.1 200 OK
Content-Length: 201
Content-Type: application/json
Date: Tue, 05 Sep 2017 03:14:22 GMT
Server: gunicorn/19.7.1
X-Request-Id: cf7cf278-d937-44aa-a7db-8e4cc2046a5b
X-VCS-Revision: 976e5cd

{
    "description": "Es is Wunderbar!",
    "package_name": "store-test-ubuntu-desktop"
}
Ubuntu Desktop Team Priorities
#9

@natalia - does this sound like a reasonable solution to interface with the store?

#10

Hey @robert.ancell

Sending the header is fine, but for the store to honor the header and return translated results, we need to do some planning and prioritization for this new feature.

In particular, we need to have a plan for:

1- How to index translations for a given snap, whether searches are also per language, how to return translated results to the requester.
2- How the snap developer would push/load translations in the store.

So I think we should have a shared session in the rally (snapd client team – ping @niemeyer, store team – ping @noise, and desktop team) to talk about this feature, sketch a spec and have some roadmap prioritization.

Robert, do you agree?

#11

@natalia a shared session sounds great.

#12

I do think we talked about it at the Rally but I don’t think a complete plan came out. Has there been any further thoughts on the Store/Snap side about this?