Open kriskowal opened 12 years ago
kriskowal
commented
12 years ago The shim could be async instead, but that would not make sense if browsers were to standardize it. The browser already has an accept-language header to use before displaying the page. We can get the same effect by postponing any work that might need the interface until it can be done synchronously.
marchant
commented
12 years ago Good idea, there are no services like that today?!! though if a language were to be hard coded in the page, it may need to take precedence?
On Jun 21, 2012, at 12:01, Kris Kowalreply@reply.github.com wrote:
To faithfully deliver the user’s preferred language in localization, we’ll need to create a browser API for content-negotiation early in the bootstrapping process.
Presently, the only viable way to query a user’s Accept-Language header is to use an XHR to a service that provides a JSON representation of the request headers.
From there, you can use a MIME parsing library to find the best match from a locally provided set of options. https://github.com/kriskowal/mimeparse
The ideal interface would look something like this:
navigator.negotiateLanguage(["en", "en-US", "en-CA", "fr", "fr-CA", "de", "sp", …])Which would return whichever of the options best matches the accept-language header.
We can issue an XHR during bootstrapping to a CORS-configured appspot service that returns the request headers in JSON. Depending on when we intend to be able use these values first, we can wait for these values (with a short timeout), or fall back to the best match to navigator.language.
Reply to this email directly or view it on GitHub: https://github.com/Motorola-Mobility/montage/issues/828
marchant
commented
12 years ago There's this:
On Jun 21, 2012, at 12:01, Kris Kowalreply@reply.github.com wrote:
To faithfully deliver the user’s preferred language in localization, we’ll need to create a browser API for content-negotiation early in the bootstrapping process.
Presently, the only viable way to query a user’s Accept-Language header is to use an XHR to a service that provides a JSON representation of the request headers.
From there, you can use a MIME parsing library to find the best match from a locally provided set of options. https://github.com/kriskowal/mimeparse
The ideal interface would look something like this:
navigator.negotiateLanguage(["en", "en-US", "en-CA", "fr", "fr-CA", "de", "sp", …])Which would return whichever of the options best matches the accept-language header.
We can issue an XHR during bootstrapping to a CORS-configured appspot service that returns the request headers in JSON. Depending on when we intend to be able use these values first, we can wait for these values (with a short timeout), or fall back to the best match to navigator.language.
Reply to this email directly or view it on GitHub: https://github.com/Motorola-Mobility/montage/issues/828
To faithfully deliver the user’s preferred language in localization, we’ll need to create a browser API for content-negotiation early in the bootstrapping process.
Presently, the only viable way to query a user’s Accept-Language header is to use an XHR to a service that provides a JSON representation of the request headers.
From there, you can use a MIME parsing library to find the best match from a locally provided set of options. https://github.com/kriskowal/mimeparse
The ideal interface would look something like this:
Which would return whichever of the options best matches the accept-language header.
We can issue an XHR during bootstrapping to a CORS-configured appspot service that returns the request headers in JSON. Depending on when we intend to be able use these values first, we can wait for these values (with a short timeout), or fall back to the best match to navigator.language.