93985 2012-08-14 09:47:01 -0700 -webkit-locale should be inferred from system language 2013-03-19 15:17:11 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Unspecified Unspecified NEW InRadar P2 Normal --- 10874 1 ap webkit-unassigned efidler esprehn falken jshin oldest_to_newest 695069 0 ap 2012-08-14 09:47:01 -0700 Consider the following HTML document: <html> <body> <p>John said <q>Mary said <q>blah</q> to me.</q></p> </body> </html> All these quotes will be displayed as ASCII ones, which is not right. I think that we should use system language as the last fallback for document language, as this would be correct more often than not. Of course, lang attribute or HTTP headers would still have precedence. 837826 1 ap 2013-02-20 15:19:29 -0800 <rdar://problem/13258070> 850876 2 falken 2013-03-07 22:21:56 -0800 A related Chromium bug is https://code.google.com/p/chromium/issues/detail?id=179331 850898 3 ap 2013-03-07 23:08:02 -0800 This should be pretty easy to do, we already track system language in WebCore (on Mac). 850899 4 ap 2013-03-07 23:08:53 -0800 (and many other WebKit based browsers have the language user configurable) 858789 5 jshin 2013-03-19 15:15:25 -0700 bug 18085 is also related. The precedence order would be 1. explicit lang/xml:lang (and Content-Language) 2. charset to lang mapping 3. OS/System language (or UI langauge if UI language is different from OS/System language) 858790 6 jshin 2013-03-19 15:17:11 -0700 BTW, when we do step #2, we also have to take into account system/UI language to break the degeneracy (ISO-8859-1, windows-1252 : what to map to? 'en' is a good fallback, but if the system/UI language is French, 'fr' would be better).