Open Bug 1486543 Opened 6 years ago Updated 6 years ago

404 when clicking "Next" on Content Blocking intro

Categories

(www.mozilla.org :: L10N, enhancement)

Production
enhancement
Not set
normal

Tracking

(firefox63 affected)

Tracking Status
firefox63 --- affected

People

(Reporter: bhearsum, Unassigned)

Details

I got the Content Blocking intro after updating to the latest Nightly today and when I tried to click through it, I got sent to a page that was a 404 (https://www.mozilla.org/en-CA/tl/firefox/63.0a1/tracking-protection/start/?newtab=true&step=2&variation=2) It looks like it may have tried to go to https://www.mozilla.org/tl/firefox/63.0a1/tracking-protection/start/?newtab=true&step=2&variation=2, and then got redirected to the page above (based on geolocation, I guess?). I'm running the Tagalog (tl) nightly, which presumably has no translated page available.
Blocks: privacy-ui
Priority: -- → P2
Alex, should this fall back to en-US when it's not translated?
No longer blocks: privacy-ui
Component: Tracking Protection → Pages & Content
Flags: needinfo?(agibson)
Priority: P2 → P1
Product: Firefox → www.mozilla.org
Version: Trunk → Production
Priority: P1 → --
Thanks for filing this. We don't redirect users based on their physical location, just according to their accept language header provided by the browser. It looks like `tl` is not currently a supported language in production, hence the redirect and 404 [1] [1] https://github.com/mozilla/bedrock/blob/master/bedrock/settings/base.py#L117-L129 needsinfo'ing Peiying so she can take a look.
Component: Pages & Content → L10N
Flags: needinfo?(agibson) → needinfo?(pmo)
Passing by note: Tagalog is still a Nightly only locale.
Hmm... yeah. It's unfortunate that it's specifically sending you to www.m.o/tl/*. This could be happening to other languages as the list of production languages on the website won't necessarily match the list of languages in which Firefox is available. It'd be better if the URL didn't include a locale at all and let the website pick the best one based on the user's accept-language header. It's tough to distinguish between just a short first component of a URL and a real (but unsupported) locale. We could potentially do a diff of the list of our prod locales and those from Firefox (in product-details) and at least strip the unsupported ones from URLs so that they don't 404 but redirect to the next best locale for the user. I'll look into that.
This page is not activated among many recently added pages since before Quantum launch: https://pontoon.mozilla.org/tl/mozillaorg/. The recently launched Rocket and the associated legal doc requires 'tl' in better shape than it is now. The team has promised to finish it in a couple of weeks but no progress so far. I am looking into alternative solution, after reaching out to the community again to get their take, so we can get through this hurtle.
Flags: needinfo?(pmo)
You need to log in before you can comment on or make changes to this bug.