From 96b2b04cdd479e9f603e6f7b0bb5020fe6088c85 Mon Sep 17 00:00:00 2001 From: Marcos Caceres Date: Tue, 22 Mar 2016 17:29:45 +1100 Subject: [PATCH] Feat (l18n): define expected means of doing l18n (closes #323) --- index.html | 41 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index ed937893..e2da9d8f 100644 --- a/index.html +++ b/index.html @@ -3137,11 +3137,46 @@

repository on GitHub.

-
+

- internationalization + Internationalization

-
+

+ It is expected that authors will localize the content of a manifest by + using one of the following options: +

+
+
+ Dynamically setting the language: +
+
+ This can include, for instance, asking the user what their preferred + language is and dynamically adding or replacing the manifest link + relationship to the document based on that language preference (e.g., + using a URL like "manifest.php?lang=fr"). +
+
+ Using content-negotiation, or geotargeting, etc. on the server: +
+
+ The server that hosts the web application could attempt to + predetermine the user's language by using geotargeting or by + using content negotiation (e.g., using [[RFC7540]]'s + "Accept-Language" header, or even a custom HTTP header). +
+
+

+ Given the options above, developers need to be mindful of the + end-user's privacy with respect to their preferred language: When the + end-user has explicitly indicated their language preference to a web + application (i.e., when not just using the user-agent default language + settings), sending the user's preferred language in the clear over the + wire is generally not OK. Doing so would reveal personal information + about an end-user. As such, developers are encouraged to use [[TLS]] to + reduce the chances of pervasive monitoring of their Web applications + [[RFC7258]]. +