Accept-Language header loses modifier information

[jhenstridge]

The current code in get_accept_languages currently discards the .codeset and @modifier portions of locale identifiers in order to try and make POSIX locales look like BCP47 locale identifiers:

https://github.com/snapcore/snapd-glib/blob/7baca4b5/snapd-glib/snapd-client.c#L313-L346

This loses important information that could result in unreadable text if the header was being used by snapd (as it hopefully will be in future).

Consider the two locales sr and sr@latin. Both represent the Serbian language, but the first is Serbian written in Cyrillic while the second is written in Latin script. Both would be converted to sr, meaning a user who can only read Latin script Serbian being presented with Cyrillic text.

The correct BCP47 identifier for the second locale would be sr-Latn, but it's not clear we'd benefit much from further locale munging if snapd is just going to have to reverse the process to recreate the POSIX locales.

[robert-ancell]

Do you think we need a custom HTTP header to pass through the locales unmodified?

[jhenstridge]

I'm not completely sure what we should do. This was just something that came up when thinking about how we could use what you did for translations within snapd (rather than just passing the header on to the Snap Store, as I gather you originally thought to have this used).

As a custom HTTP protocol, we could pass non-standard data in the Accept-Language header. But if we are going the non-standard route we might want to also do away with the quality values too, and just treat it like an ordered list. At that point, maybe it is better to go with a custom header name.

I guess one benefit of a separate header is that it would be less likely to cause compatibility problems with existing deployed versions of snapd-glib.