In fact charts like https://secure.phabricator.com/fact/chart/?y1=N%3A* dates are wrongly localized, without respect for browser configuration.
Browser configuration:
Firefox returned "en,en-us;q=0.8,fr;q=0.6,fr-be;q=0.4,fr-fr;q=0.2" as HTTP_ACCEPT_LANGUAGE.
Keyboard and OS languages are french.
Expected behavior:
English l10n
Current behavior:
French l10n
We're using .toLocaleDateString() in JS ourselves, here:
So I guess your browser isn't respecting its own configuration. :)
There's some discussion of allowing users to specify date formats in {T1202}.
Once that's implemented we should probably do the date rendering on the server, although that could get kind of messy...
Indeed, according https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toLocaleDateString .toLocaleDateString() follows system l10n parameters, not language user preference.
That's more annoying and could lead to some incoherence, but I guess this is fine for the majority of the users (who should have similar preferences in their OS and browser).
I guess to use the CLDR - http://cldr.unicode.org/ - could be a solution to have a coherent application localization but according my Wikimedia experience, this is rather hard to implement correctly.