Closed Bug 647796 Opened 13 years ago Closed 11 years ago

Broken parsing of Accept-Language for language redirection

Categories

(developer.mozilla.org Graveyard :: Localization, defect, P1)

Product:
developer.mozilla.org Graveyard
Component:
Localization
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fvsch, Unassigned)

References

(
URL
)

Details

(Whiteboard: [specification-like][type:bug][selected]) 

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: 

When going to http://developer.mozilla.org (or https://developer.mozilla.org) the user gets redirected to a specific language version. This redirection seems to be based on the value of the HTTP header Accept-Language, but the parsing of this value is probably wrong.

Four examples of this bug, with cookies disabled and varying Accept-Language configs:

1. Accept-Language:en,fr;q=0.5
   Redirects to: https://developer.mozilla.org/fr/ (expected: /en/ or /en-US/)
2. Accept-Language:en,de;q=0.5
   Redirects to: https://developer.mozilla.org/de/ (expected: /en/ or /en-US/)
3. Accept-Language:it,en;q=0.8,de;q=0.5,en-us;q=0.3
   Redirects to: https://developer.mozilla.org/de/ (expected: /it/)
4. Accept-Language:it,en;q=0.8,en-us;q=0.5,de;q=0.3
   Redirects to: https://developer.mozilla.org/en-US/ (expected: /it/)

It seems the redirection only considers the "new" language versions, including:
https://developer.mozilla.org/en-US/
https://developer.mozilla.org/fr/
https://developer.mozilla.org/de/
And excluding:
https://developer.mozilla.org/en
https://developer.mozilla.org/it
https://developer.mozilla.org/fr

In Accept-Language, "en" is not matched with "en-US" (I think it should!), and "it" is not matched since there is no new Italian version yet (no idea on what should be done for this).

Reproducible: Always
This bug is just for 'en' not matching to 'en-US'

