Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
On Wed, Jul 22, 2009 at 10:52 PM, Alexey Proskuryakov a...@webkit.org wrote: 22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html. There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510, not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. FF has a lot more marketshare now than it did in 2005. Perhaps these issues are a thing of the past? It would be interesting to know if any of the sites mentioned still have problems in FF or Chrome. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
On Jul 22, 2009, at 11:24 PM, Darin Fisher wrote: On Wed, Jul 22, 2009 at 10:52 PM, Alexey Proskuryakov a...@webkit.org wrote: 22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html . There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510 , not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. FF has a lot more marketshare now than it did in 2005. Perhaps these issues are a thing of the past? It would be interesting to know if any of the sites mentioned still have problems in FF or Chrome. I think the main reason for us to minimize the Accept-Language header was compatibility. I think it would be reasonable to try an extended version now. The problem now is how to set things that way. Safari on Mac used to pick the Accept-Language header based on International preferences, but in the default setup, many languages are in the list and the order beyond the user's main language is fairly arbitrary. In any case, I think the privacy concern is minimal, and I don't think the proposed API makes it any worse. My only doubts about the proposal are whether web developers will actually want to use it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
Thank you all for the comments. I'll write to whatwg and public-html about adding it to window.navigator (yes, I meant navigator :-)) ). 2009/7/22 Alexey Proskuryakov a...@webkit.org: 22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? Thank you for the reference. It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html. Most of pages (Netscape directory server?) referred to there are not available any more. http://gun.teipir.gr/ds/csearch is still up and fails in Chrome, Firefox 3, and IE 8 because they all send Accept-Language with q-values. The page I got back from the server in Firefox and Chrome is 'funny': 0 0. ko 1 0.7998 en_us 2 0.4997 zh 3 0.2996 en 0 0. ko 1 0.7998 en_us 2 0.4997 zh 3 0.2996 en A-L sent was ko,en-us;q=0.8,zh;q=0.5,en;q=0.3 (IE8 'fails' to load the page, too, but it just shows an HTTP error message). There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510, not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. https://bugs.webkit.org/show_bug.cgi?id=3510#c2 has a reference to Outlook Webaccess, but that's about 'ru-ru' vs 'ru'. There's a bug report against Chrome about an 'opposite' case. We used to send languages without a q-value (which means everything gets q=1.0). See http://crbug.com/3970 Safari should just work for this case, though because the page in question works when only a single language is sent with no q-value. It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list, and that they have to configure their browser to advertise other languages. I think that addresses the privacy concerns, assuming suitable wording in the configuration panel. Yes, I agree. Safari takes the languages from system configuration. Aha.. right. I forgot that when I wrote the first email in the thread. Jungshik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
On Jul 22, 2009, at 10:36 PM, Darin Fisher wrote: Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? I’m not familiar with how Chrome approaches this, but Firefox handles this by offering a browser setting to explicitly configure a list of languages for web browsing. Roughly speaking, it’s a direct control of the Accept-Languages header field. Very few web servers look at this header field at all. It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list Exactly; this is true across browsers. Thus a single value is the configuration that’s most tested. Thus the issue is not Firefox market share number that matters, but rather the vastly smaller number of people using any browser who have gone to the trouble to put multiple languages in the language list. What we discovered in 2003 and 2004 was that making a multiple- language list the norm for people who don’t opt in to it resulted in many broken websites. Further, almost no websites worked better with a more complete Accept-Language header field. We discovered sites that had difficulty with long Accept-Language header fields containing a large numbers of characters. Here are a few examples: - The official Irish Tourist Board site www.ireland.travel.ie did not load because of the long Accept-Language header. - A site called termpro.com gave us a “Firewall Security Alert” because the header was too long. Presumably that’s not the only site that was affected by this firewall. - Servers using the Netscape Directory Gateway failed because of the long header. At the time this included sites such as these: calendar.gwu.edu co.stanford.edu directory.princeton.edu gun.teipir.gr ldap.chapman.edu www.inami.fgov.be Symptoms were variable and it took us a long time to figure out the issue was because of long header. - Another site that had problems with the long list was dirtypictureshow.com . Later, we discovered a few other problems. For example, for a while eBay treated users as if they were browsing from Germany if the German language appeared anywhere in the list, blocking certain auctions. Using the languages list from Mac OS X as our default meant that German would be included for most users. Once we changed the Safari Accept-Language to be shorter we didn’t get any more data about the problem, naturally. But I don’t think it is right to assume that these problematic sites disappeared. It’s not as if there are a large number of users with any browser that are testing behavior with a long Accept-Language header field. I think this boils down to a question of the value of having an explicit browser preference setting solely to configure the value of the Accept-Language header field. It seems this is one of those settings that experts love to tweak, but has little relevance to the real web. Do we really expect users to go out of their way to configure such things so they can browse the web? Can’t we just make the web work for them? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
Hi,
I proposed exposing the values of the Accept-Langauge list via
window.navigation.acceptLanguages at
https://bugs.webkit.org/show_bug.cgi?id=27555
This email is to get opinions (for and against) on that in case the
bug is not noticed by many. As pointed out by ap in the bug, perhaps,
we have to bring this up in the WHATWG as well. Before I do that, it
may not be a bad idea to know what others her think about it.
Currently, the UI language of a browser is exposed with
window.navigation.language. This can be used by a 'web application' /
widget / browser extension to 'behave differently' per the UI
language.
A lot of web servers also take into account the value of
Accept-Language HTTP header field when determining the UI language of
their web apps or the language of contents to serve when multiple
language versions exist. Moreover, most browsers (Safari, Chrome,
Firefox, IE, and so forth) allow users to add, delete, move up and
down a language to the prioritized list of languages they understand
Some web apps/widgets/browser extensions can also benefit from knowing
the ordered list of languages in Accept-Language.
One particular use case Chrome has in mind is to determine the target
language of translation without a user-intervention. If the source
language is A and the A-L list has {B, C, D}, the target language can
be determined by walking through the list and picking up the first
language for which the translation from A is available. If 'A' is in
the A-L list, perhaps the translation service should not be called. (
See http://crbug.com/14574 )
There might be other cases of 'multi-lingual' applications where the
knowledge of the A-L list can be helpful.
It can be exposed by adding either of the two below to window.navigation
readonly attribute DOMStringList acceptLanguages // a list of
language codes
readonly attribute DOMString acceptLanguages // a comma separated
language codes
Unlike in the Accept-Language http header field, a language in the
list will not have a q-factor associated with it. Instead, they're
sorted in the descending order of the priority.
Any opinion would be welcome.
Jungshik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
2009/7/22 Jungshik Shin (신정식, 申政湜) js...@chromium.org This email is to get opinions (for and against) on that in case the bug is not noticed by many. As pointed out by ap in the bug, perhaps, we have to bring this up in the WHATWG as well. Before I do that, it may not be a bad idea to know what others her think about it. There doesn't seem any harm in simply emailing the WHATWG list with this idea. The folks on that list are probably a better audience for the question of should this be done for user agents in general. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
I assume you mean window.navigator?
I think this is a good idea. You should bring this up the WHATWG as well.
2009/7/22 Jungshik Shin (신정식, 申政湜) js...@chromium.org:
Hi,
I proposed exposing the values of the Accept-Langauge list via
window.navigation.acceptLanguages at
https://bugs.webkit.org/show_bug.cgi?id=27555
This email is to get opinions (for and against) on that in case the
bug is not noticed by many. As pointed out by ap in the bug, perhaps,
we have to bring this up in the WHATWG as well. Before I do that, it
may not be a bad idea to know what others her think about it.
Currently, the UI language of a browser is exposed with
window.navigation.language. This can be used by a 'web application' /
widget / browser extension to 'behave differently' per the UI
language.
A lot of web servers also take into account the value of
Accept-Language HTTP header field when determining the UI language of
their web apps or the language of contents to serve when multiple
language versions exist. Moreover, most browsers (Safari, Chrome,
Firefox, IE, and so forth) allow users to add, delete, move up and
down a language to the prioritized list of languages they understand
Some web apps/widgets/browser extensions can also benefit from knowing
the ordered list of languages in Accept-Language.
One particular use case Chrome has in mind is to determine the target
language of translation without a user-intervention. If the source
language is A and the A-L list has {B, C, D}, the target language can
be determined by walking through the list and picking up the first
language for which the translation from A is available. If 'A' is in
the A-L list, perhaps the translation service should not be called. (
See http://crbug.com/14574 )
There might be other cases of 'multi-lingual' applications where the
knowledge of the A-L list can be helpful.
It can be exposed by adding either of the two below to window.navigation
readonly attribute DOMStringList acceptLanguages // a list of
language codes
readonly attribute DOMString acceptLanguages // a comma separated
language codes
Unlike in the Accept-Language http header field, a language in the
list will not have a q-factor associated with it. Instead, they're
sorted in the descending order of the priority.
Any opinion would be welcome.
Jungshik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
erik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
On Jul 22, 2009, at 4:41 PM, Jungshik Shin (신정식, 申政湜) wrote: Hi, I proposed exposing the values of the Accept-Langauge list via window.navigation.acceptLanguages at https://bugs.webkit.org/show_bug.cgi?id=27555 This email is to get opinions (for and against) on that in case the bug is not noticed by many. As pointed out by ap in the bug, perhaps, we have to bring this up in the WHATWG as well. Before I do that, it may not be a bad idea to know what others her think about it. This sounds like a reasonable extension. I prefer the variant that gives a tokenized form of Accept-Language. I think a good next step is to propose it on the WHATWG list or public-html, explaining the use cases. Besides possible translation extensions, is this something Google Translate would possible use? It seems that a number Google web properties pick their UI language based on the likely physical location of your IP address(*), and many websites do likewise, so I'm wondering if this extension is something that would actually get used on the web. Regards, Maciej * - Kind of off topic, but I found this incredibly frustrating recently when traveling in countries where I did not know the native language. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
22.07.2009, в 16:41, Jungshik Shin (신정식, 申政湜) написал(а): Some web apps/widgets/browser extensions can also benefit from knowing the ordered list of languages in Accept-Language. I should note that Safari only sends one language. The reasons for this are: - protecting users' privacy, as a list of spoken languages can help identify a site visitor better than the primary preferred language; - improving Web compatibility, as servers happen to have most weird problems with complicated Accept-Language strings. So, the difference between Accept-Language and navigator.language is very minimal for us. 22.07.2009, в 20:21, Maciej Stachowiak написал(а): * - Kind of off topic, but I found this incredibly frustrating recently when traveling in countries where I did not know the native language. Yes, this kind of auto-detection is quite frustrating, and it becomes even more frustrating when sites say This content is not available in your country. This makes me very skeptical of any proposals that let sites get more information about users without their explicit consent. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
2009/7/22 Alexey Proskuryakov a...@webkit.org 22.07.2009, в 16:41, Jungshik Shin (신정식, 申政湜) написал(а): Some web apps/widgets/browser extensions can also benefit from knowing the ordered list of languages in Accept-Language. I should note that Safari only sends one language. The reasons for this are: - protecting users' privacy, as a list of spoken languages can help identify a site visitor better than the primary preferred language; - improving Web compatibility, as servers happen to have most weird problems with complicated Accept-Language strings. Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list, and that they have to configure their browser to advertise other languages. I think that addresses the privacy concerns, assuming suitable wording in the configuration panel. I think this is a valuable extension to window.navigator because it is not revealing any additional information to the web app. They can already get this information by having a web server echo back the A-L header. This is just a short-cut convenience for use by web authors (avoiding a server round trip). -Darin So, the difference between Accept-Language and navigator.language is very minimal for us. 22.07.2009, в 20:21, Maciej Stachowiak написал(а): * - Kind of off topic, but I found this incredibly frustrating recently when traveling in countries where I did not know the native language. Yes, this kind of auto-detection is quite frustrating, and it becomes even more frustrating when sites say This content is not available in your country. This makes me very skeptical of any proposals that let sites get more information about users without their explicit consent. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exposing the value of Accept-Language via window.navigation.acceptLanguage ?
22.07.2009, в 22:36, Darin Fisher написал(а): Firefox and Chrome send very similar A-L headers. Given FF's marketshare, I'm surprised you observed compat problems with doing the same. Was that a recent observation? Can you provide more details about the issues you observed? It's not recent, see http://lists.macosforge.org/pipermail/webkit-dev/2005-June/000217.html . There is also some discussion in https://bugs.webkit.org/show_bug.cgi?id=3510 , not sure if any of it is still relevant. I do not have a reference handy, but IIRC, sending quality values was breaking some widely deployed intranet webmail system. It should be noted that normally people only have one value (or one family of values: en and en-US for example) on the A-L list, and that they have to configure their browser to advertise other languages. I think that addresses the privacy concerns, assuming suitable wording in the configuration panel. Safari takes the languages from system configuration. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
