This is probably a good idea for most cases, but we should make sure this doesn't break any of the Deki l10n dependencies for en-US docs and their relationship with localized versions of those docs.
I think localizing the href's actually FIXES Deki stuff. Right now if I set my browser to Deutsch and go to /docs/ I'm correctly forwarded to https://developer.mozilla.org/de/docs by django. But, because the href's are hard-coded to /en/* deki doesn't honor my browser language preference. I even tried setting my DekiWiki language preference to Deutsch and the hard-coded href's override even Deki's own preference! What are Deki's dependencies for en-US docs? This will be important to fix if/when 0.9.3 goes out touting localization features. Should we make this a 0.9.3 bug then?
bump. Jay: want to make this a 0.9.3 blocker? should I start slogging away at the /en/ links?
(In reply to comment #0) Should we make the href's a gettext string, or should we just auto-detect language for the request and auto-replace 'en' with the language code? (via the devmo_url helper)
I'll see how tricky it would be to auto-detect the language for the request, check the dekiwiki database for a localized version of the page to serve either the localized URL or default to 'en'. If that's going to be too much, I'll make the href's into gettext strings so localizers can manually check the wiki and change the url's by locale.
This will need memcache on staging and production so we don't make dozens of http requests to dekiwiki for every mdn page. And we will want to change the CACHE_BACKEND in settings[_local].py to memcached.
Let's get IT to help get this blocker fixed for 0.9.3. It's an important release for l10n and this will be a huge win for us.
cronjob and memcache are good. href strings are ready for localizers in verbatim.
verified fixed https://developer.mozilla.org/en-US/