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]].
+