327517 - joelonsoftware.com - Incorrectly translates language settings

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Kenneth Miller]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0

I have English first in the list in the International pref pane, but the included URL still sees me as French.  (Only shows up in the post dates.)  Safari and FF both show up as English.

For the sake of thoroughness, I used http://gemal.dk/browserspy/accept.php to double check what the site is seeing.  Here's what it said:

en
ja;q=0.9
fr;q=0.9
de;q=0.8
es;q=0.7
it;q=0.7
nl;q=0.6
sv;q=0.5
nb;q=0.5
da;q=0.4
fi;q=0.3
pt;q=0.3
zh-hans;q=0.2
zh-hant;q=0.1
ko;q=0.1

Firefox got this:
en-us
en;q=0.5

Safari had this:
en

This could totally be a bug on their site!  But, given that other browsers seem to do OK, I thought you should know.


Reproducible: Always

Steps to Reproduce:
1. Go to URL
2. Look at dates

Actual Results:  
French dates

Expected Results:  
English dates

I've been unble to convince this to work properly using normal means, but haven't tried editing user.js.  The problem is trivial in this particular case, but if other sites are interpreting the accepted languages in the same way, it could be more serious.

Comment 1

[Chris Lawson (gone)]

This is probably similar to (and therefore INVALID) the same bug on eBay (bug 317875).

Someone should let Joel know his site is b0rken.

cl

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

There have been a series of recent reports of sites "ignoring" the first value in a list and choosing the second or third item in the list (bug 323670, some threads in the forum I can't find atm).

Kenneth, can you confirm that the order of the languages in the International pane of the System Prefs matches exactly with the order of the languages reported by gemal.dk?

If so, I don't think this is anything we're getting wrong and the bug in Joel's server; you can probably work around the problem by unchecking the languages you don't speak in the System Prefs and then launching Camino.

(This WFM, btw, with en-us,en,fr,ar as my accept-lang)

Comment 3

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060213 Firefox/1.6a1
confirming, if I use the sequence en,ar,fr or  en,fr,ar
wfm, if i use the sequence en,en-us,fr,ar

Languages accepted 	en
ar;q=0.7
fr;q=0.3

gives english text, french date:

Apologies for the length of this.
Patrick from an IBank Send private email
mercredi 8 février 2006 


So it seems first language 'en' is ignored, 2nd language 'ar' is unknown to the server, 3rd language 'fr' picked for the date.

According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4
1st language is default q=1.0, so 'en' should be picked instead of 'fr;q=0.3'
as that represents 'en;q=1.0'

I've found that link in Bug 302007 getting 404 in wrong language

Comment 4

[Kenneth Miller]

Yes, the order matches exactly, and updates if I move things around.  I wasn't able to make it give me en-us as one of the list, but I think I just figured it out.  I'll try it and post back.

Comment 5

[Kenneth Miller]

OK, I managed to get it to insert en-US as a language, and so long as that's there (and before non-English languages) everything is peachy.  If it's just en, no dice.  

Comment 6

[Samuel Sidler (old account; do not CC)]

This isn't a Camino bug, but rather a bug with the website. If you wish to keep this open, because you're planning on contacting them, please move it to tech evangelism. Otherwise, close it as INVALID.

Comment 7

[Bob Clary [:bc] (inactive)]

sent a note. lets see.

Comment 8

[Joel Spolsky]

"en" is ambiguous --- you need to specify "en-us" or "en-gb".

Because US and GB format dates differently (m/d/y vs d/m/y) it is not possible to format a date in "en" format.

This behavior is a part of how ASP and IIS will handle locales, i.e., it's a Windows Server behavior (and not a bug in my opinion) so it's not a joelonsoftware.com bug.

Comment 9

[Joel Spolsky]

I would argue that Firefox should not include "English" in the list of languages in the languages options preference, for this reason. Make people choose a dialect.

Comment 10

[Bob Clary [:bc] (inactive)]

smontagu, darin: so is this user error in selecting the language preferences, or should we remove [en] as a choice as Joel suggests?

Comment 11

[Chris Lawson (gone)]

(In reply to comment #8)
> "en" is ambiguous --- you need to specify "en-us" or "en-gb".
> 
> Because US and GB format dates differently (m/d/y vs d/m/y) it is not possible
> to format a date in "en" format.
> 
> This behavior is a part of how ASP and IIS will handle locales, i.e., it's a
> Windows Server behavior (and not a bug in my opinion) so it's not a
> joelonsoftware.com bug.

Surely you can develop an intelligent fallback system; i.e., assume en-us if only given "en".

The Mac OS does NOT assign a locale to English-US systems. (It may give en-gb for British, but I haven't seen the results of the above link on a British Mac OS.) Rather, Safari (and Camino, since it uses the OS's language settings too) simply sends "en" in the accept-language header.

Clearly the proper thing to do in this case is NOT to punt entirely and send the user French.

cl

Comment 12

[Benjamin Smedberg]

The HTTP 1.1 specification explicitly recommends that the generic language *should* be included in the Accept-Lang header and if the user selects "en-US" but not "en" the UA should recommend "en".

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.5

If anything the client bug is that when the user selects English (correctly) we should also ask them to select appropriate language subtypes.

Comment 13

[Joel Spolsky]

well, we want to be liberal in what we accept, so we'll silently change en to en-us.

I do want to point out that a large class of web services written for ASP and IIS will exhibit this problem if the language preferences include "en" but not a region. 

The writer of the HTTP 1.1 spec was apparently not aware that "en" does not give enough information to display a date, and therefore web applications presented with only "en" as an option will have trouble displaying dates (and will likely confuse the user with m/d vs. d/m format)

One could argue that punting to the user's second language choice is completely reasonable in this case. Since I don't know how to format dates in "en," I'll pick some other language for dates that you do know. This is better than formatting a date as, e.g. 3/1 and have you misinterpret it as March 1 when I meant Jan 3.

Comment 14

[Chris Lawson (gone)]

(In reply to comment #13)
> The writer of the HTTP 1.1 spec was apparently not aware that "en" does not
> give enough information to display a date, and therefore web applications
> presented with only "en" as an option will have trouble displaying dates (and
> will likely confuse the user with m/d vs. d/m format)

Perhaps the flaw is in assuming that date format preference and language preference are in any way related. A more ideal solution would be presenting dates (and times) in an unambiguous format in the first place.

cl

Comment 15

[Kenneth Miller]

> Perhaps the flaw is in assuming that date format preference and language
> preference are in any way related. A more ideal solution would be presenting
> dates (and times) in an unambiguous format in the first place.

Indeed.  I think the point of specifying just "English" as a possibility is to say, "I don't mind regional differences, just please show me english text of any variety."  Your dates are long-form anyway -- no problems with confusion when it says "February 28, 2006". 

Comment 16

[Simon Montagu :smontagu]

(In reply to comment #12)
> The HTTP 1.1 specification explicitly recommends that the generic language
> *should* be included in the Accept-Lang header and if the user selects "en-US"
> but not "en" the UA should recommend "en".

True, but the current behaviour of sending *only* the generic language by default seems odd to me, and not consistent with what we do on other platforms. 

(In reply to comment #14)
> Perhaps the flaw is in assuming that date format preference and language
> preference are in any way related.

This is theoretically correct, but it's a fairly common practice to overload Accept-Language in this way.

Comment 17

[Karl Dubost💡 :karlcow]

This seems to be resolved.