Support localization in apps

[ocdtrekkie]

While work is being done and discussions being had on things like variables passed through to apps and the revised profile page, I think it'd make sense to support localization in apps, which could be much simpler than supporting localization for the platform itself. While this may not be a huge priority, it may be worth considering adding these features as other work on the necessary fields are being done.

Sandstorm may be light enough on the amount of text in the UI to at least allow non-English speakers to operate effectively with grains shared with them, if not enough to get around Sandstorm fully, based on common terms (like "sign in") that they have probably seen on tons of other websites that aren't localized. Or the fact that many of those terms may be cognates in their preferred language.

We'd need:

• A profile setting for a user to set their preferred localization.
• An X-Sandstorm-Preferred-Language header passed through the HTTP bridge.
• Probably a metadata tag to specify supported languages for market use.

Apps would be able to detect that, display the relevant localization (if supported), and display the default if the language isn't supported by that app.

[kpreid]

Don't invent new protocols unnecessarily; apps should read the HTTP Accept-Language header. For cases where a user uses public or otherwise misconfigured computers, a profile setting can override the header value that is proxied to the app, but that is now an independent feature from apps' localizations since the app doesn't care where the value comes from.

[ocdtrekkie]

@kpreid Sorry, I admit my knowledge of what standards for passing this information through is lacking. I was just thinking of the manner Sandstorm tends to communicate platform user settings to apps.

I suppose anonymous users would get their Accept-Language passed through from the browser, but for signed in users, apps would get Accept-Language provided by their profile setting in Sandstorm.

[ocdtrekkie]

So I was trying to read sandstorm-http-bridge.c++ and I think the current code does pass through Accept-Language, so if I were to test it, apps that looked for it would localize currently?

Perhaps a better question additional question on this topic is if we need to add more documentation on what headers are passed through. https://docs.sandstorm.io/en/latest/developing/auth/ mentions Sandstorm-specific ones, like the preferred pronoun, but doesn't mention standard headers which may be passed through. (I see that web-session.capnp lists all the headers which WON'T be.)

(Random trivia: Rendering the text for code browsing on GitHub in Edge is very, very broken. I have to look at the Raw view.)

[zarvox]

Sandstorm does pass through Accept-Language, so that should work fine today, if the app respects Accept-Language. (There's some detail where we don't yet support utility factors like ";q=0.7" but for a first approximation, Accept-Language should work today.)

More approachable documentation on what headers are in/out/backburnered is probably a good thing. A tool which we could use to make the precise reference documentation (e.g. the source code comments) more web-accessible and linkable would be quite nice, if someone wants to implement a docs generator for capnp or KJ-style C++. :)