- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 19 Nov 2009 15:01:29 +0100
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, public-html <public-html@w3.org>
On Thu, 19 Nov 2009 21:08:13 +1100, Silvia Pfeiffer wrote: > On Thu, Nov 19, 2009 at 2:10 PM, Maciej Stachowiak <mjs@apple.com> wrote: >> On Nov 18, 2009, at 7:00 PM, Silvia Pfeiffer wrote: >>> A unified interface for language setting API across browsers certainly >>> should be in the interest of everyone, no? >> >> Is there a need to expose any setting to the Web page other than the >> language preference for Web content? Maciej: You speak in singular: "the language preference". >> In Safari, it's unlikely we'll ever >> have three separate language preferences, Maciej: You don't have any. You just take what the Mac OS X preferences decide. Except that you ignore that Mac OS X can be set up with a cascade of preferences. [...] >> Regarding captions and audio descriptions: is it really necessary to >> specify >> a preferred language? What's the use case for having those in a different >> language than your preferred language for Web content? Maciej: You speak in singular: "preferred language". >> Are there users who >> have different language preferences the text of the Web page, video >> captions, and audio descriptions? It seems like "want" and "don't want" are >> the only relevant settings for those. Maciej: You mean "I want audio description", "I want video caption", I suppose. The answer to your question is that, yes, per the context, the user may have different language preferences - determined by what is available. Safari, as told, only report one language as the preferred language. My small mother language have 3 language codes: nn, nb, no. As a consequence of Webkit's behavior, if I have set 'nn' as my preferred language (which I have), then the page may fall back to English or Chinese simply because Webkit doesn't link "nb" and "no" to "nn". If Safari would start to send an accept header that optionally reports more than one language, then, as result, the user may get a film with English audio (because he has English as the least preferred language) with Norwegian subtitling (because he has Norwegian as his most preferred language). I think that giving the user the ability to say what /secondary/ language he/she prefer for audio descriptions, for subtitling etc, may help the user to understand /why/ he/she needs to define more than simply his/her mother tongue as a preferred language. My set-top TV box allows me to select interface language, another audio/dubbing language preference and a third subtitling language preference. > Maybe - it's something that still needs to be discussed. I proposed it > that way because it provides flexibility without much extra effort. Please be aware that Webkit is a browser that hasn't realized the need to report more than the mother tongue (= a single language) in the accept header. Firefox is better, but I don't think it has a good interface for it. > It's not even clear if we should have a preference for captions and > subtitles each - since they typically are presented in the same > location, I have merged them in one preference. > > For subtitles, it is, however, indeed necessary to specify which > language they should be in, because let's say you are a foreigner and > everything is set up in English for you, you might still want your > video subtitles to be in your native language. I think what Maciej meant was that if the page is all English, and your accept header says "Norwegian", then - if subtitling is available in Norwegian, you will get Norwegian subtitling, as long as you have told that you want subtitling at all. What I care more a about, therefore, is that Safari only report one accept language. E.g. may be I want Swedish when Norwegian isn't available. Or my language situation might be such that there are 3 language tags that cover my primary language preference. > BTW: a whole discussion about the necessary OS/browser preferences for > accessibility will need to be had and I assume it will likely be had > in the accessibility task force. > > I raised it here since it's not just an accessibility but also an > internationalisation issue. Indeed. -- leif halvard silli
Received on Thursday, 19 November 2009 14:02:06 UTC