Closed Bug 612857 Opened 15 years ago Closed 15 years ago

MDC no localized language Main pages (ex.developer.mozilla.org/ja) redirects incorrect URL

Categories

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Product:
developer.mozilla.org Graveyard
Component:
Wiki pages
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: potappo, Assigned: ozten)

References

(
URL
)

Details

(Keywords: jp-critical, Whiteboard: 0.9.2.1)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 Build Identifier: No localized language Main page URLs (all languages exclude Deutsch and English) redirect incorrect URLs (ex. https://developer.mozilla.org/en-US/ja). Please don't redirect until completing localization. Reproducible: Always Steps to Reproduce: 1.access https://developer.mozilla.org/ja 2. 3. Actual Results: redirects https://developer.mozilla.org/en-US/ja Expected Results: can access https://developer.mozilla.org/ja
Status: UNCONFIRMED → NEW
Ever confirmed: true
I suspect this is only German being on https://localize.mozilla.org/projects/mdn/, right, Fred?
Yes, that is true.
Keywords: jp-critical
1. fix redirect setting ASAP 2. write some guide/announce about MDN l10n on Verbatim x. don't setup l10n only for a locale without any announcement # Sorry if I missed your announcement about MDN l10n but AFAIK no announcement # or guide is posted to dev-l10n nor dev-l10n-web newsgroup.
Severity: major → critical
This is involved, and I don't really know what to do without risking more damage than benefit. As Fred is PTO, Austin, can you jump in and help out? On the one hand, mdn shouldn't 404 on locales that exist on deki, but not in mdn, IMHO. Not sure how to best fix that, maybe just add all locales? Not sure if we have a list of those, sheppy? Not clear if the old mdc entry page is inaccessible on purpose, can't get to the en one either. Jay, sheppy? On how to add locales to mdn, that is a bit confusing to me. My guess is that IT needs to deploy a new version of mdn, which needs to link to a new version of mdn-locales, which needs to pull new versions from svn, which needs localizers to push to vcs in verbatim. So we should start something at verbatim, just that the readme in https://github.com/fwenzel/mdn-locales confuses me good. I don't want to jump-start at things which we then throw away for technical reasons. Austin, I'd be glad to take instructions here, and corrections on the process.
Localized MDC top pages are here: https://developer.mozilla.org/index.php?title=ja https://developer.mozilla.org/index.php?title=fr MDN top page must show these pages for locales which don't have localized new MDN pages. But please make it sure, MDN top page must not redirected to above urls. Top page url must be kept as: https://developer.mozilla.org/ja/ https://developer.mozilla.org/fr/ That is, MDN top page should be alias (not redirect) of MDC top page if the local don't have new MDN top page. At the same time, Language selection menu on the bottom-right of MDN pages (not only top page but also other pages) must include other languages, not only German and English. If current MDN system cannot solve this critical problem soon, my suggestion is to back-out new MDN system until the problem is solved. To avoid more trouble like this, we should be able to test MDN l10n on staging server first.
Assignee: nobody → ozten.bugs
ozten: is there a way to ensure any existing top-level locale pages don't get redirected to the home page? it may be a while until localizers adopt the new django pages, so it looks like keeping the old MDC pages accessible for now is the best approach.
Severity: critical → blocker
Whiteboard: 0.9.2.2
(In reply to comment #5) Agreed that adding new locales is very confusing. I've started a page to capture the status of MDN and which pieces need to be updated. https://wiki.mozilla.org/MDN/MDN:L10n
(In reply to comment #7) We need up update Django's locales. I agree with comment #4, let's get a list of locales together for 0.9.2.2 release (mid-December). We can fix the /ja landing page issue from comment#1 by adding the ja locale in 0.9.2.1 (this Thursday), but do we want to push locales before they've been localized?
FWIW, https://developer.mozilla.org/En has a much longer locales list. We shouldn't focus this discussion around Japanese just because they're complaining the loudest. IMHO, we should get the django app to ignore locale codes it doesn't have and let deki try, that sounds like the least bad solution. We have well-localized content, we should show it.
(In reply to comment #11) It's weird, but the locale chooser for Deki is per wiki page. @Axel thanks for that link, will be a good target.
(In reply to comment #4) > 1. fix redirect setting ASAP We will keep en and de on Django. We will push all other locales straight to Dekiwiki. In the future we'll add Django back on a locale by locale basis.
Depends on: 615339
This fix is on stage9: https://developer-stage9.mozilla.org/ja
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: 0.9.2.2 → 0.9.2.1
When we select English from the top-right DekiWiki language menu on https://developer-stage9.mozilla.org/ja it is linked to https://developer-stage9.mozilla.org/en Is this intended? I think it's better to link to the new top page: https://developer-stage9.mozilla.org/en-US If you don't intend to keep old english top page, you should redirect? # note: # de page is new top page, only English have both old en and new en-US On the other hand, once user come to the en or de top page, they cannot back to their language page since no language menu (only de and en so far) for them on the top page. Yes, this is not easily solved with only redirect but this should be handled as an exception case until all locales move to new MDN style I believe.
qa-verified https://developer.mozilla.org/JA
Status: RESOLVED → VERIFIED
Keywords: qawanted
Component: Website → Landing pages
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.