Since SUMO has no 'pt' locale, requests with an Accept-Language of 'pt' currently get sent to 'pt-BR' because it's the first close match alphabetically. As I understand it, pt-BR is more up-to-date and complete than pt-PT at the moment, but I might be wrong. Should pt go to pt-PT? (It's a trivially easy fix, if so.)

Putting in folks from both pt-BR and -PT.

To which locale do you redirect en, for example?

I think the best option would be a redirect based on location when something like that happens. (In reply to comment #2) > To which locale do you redirect en, for example? +1

If I am reading RFC 4647 [1] correctly, then the first alphabetical choice [pt-BR] is the correct one. The other option is to offer users without a particular region preference a choice, saying something like this: "We see you are looking for Portuguese [pt]. We have multiple options for that. Please select your preference: * Portuguese (Angola) [pt-AO] * Portuguese (Brazil) [pt-BR] * Portuguese (Portugal) [pt-PT] * Portuguese (São Tomé and Príncipe) [pt-ST]" I've added some more hypothetical options (based on data from Wikipedia) of what may exist in the future. Ideally, a user should already specify that they're looking for a specific regional variation, such as pt-BR or pt-PT, if they know that it's a language with significant difference in orthography (or sound). If I only specify 'en' as a preference, I shouldn't be surprised if I am returned 'en-GB' despite my native language (and orthography) being 'en-US'. Also, this language selection interface should be applied to all languages that have multiple variations but no default, not just Portuguese. (English would probably be one of them, given en-US, en-GB, en-ZA, etc.) [1] http://tools.ietf.org/html/rfc4647

(In reply to comment #4) > The other option is to offer users without a particular region preference a > choice, saying something like this: > "We see you are looking for Portuguese [pt]. We have multiple options for > that. Please select your preference: It occurred to me that the question might arise as to which language this message should be displayed in. I presume that the overall default of SUMO is 'en-US', like everything else Mozilla, so that would remain the final fallback. However, if the user has another preferred language, then that should be used instead. For example, if I have an Accept-Language header of 'pt, fr, en', then you'd give me the Portuguese selection message in French. (I am presuming for the moment that 'fr' maps directly to a locale and doesn't have the same region-specific problem that we are talking about with Portuguese.) I think this ties in with the work that we're doing for BCP 47 support, because this proposal will involve translating each language/region/etc. name, so I'm marking it as blocking the meta tracking bug. We'll (hopefully) shortly be implementing a master list of such languages in Firefox, with a small portion of that being localizable by default; there's no reason why SUMO can't take advantage of that list. (Some or all of it may be based off of Unicode's CLDR, but that's outside the scope of this particular discussion.)

(In reply to comment #2) > To which locale do you redirect en, for example? en and en-* (e.g. en-GB, en-CA, etc) all go to en-US, because it is our only English locale. Similarly, all the various es-* that Firefox ships in go to es on SUMO, because we only have one Spanish locale. Since we don't ship a pt Firefox, only pt-PT or pt-BR, this would really only affect people who had added pt as a language choice (in the Options - Content panel, pt and pt-BR are available, but pt-PT is not) or someone who went manually went to http://support.mozilla.com/pt. (In reply to comment #4) > The other option is to offer users without a particular region preference a > choice, saying something like this: From a UX standpoint, we don't want to do this. We just want people to get to most-correct place.

(In reply to comment #0) > Should pt go to pt-PT? (It's a trivially easy fix, if so.) Without a language selector, it appears that the answer is no, at least according to RFC 4647. (In reply to comment #6) > Since we don't ship a pt Firefox, only pt-PT or pt-BR, this would really > only affect people who had added pt as a language choice (in the Options - > Content panel, pt and pt-BR are available, but pt-PT is not) or someone who > went manually went to http://support.mozilla.com/pt. Our BCP 47 work hopes to alleviate that issue of certain combinations not being available in the Languages preference panel.

if the Portuguese binary of Firefox asks for 'pt-PT' then that addresses my initial complaint. it might be nice if the Content options gave a pt-PT choice, but that's not a SUMO thing.

I agree with Luke Crouch... What is the default selection for portuguese (european) speakers when they install their pt-PT Firefox binary? Is "pt" selected by default as their language on their installations? Does that mean all pt-PT users are currently being redirected to support.mozilla.com/pt? If that's the case, I imagine that it would be best to change it. ** I cannot test this at the moment because I'm not using my personal computer.

If you download a Portuguese (Portugal) Firefox, it defaults to 'pt-PT' (just checked). The only time 'pt' shows up is if you want to add another language to your Accept-Languages list through the Options>Content panel. So, if you download Portuguese Firefox and never mess with these settings, you'll go to the correct version of SUMO. Apparently there are significantly more (>10x) pt-BR speakers than pt-PT, which leads me to think we shouldn't change anything.

Correct technical answer to the question is yes, it should go. Browser language options are 'pt' for pt-PT and 'pt-br' for pt-BR. At the moment, and until Ricardo doesn't make sure that most of the most important articles are available in pt-PT, I'd prefer that not to be corrected.

Yeah, this is probably a very rare edge case. Cheng, do you know whether we can check how many people asked for /pt articles?

(In reply to comment #12) > Cheng, do you know whether we can check how many people asked for /pt > articles? WebTrends doesn't know anything about redirects, it can only load on pages that execute JS. (In reply to comment #11) > At the moment, and until Ricardo doesn't make sure that most of the most > important articles are available in pt-PT, I'd prefer that not to be > corrected. Based on this, I'm going to WONTFIX for now. Thanks everyone for the input! Feel free to reopen or re-file if this changes.