23436 - implement navigator.appMinorVersion, systemLanguage, userLanguage

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement)

Description

[Henrik Gemal]

appMinorVersion: Retrieves the application's minor version value.
systemLanguage: Retrieves the default language used by the system.
userLanguage: Retrieves the current user language.
javaEnabled: Returns whether Java is enabled.

http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/obj_navigator.
asp

Comment 1

[vidur (gone)]

javaEnabled has been implemented. The rest are worth considering, but not till 
later.

Comment 2

[ekrock's old account (dead)]

<tough_decision>Marking FUTURE. Time to push off noncritical 
enhancements.</tough_decision>

Comment 3

[Henrik Gemal]

RFE cleanup. RFE is already indicated by the Severity field...Sorry for the 
spam!

Comment 4

[Yuying Long]

Add intl keyword and nominating as nsbeta1 from i18n point of view for adding
"userLanguage" and "systemLanguage".

Paste an user comment here:
-----------------------------------------------
When the Icelandic user is using the English version of IE with the character
set set to 1252 (or ISO-8859-1 or 15), you can still find out that the user uses
Icelandic by accessing this property in JavaScript as long as the user sets it
that way in Control Panel.
So if you have contents for your small-scale web site (and if you don't have the
budget for the system that uses server-side scripting) offered in both English
and Icelandic, and you use JavaScript to decide in which language you should
offer the content to this user (albeit which may not be likely in real world),
you can still correctly offer the content in Icelandic to this user.
However, if the user, who is using Netscape, accesses your site, there is no way
to tell the user's language by using JavaScript (after all he is using the
English version of Netscape with charset being set to CP1252), you can only
offer the content in English.

Comment 5

[Simon Montagu :smontagu]

international team confirms that this bug is nsbeta1

Comment 6

[Samir Gehani]

i18n triage team: nsbeta1-

Comment 7

[Boris Zbarsky [:bzbarsky]]

jst, are these something we want?

Comment 8

[Johnny Stenback (:jst)]

I'd accept patches that makes Mozilla mimic IE here where there's no existing
easily available equivalent for new properties.

Here's what IE appears to have on navigator:

http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/obj_navigator.asp

Comment 9

[Boris Zbarsky [:bzbarsky]]

userLanguage and systemLanguage would need some info from intl folk (how can the
DOM get at these?)

Comment 10

[Vidar Haarr (not reading bugmail)]

As bz said, someone who is familiar with this code (intl) should comment on
this, but I thought I'd take a stab at it - who knows, maybe I got something
right :-)

The relevant code for Unix/BeOS is here:
<http://lxr.mozilla.org/seamonkey/source/intl/locale/src/nsLocaleService.cpp#201>.

It loops through posix_locale_category and calls setlocale for them, which will
set the posix_locale_category for Mozilla to the users $LC_ALL or $LANG (IIRC,
this depends a bit on the system type, Linux prioritizes $LANG, but I /think/
BSD prefers $LC_ALL) and returns that as char* lc_temp (on my box all these
setlocale calls return "nb_NO.UTF-8", for example). If any of these return NULL,
we check $LANG ourselves or eventually just default to "en_US". If it doesn't
return NULL, we set the platformLocale and xpLocale to (on my box) "nb_NO.UTF-8"
and "nb-NO", respectively.

MS defines 
navigator.userLanguage as "Retrieves the operating system's natural language
setting."
and
navigator.systemLanguage as "Retrieves the default language used by the
operating system."

On Windows, these map easily to nsILocaleService:: getApplicationLocale and
getSystemLocale, respectively.

On Linux we must map both to getApplicationLocale, since IE defines the return
value from navigator.userLanguage as one of these:
<http://msdn.microsoft.com/workshop/author/dhtml/reference/language_codes.asp>.
The locales stored in nsILocaleService::getSystemLocale() are seperated by "_",
while this list says that those that need a seperator should use "-" (many only
use the first part there), which is what the getApplicationLocale() uses.

In any case, how do we get it to mimic IE 100% on Linux? I'm not sure we can. We
will return the full "en-US" identifier, while IE (according to that document at
least, I don't have IE here so I can't test) will return "en" (for the US
variant, that is).

I have no idea about OS/2 or Mac.

Anyway, adding and populating the properties to nsIDOMNavigator shouldn't be a
problem.

Comment 11

[Gordon P. Hemsley [:GPHemsley]]

There are better ways of getting at the user's preferred language than navigator.systemLanguage or navigator.userLanguage. Firefox only exposes the user's stated preferred language, not information about their non-Web-exposed system language. And it seems that most other modern non-IE browsers don't support these properties either:

http://www.aptana.com/reference/html/api/Navigator.html

It doesn't appear that navigator.appMinorVersion ever included any useful information (even in IE), Firefox doesn't expose minor version information (if it even has any), and there are better ways to access the UA information if actually necessary.

Here's some additional historical information:

https://developer.mozilla.org/en-US/docs/DOM_Client_Object_Cross-Reference/navigator

Given that time and specs have moved on, I'm going to assume that this is WONTFIX.