This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 6.5.1.2 Language preferences has the recommendation "user agent implementors are encouraged to return 'en' unless the user has explicitly indicated that the site in question is allowed access to the information." "en" is the wrong value to recommend here. "en" is a valid language tag, but not the preferred language of the majority of internet users. If user agents started following the recommendation to return "en" for users whose preferred language is not English, then applications would have to treat "en" as meaning "undefined", i.e., stop providing English-speaking users with their preferred language. If a user agent wants to protect the user's privacy by not providing the user's real preferred language, then it should simply return |undefined|.
Returning undefined is very likely to break pages that use string methods on the return value (e.g. navigator.language.charAt(0) or whatnot). We want a default value that's a string; perhaps ""?
Internet Explorer up to at least version 10 doesn't have navigator.language, so at this point applications have to deal with it being undefined.
Except to the extent that they do sniffing and take different codepaths in different browsers, of course... We've been bitten far too many times by making something undefined that was already undefined in some one browser and pages suddenly breaking. But more importantly, think about the situation a few years from now when all UAs return strings except the ones that are implementing the encouragement from the spec (which I expect to be minority UAs). At that point, those UAs would almost certainly have to return "" (violating this spec) due to compat concerns, assuming the property gets used at all.
(In reply to comment #0) > If a user agent wants to protect the user's privacy by not providing the > user's real preferred language, then it should simply return |undefined|. How about "und" = Undetermined ? http://www.loc.gov/standards/iso639-2/php/code_list.php
"und" would work, and so would "" (which is used in XML and HTML to "switch off" outer lang/xml:lang settings for inner structure). I'd personally prefer "".
If the concern is that applications use the value of navigator.language without any checking, then "und" is better than "". "" is not a valid BCP 47 language tag and will result in exceptions when passed to methods in the ECMAScript Internationalization API.
Why do we need to make navigator.language return a fake value while we already provide more information in the HTTP headers?
(In reply to comment #0) > If a user agent wants to protect the user's privacy by not providing the > user's real preferred language, then it should simply return |undefined|. This makes the user more special (i.e. trackable) than if the user was hiding in the "en" crowd.
Is it common for browsers to return "en" currently? I don't believe I ever configured any of mine for this, but they all return either en-US or en-GB. Is there really an "en" crowd to hide in?
HTML5.1 Bugzilla Bug Triage: Works for me. Spec currently gives this advice: > If the user is using an anonymizing service, then the value "en-US" is suggested; if all users of the service use that same value, that reduces the possibility of distinguishing the users from each other. Are folks still interested in returning the empty string? If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!