'it' would match if there were an Italian translation available.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Two things:
- I would argue that if a user asks for 'en-GB' (or any 'en-..' but not 'en-US' or 'en', he should be directed to 'en-US' as well. For technical reasons discussed in Bug 647801, it seems 'en-US' is the new 'en'. ;)
- I see there is a 'it' version at https://developer.mozilla.org/it but I guess it was too embryonic to be ported to the new system.
> I see there is a 'it' version at https://developer.mozilla.org/it but I guess
> it was too embryonic to be ported to the new system.
That's the Italian home page of the *Doc Center* (i.e., the DekiWiki system). We don't auto-redirect to '/it/' because we don't have an Italian translation of the django content. :(
OS: Mac OS X → All
Priority: -- → P1
Hardware: x86 → All
Component: Website → Localization
Still an issue on Kuma. Up-to-date information and steps to repeat in bug 773501.
My browser is set with Accept-Language:en,en-US;q=0.8,ja;q=0.6 and I still get redirected to the Japanese version of the site.
Hey Glen. Are you using Chrome? As a workaround, you can remove "ja" from your list of languages completely.
The Accept-Language is clearly set to prioritize English. Why do you care if he's using Chrome?
(In reply to fantasai from comment #9)
> The Accept-Language is clearly set to prioritize English. Why do you care if
> he's using Chrome?

We still do not completely understand what causes this. I have only seen this behavior in Chrome, so I'm wondering if it might be a Chrome-only bug.
As far as design / expected results: The goal here should simply be to redirect the user to his preferred language as reflected in his browser settings.

Or as a rule of thumb: Behavior should be identical to that of mozilla.org

At the moment, entering mozilla.org in Chrome redirects me to http://www.mozilla.org/en-US/. Entering developer.mozilla.org in Chrome redirects me to https://developer.mozilla.org/fr/.
OK, I can confirm that this issue is not exclusive to Chrome. I can experience it on Aurora 20.

It seems part of the problem here is that the code is assuming that incoming language preferences are completely lowercase, which means any language tag with capital letters in it will fail. (For example, 'en-US' will not match 'en-us'.)

The fix for this is simple, I think:
https://github.com/mozilla/kuma/blob/master/apps/devmo/urlresolvers.py#L90

Change this:
            supported = [lang[0] for lang in ranked_languages if lang[0]
                        in settings.LANGUAGE_URL_MAP]

To this:
            supported = [lang[0] for lang in ranked_languages if lang[0].lower()
                        in settings.LANGUAGE_URL_MAP]

However, I'm not sure that this will fix the original issue in comment 0, if it still exists.
Actually, since I haven't attempted to test this proposed fix, you might have to change the first lang[0] to lang[0].lower(), too. I don't know where the code ends up after it gets through here.
(In reply to Gordon P. Hemsley [:gphemsley] from comment #13)
> Actually, since I haven't attempted to test this proposed fix, you might
> have to change the first lang[0] to lang[0].lower(), too. I don't know where
> the code ends up after it gets through here.

Oh, no need for that. It's lowercased later, a few lines down. The single change is all that's necessary.

Sorry for the bugspam.
Oh, one other outstanding issue would be to ensure that 'en' maps to 'en-US'. Otherwise, someone who specifies "en,fr;q=0.5" will get 'fr' instead of 'en-US', which we probably don't want to happen.

Here's how it was done for Portuguese ('pt' to 'pt-PT'):
https://github.com/mozilla/kuma/blob/master/settings.py#L142
Actually, there are a number of locales that need aliases, because they are listed (often unnecessarily) with the region subtag:

* en-US
* bn-BD
* fy-NL
* ga-IE
* zh-CN / zh-TW

(Portuguese [pt-PT / pt-BR] already has an alias [pt].)

If I have an Accept-Language header of "abc,bn;q=0.9,fy;q=0.8,ga;q=0.7,zh;q=0.6", I will be given 'en-US' (because that is the ultimate fallback).

Any lone locale with a region subtag should have as an alias the language subtag only:

* en => en-US
* bn => bn-BD
* fy => fy-NL
* ga => ga-IE

For multiple locales sharing a base language, the alias target would have to be decided upon, with consultation with the l10n communities, based on one of two criteria: (1) the region with the most speakers, or (2) the region more associated with the language.

This has already been done for Portuguese [pt], which was aliased to 'pt-PT' (presumably) using the second factor.

For Chinese, the situation might be a little more complex, but I would recommend aliasing 'zh' to 'zh-CN' as a preliminary decision.

The situation for English a bit of a special case, since 'en-US' is the original locale. 'en' should be aliased to 'en-US' primarily for that reason, even though the other two criteria would otherwise normally apply. (The difference is, aliases for other languages may change as new communities arise or population shifts; for English, unless the original locale changes, 'en' should always point to 'en-US'—even if 'en-GB' is created.)
Really great research here. This will really help. Thank you, Gordon!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to [github robot] from comment #18)
> Commits pushed to master at https://github.com/mozilla/kuma
> 
> https://github.com/mozilla/kuma/commit/
> 9f541063e8e277ac594e536a654a83c3c9446add
> fix bug 647796 - shorter locales
> 
> https://github.com/mozilla/kuma/commit/
> 20a90a91bc048b65a96d434d7346bc4c410c94bb
> Merge pull request #892 from darkwing/ua-parse-647796
> 
> fix bug 647796 - shorter locales

This only fixes the issue mentioned in comment 16 (except Chinese), which was mostly tangential. It doesn't address the main issue, which was described in comment 12.

Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
<battlestar>All of this has happened before...</battlestar>

Providing aliases for everything is a whackamole solution.

Kitsune addressed this in bug 621389 and bug 639818, leading to the following method, which apparently happened post-schism: sumo.urlresolvers.get_best_language[1].

Taking Gordon's example Accept-Language header from comment 16:

>>> get_best_language('abc,bn;q=0.9,fy;q=0.8,ga;q=0.7,zh;q=0.6')
bn-BD

(Obviously, that depends on bn-BD being a valid language on SUMO.) Pulling get_best_language out let us write pretty good tests for it[2].

The only locale aliases necessary with the updated urlresolvers module in kitsune are where a locale intentionally redirects to a different locale (e.g.: Breton to French[3]). (In this case, 'br-FR' still goes to 'fr' as expected, even though only 'br' is in the list.)

[1]: https://github.com/mozilla/kitsune/blob/master/apps/sumo/urlresolvers.py#L76
[2]: https://github.com/mozilla/kitsune/blob/master/apps/sumo/tests/test_locale_middleware.py#L60 (Though in retrospect, I should've written test generators. Oh well.)
[3]: https://github.com/mozilla/kitsune/blob/master/settings.py#L187
This implementation is based on (but ignores rare cases from) BCP 47 section 4.1[1].

[1]: http://tools.ietf.org/html/bcp47#section-4.1
(In reply to James Socol [:jsocol, :james] from comment #20)
> Providing aliases for everything is a whackamole solution.

This is not providing aliases for everything; this is providing aliases for locales whose language tags are more specific than they should be, or for when multiple locales share a common language. Ideally, the former situation should not occur with new locales in the future. (The latter situation is often inevitable, when it occurs, but no automatic parsing can determine the best value for the alias in that case.)

> Kitsune addressed this in bug 621389 and bug 639818, leading to the
> following method, which apparently happened post-schism:
> sumo.urlresolvers.get_best_language[1].
> 
> Taking Gordon's example Accept-Language header from comment 16:
> 
> >>> get_best_language('abc,bn;q=0.9,fy;q=0.8,ga;q=0.7,zh;q=0.6')
> bn-BD
> 
> (Obviously, that depends on bn-BD being a valid language on SUMO.) Pulling
> get_best_language out let us write pretty good tests for it[2].

If I'm reading settings.py correctly, MDN and SUMO are sharing the same list of supported locales:

LANGUAGE_URL_MAP is created based on PROD_LANGUAGES, which come from MDN_LANGUAGES.

That being said, it does indeed (at first glance) look like get_best_language() would be an improvement over the current situation. (But see below.)

> The only locale aliases necessary with the updated urlresolvers module in
> kitsune are where a locale intentionally redirects to a different locale
> (e.g.: Breton to French[3]). (In this case, 'br-FR' still goes to 'fr' as
> expected, even though only 'br' is in the list.)

We have two issues here:

* Providing fallback for the case when the user requests the general locale and we only have a specific one (e.g. 'bn' vs. 'bn-BD', or 'pt' vs. 'pt-PT', or 'sr' vs. 'sr-Cyrl', or 'nb-NO'/'nn-NO' vs. 'no').
* Providing fallback for the case when a user requests a minority locale and we only have the majority locale from the same area (e.g. 'csb' vs. 'pl').

The first issue we clearly need to handle, because it involves idiosyncrasies with MDN.

The second issue, however, is less clear. By having these redirects, we are potentially overriding the user's actual preferences. For example, someone with an Accept-Language header of "br,cy;q=0.9,en-GB;q=0.8,fr;q=0.7" would get the French locale even though they'd prefer Welsh (if we had a Welsh locale) or British English over French. This example also raises the issue of whether this use should 'en-US' instead of 'fr'; which would they prefer more: American English, or French?

I would argue that the best thing to do is to respect the user's preference as much as possible, before doing any fancy guesswork. And to do that, I think we should run through their list literally (with the minimal redirects under the first issue above) before modifying their choices. That would mean the user above would get the first one available of this list:

* Breton
* Welsh
* English (United Kingdom)
* French
* English (United States)

Under the current system, it seems this fallback hierarchy would be short-circuited upon that first request for Breton. I don't think that's particularly good, at least not for a first pass. (It may be useful on a second pass, though. For example, if a user's preference was "br,cy;q=0.9", they'd probably prefer French (an override) over American English (the absolute default).)
(In reply to Gordon P. Hemsley [:gphemsley] from comment #22)
> (In reply to James Socol [:jsocol, :james] from comment #20)
> > Providing aliases for everything is a whackamole solution.
> 
> This is not providing aliases for everything; this is providing aliases for
> locales whose language tags are more specific than they should be, or for
> when multiple locales share a common language.

And that is unnecessary, it can be solved in a general way (and it has been).

> If I'm reading settings.py correctly, MDN and SUMO are sharing the same list
> of supported locales:
> 
> LANGUAGE_URL_MAP is created based on PROD_LANGUAGES, which come from
> MDN_LANGUAGES.

Not precisely, no. SUMO uses the SUMO_LANGUAGES tuple, and doesn't have PROD_LANGUAGES. MDN uses MDN_LANGUAGES, which is a different set, and it involves more indirection.

> > The only locale aliases necessary with the updated urlresolvers module in
> > kitsune are where a locale intentionally redirects to a different locale
> > (e.g.: Breton to French[3]). (In this case, 'br-FR' still goes to 'fr' as
> > expected, even though only 'br' is in the list.)
> 
> We have two issues here:
> 
> * Providing fallback for the case when the user requests the general locale
> and we only have a specific one (e.g. 'bn' vs. 'bn-BD', or 'pt' vs. 'pt-PT',
> or 'sr' vs. 'sr-Cyrl', or 'nb-NO'/'nn-NO' vs. 'no').

This is explicitly handled by the linked code.

> * Providing fallback for the case when a user requests a minority locale and
> we only have the majority locale from the same area (e.g. 'csb' vs. 'pl').

As is this.

The Kitsune code I linked solves this in a more general way than the current Kuma code. It might not be perfect and certainly the rest can be argued out further, but don't let perfect be the enemy of better.

Onward...

> The second issue, however, is less clear. By having these redirects, we are
> potentially overriding the user's actual preferences. For example, someone
> with an Accept-Language header of "br,cy;q=0.9,en-GB;q=0.8,fr;q=0.7" would
> get the French locale even though they'd prefer Welsh (if we had a Welsh
> locale) or British English over French. This example also raises the issue
> of whether this use should 'en-US' instead of 'fr'; which would they prefer
> more: American English, or French?

In this case, the decision was made by the Breton community to redirect to French. If they had not made that decision, "br" would be missed and it would fallback.

To address en-US specifically: Firefox has multiple English localizations (en-US, en-GB, and en-ZA) but none of our websites (that I know of) do. We've all basically stuck with en-US instead of using 'en' because (1) we all are, we'd want to change that everywhere, and changes everywhere are hard, and (2) changing it to 'en' adds an extra redirect for who knows how many links even within Mozilla, let alone on the web.

Basically, we consider "en-US" == "en" for our purposes. This is not be something everyone would do, but it works well-enough across our websites. So if you say "en-GB;q=0.8,fr;q=0.7", we, and I think most, would assume that English is higher preference than French, especially given that en-GB and en-US are, except slang, mutually intelligible.

> I would argue that the best thing to do is to respect the user's preference
> as much as possible, before doing any fancy guesswork. And to do that, I
> think we should run through their list literally (with the minimal redirects
> under the first issue above) before modifying their choices. That would mean
> the user above would get the first one available of this list:

As above, English is a special case, but I do take your point.

> Under the current system, it seems this fallback hierarchy would be
> short-circuited upon that first request for Breton. I don't think that's
> particularly good, at least not for a first pass. (It may be useful on a
> second pass, though. For example, if a user's preference was "br,cy;q=0.9",
> they'd probably prefer French (an override) over American English (the
> absolute default).)

What the current system does is allow the Breton community to say "yes, br is a supported locale insofar as we know about it, but we're not localizing this content into Breton, just use French." The user asked for br first, and we, in a way consistent with the br localizers' intentions, honored that request.
Whiteboard: [specification-like][type:bug][selected]
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/2a8d33532ec3ba7cd1a20895c1e65fac5fc85841
fix bug 647796 - better accept-language logic

https://github.com/mozilla/kuma/commit/2b9606b30b959368f7712a216578d116bb50e77c
Merge pull request #918 from groovecoder/accept-language-647796

fix bug 647796 - better accept-language logic
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Found a bug with the redirect code we implemented. Re-opening until we can fix it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
bug reported in IRC:

16:24:14 - openjck: Just to be sure I understand -- what do we mean by bad redirects?
16:24:31 - ericz: < nagios-pek1> | Mon 14:10:19 PDT [616] devmo-zlb.vips.pek1.mozilla.com:https - developer.mozilla.org is WARNING: HTTP WARNING - maximum redirection depth 15 exceeded - cyborgsh~ https://developer.mozilla.org:443/sv/sv/sv/sv/sv/sv/sv/sv/sv/sv/sv/sv/sv/sv/sv/sv/ (http://m.allizom.org/https+-+developer.mozilla.org)
16:24:39 - ubernostrum: Oh.
16:24:48 - ericz: And someone else got redir'd to https://developer.mozilla.org/en-US/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/sr-CYRL/
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/61720e63c9093ad71c39d4197da5c7f9d95d4200
fix bug 647796 - get_best_language without NSL bug

https://github.com/mozilla/kuma/commit/ee43ae05d8f451783e29e6a591074bab71643165
Merge pull request #924 from groovecoder/accept-language-bug-fix-647796

fix bug 647796 - get_best_language without NSL bug
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
(In reply to James Socol [:jsocol, :james] from comment #23)
> (In reply to Gordon P. Hemsley [:gphemsley] from comment #22)
> > (In reply to James Socol [:jsocol, :james] from comment #20)
> > > Providing aliases for everything is a whackamole solution.
> > 
> > This is not providing aliases for everything; this is providing aliases for
> > locales whose language tags are more specific than they should be, or for
> > when multiple locales share a common language.
> 
> And that is unnecessary, it can be solved in a general way (and it has been).

I am arguing that solving this problem in a general way is the wrong thing to do. The region subtag cannot just be arbitrarily discarded as superfluous; it is an important part of the expression of the user's preferences.

For example, if a user's preference was "bn-IN,hi;q=0.9,bn;q=0.8", the general case might serve them 'bn-BD' instead of the more appropriate 'hi'. (Keep in mind that the actual value of the 'q' parameter is irrelevant; it only serves to rank the language preferences into an order. It is only the order that matters: this preference could just as easily be presented as "bn-IN,hi;q=0.3,bn;q=0.001".)

> > If I'm reading settings.py correctly, MDN and SUMO are sharing the same list
> > of supported locales:
> > 
> > LANGUAGE_URL_MAP is created based on PROD_LANGUAGES, which come from
> > MDN_LANGUAGES.
> 
> Not precisely, no. SUMO uses the SUMO_LANGUAGES tuple, and doesn't have
> PROD_LANGUAGES. MDN uses MDN_LANGUAGES, which is a different set, and it
> involves more indirection.

Again, perhaps I am missing something, but I see no mention of SUMO_LANGUAGES in SUMO's get_best_language(), linked in comment 20 above.

> > > The only locale aliases necessary with the updated urlresolvers module in
> > > kitsune are where a locale intentionally redirects to a different locale
> > > (e.g.: Breton to French[3]). (In this case, 'br-FR' still goes to 'fr' as
> > > expected, even though only 'br' is in the list.)
> > 
> > We have two issues here:
> > 
> > * Providing fallback for the case when the user requests the general locale
> > and we only have a specific one (e.g. 'bn' vs. 'bn-BD', or 'pt' vs. 'pt-PT',
> > or 'sr' vs. 'sr-Cyrl', or 'nb-NO'/'nn-NO' vs. 'no').
> 
> This is explicitly handled by the linked code.
> 
> > * Providing fallback for the case when a user requests a minority locale and
> > we only have the majority locale from the same area (e.g. 'csb' vs. 'pl').
> 
> As is this.

The code makes no distinction between the two, AFAIK. I believe that was part of the point I was making.

> The Kitsune code I linked solves this in a more general way than the current
> Kuma code. It might not be perfect and certainly the rest can be argued out
> further, but don't let perfect be the enemy of better.

I think my argument here was that it wasn't clear that the new method was in fact better (except insofar as it reduces code duplication).

> > The second issue, however, is less clear. By having these redirects, we are
> > potentially overriding the user's actual preferences. For example, someone
> > with an Accept-Language header of "br,cy;q=0.9,en-GB;q=0.8,fr;q=0.7" would
> > get the French locale even though they'd prefer Welsh (if we had a Welsh
> > locale) or British English over French. This example also raises the issue
> > of whether this use should 'en-US' instead of 'fr'; which would they prefer
> > more: American English, or French?
> 
> In this case, the decision was made by the Breton community to redirect to
> French.

With all due deference to the l10n communities, my experience suggests that they in general do not understand the technicalities inherent in dealing with language fallback. Consulting them is obviously important for understanding the linguistic realities surrounding a locale, but I do not think it is the l10n community that should have final authority over mostly technical matters.

> If they had not made that decision, "br" would be missed and it
> would fallback.

I am arguing that that is how it should be.

> To address en-US specifically: Firefox has multiple English localizations
> (en-US, en-GB, and en-ZA) but none of our websites (that I know of) do.
> We've all basically stuck with en-US instead of using 'en' because (1) we
> all are, we'd want to change that everywhere, and changes everywhere are
> hard, and (2) changing it to 'en' adds an extra redirect for who knows how
> many links even within Mozilla, let alone on the web.
> 
> Basically, we consider "en-US" == "en" for our purposes. This is not be
> something everyone would do, but it works well-enough across our websites.

Yes, that is exactly the fact I am asserting: "en-US" == "en" in all Mozilla cases. But, rather than handling it explicitly, as you should be, you are relying on the (IMO incorrect) "general" handling that simply chops off region tags in an attempt to match locales. 

> So if you say "en-GB;q=0.8,fr;q=0.7", we, and I think most, would assume
> that English is higher preference than French, especially given that en-GB
> and en-US are, except slang, mutually intelligible.

But I am arguing that such an assumption would be incorrect. The user has clearly expressed the preferences they want to express. If you don't have English as spoken in the United Kingdom, they want French. If they had no preference as to the variety of English they received, they would have used 'en' instead of 'en-GB'.

It is much more a game of whackamole to assume that languages that share a language subtag are as mutually intelligible as 'en-US' and 'en-GB' happen to be. And, in fact, it is that 'slang' (AKA localization) that you refer to that often spells the difference between such locales in the first place. If you, as an 'en-US' speaker, were forced to use a locale that had elevators labeled as lifts and curbs labeled as kerbs and jails labeled as gaols, you'd be disoriented, too.

> > Under the current system, it seems this fallback hierarchy would be
> > short-circuited upon that first request for Breton. I don't think that's
> > particularly good, at least not for a first pass. (It may be useful on a
> > second pass, though. For example, if a user's preference was "br,cy;q=0.9",
> > they'd probably prefer French (an override) over American English (the
> > absolute default).)
> 
> What the current system does is allow the Breton community to say "yes, br
> is a supported locale insofar as we know about it, but we're not localizing
> this content into Breton, just use French." The user asked for br first, and
> we, in a way consistent with the br localizers' intentions, honored that
> request.

It does matter whether we "know about" a locale if we don't have an actual localized version of the interface to match. It is precisely the "oh, you asked for Breton? you must read French" assumption that the Accept-Language header is designed to avoid.

(In reply to [github robot] from comment #27)
> https://github.com/mozilla/kuma/commit/
> 61720e63c9093ad71c39d4197da5c7f9d95d4200
> fix bug 647796 - get_best_language without NSL bug

This change does nothing to fix the underlying problem of infinite redirects. All it does is remove all of the mappings that might generate a redirect, which is a terrible way to "fix" the problem.

If a user "asks" for the 'sv-SE' to 'sv' or 'sr' to 'sr-Cyrl' mappings, as the comment suggests they do, then the problem will just happen again.

I am reopening this bug, as I don't think it is entirely fixed. (In fact, I don't really know where it stands at this point.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Without actually responding to your arguments, can we please open a new bug, and/or move discussion to the dev-mdn mailing list? The original issue here has been fixed and what you're asking for is a massive change of scope.
Here's a dev-mdn thread about alternative locales for MDN:

https://groups.google.com/forum/#!topic/mozilla.dev.mdn/D6nSmN9RTz4
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
(In reply to James Socol [:jsocol, :james] from comment #29)
> Without actually responding to your arguments, can we please open a new bug,
> and/or move discussion to the dev-mdn mailing list? The original issue here
> has been fixed and what you're asking for is a massive change of scope.

I've submitted a pull request to implement what I was suggesting:

https://github.com/mozilla/kuma/pull/930

We can discuss there, if necessary.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
See Also: → 1461350
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.