Re: Web Browser Preferences and Internationalisation/Accessibility

On Thu, Nov 19, 2009 at 12:26 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Nov 18, 2009, at 5:10 PM, Silvia Pfeiffer wrote:
>
>> On Thu, Nov 19, 2009 at 10:56 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>
>>> On Nov 18, 2009, at 3:39 PM, Silvia Pfeiffer wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have a very concrete request and I am not sure that the HTML WG is
>>>> the right place to solve it, but please bear with me.
>>>> If we want to improve accessibility and internationalisation support,
>>>> I believe we need to do something.
>>>>
>>>> All modern Web browsers have user preferences and as part of these,
>>>> you can choose your preferred languages for displaying Web pages.
>>>> These preferences are different to the language in which your
>>>> browser's user interface is presented: you can e.g. run your browser
>>>> in English and still want your Web pages inside the browser preferably
>>>> to display Japanese or French or some other language over English.
>>>>
>>>> Now, not all browsers actually expose this preference setting to Web
>>>> pages. AFAIK, only Internet Explorer does:
>>>>
>>>> IE has:
>>>> navigator.browserLanguage -> Browser Localized Language
>>>> navigator.systemLanguage   -> Windows OS - Localized Language
>>>> navigator.userLanguage       -> Windows OS - Regional Settings (this
>>>> is the exposure of preferences)
>>>>
>>>> Firefox only has:
>>>> navigator.language -> only the browser's localized language - no way
>>>> to get the preference in javascript
>>>
>>> navigator.language contains the same info that's in the UA string, I
>>> believe
>>> it works in all the non-IE browsers, and it's totally accessible from
>>> JavaScript.
>>
>> No, it doesn't. It contains the language that your browser has been
>> installed in.
>> See, for example,
>>
>> http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference
>> .
>>
>> I had assumed the same and based my subtitle tests on that and ran
>> into some nasty issues with some French friends of mine, which upon
>> debugging exposed this issue. It is mentioned all over the web when
>> you try and look for language preference exposure in javascript.
>>
>
> [...]
>
>>
>> You're right and it actually exposes the same language as
>> navigator.language.
>>
>> What I meant to write was that you have to analyse the
>> "Accept-Language" header of the HTTP request, which in fact contains
>> the browser preference settings. This is a horrible hack and the only
>> way for a Web page to find out the browser preference settings.
>>
>> Try it for yourself: go into Firefox's preferences and add a language
>> that's not English and make it your first one. Then inspect your
>> navigator.language setting and your HTTP headers (firebug helps).
>
> Thanks for the clarification. For what it's worth, Safari doesn't have this
> issue; it uses the OS language setting and doesn't have a separate "install
> language" or browser-level language preference. Perhaps Mozilla folks can
> comment on the Firefox behavior.


Indeed, Safari doesn't allow any user preferences that are
safari-specific, but instead contains in navigator.language the system
preference.

This to me this signifies that there are even more problems with
browser cross-compatibility of language settings. And when we approach
captions and audio descriptions, we will only further extend this
problem.

I actually think that the IE approach is the best: it differentiates
between the OS setting, the browser setting and the Web page
preferences and lets javascript developers retrieve all of these and
react accordingly. If Safari/Webkit and several others do not
distinguish between OS and Web page preferences, then they should
simply report the same value for these.

A unified interface for language setting API across browsers certainly
should be in the interest of everyone, no?

Cheers,
Silvia.

Received on Thursday, 19 November 2009 03:01:37 UTC