- From: Toby Inkster <tai@g5n.co.uk>
- Date: Thu, 19 Nov 2009 10:05:12 +0000
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-html <public-html@w3.org>
On Wed, 2009-11-18 at 19:10 -0800, Maciej Stachowiak wrote: > Is there a need to expose any setting to the Web page other than the > language preference for Web content? In Safari, it's unlikely we'll > ever have three separate language preferences, but even if we did, I > can't see why Web content would care about the OS language or the > browser language if they are different from the language to be used in > Web pages. I can only think of one realistic use case where the web page might want to know OS and Browser UI languages rather than web page language preferences, and that's when providing help on using their system. For example: <p>To open a command prompt in Windows 95, click the <kbd id="start">Start</kbd> menu, select "Run" and type <kbd>command</kbd> then Enter.</p> <script type="text/javascript"> var start = document.getElementById('start'); if (navigator.systemLanguage=='fr') start.innerHTML='Démarrage'; else if (navigator.systemLanguage=='es') start.innerHTML='Inicio'; else if (navigator.systemLanguage=='it') start.innerHTML='Avvio'; </script> It seems to me that the most useful information that scripts could be provided would be the user's preferences for web page languages - i.e. the same information used to construct the Accept-Language HTTP header. This should probably be as an array. I'm not sure if it's best for it to be an array of strings, or an array of objects. The former is simpler, but the latter would allow them to provide some useful methods like lang.matches() which could allow "en-gb" to match "en", but not match "en-us" (similar to SPARQL's langMatches function). -- Toby A Inkster <mailto:mail@tobyinkster.co.uk> <http://tobyinkster.co.uk>
Received on Thursday, 19 November 2009 10:05:59 UTC