1523590 - In-product links are broken if locale is undefined or not available in SUMO

Status: REOPENED

(support.mozilla.org :: Localization, defect)

Description

[Reşat SABIQ (Reshat)]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

Using crh Nightly, accessed:

1. Firefox Help (Yardımı):
2. Keyboard Shortcuts (Klavye Qısqayolları)

Actual results:

URLs are invalid:

1. https://support.mozilla.org/1/firefox/65.0a1/Linux/crh/firefox-help
   1.1. Lands on: https://support.mozilla.org/tr/crh/products/firefox?as=u&utm_source=inproduct
2. https://support.mozilla.org/1/firefox/65.0a1/Linux/crh/keyboard-shortcuts
   2.1. Lands on: https://support.mozilla.org/tr/crh/kb/Keyboard%20shortcuts?as=u&utm_source=inproduct

Expected results:

Valid pages opened (preferrably in tr locale (e.g., for privacy reasons)).

Comment 1

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

This is probably because SUMO doesn't have chr as a valid locale.

We are trying to match the same locales as Firefox Desktop in bug 1521551.

Let me see how we can sync for locales that are in progress and not launched officially yet.

Comment 2

[Reşat SABIQ (Reshat)]

Here are some other links in which equivalent issues have been encountered (verified just now, using latest 66.0a1 build available).
3. Download Nightly: (probably tries) https://www.mozilla.org/crh/firefox/channel/desktop/#nightly
3.1. Lands on: https://www.mozilla.org/tr/crh/firefox/channel/desktop/#nightly
4. 1st link under Privacy & Security in preferences: https://support.mozilla.org/1/firefox/65.0a1/Linux/crh/tracking-protection
4.1. Lands on: https://support.mozilla.org/tr/crh/kb/what-happened-tracking-protection?as=u&utm_source=inproduct
5. What's New link under "A new Nightly update is available": https://www.mozilla.org/crh/firefox/nightly/notes/
5.1. Lands on: https://www.mozilla.org/tr/crh/firefox/nightly/notes/

THE GIST:
all 5 URLs (will) work if
instead of "tr/crh" just "tr"
is used (verified just now). My guess is this rule can be used for all pages as of now.

P.S. The only URL where "crh" probably needs to be used is the URL for downloading the actual update binaries. That said, I'm sure that URL is treated separately from the web-page URLs anyway.

Comment 3

[Francesco Lodolo [:flod]]

(In reply to Rubén Martín [:Nukeador] from comment #1)

Let me see how we can sync for locales that are in progress and not launched officially yet.

There are locales that will never complete SUMO localization. We should fall back to the first language available in their Acccept-Language (e.g. tr for crh), that's a better experience than a 404.

Comment 4

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

Thanks Flod, I'll see if we can implement that behavior.

Comment 6

[Martijn Dekker]

This is still not fixed 10 months after the original report? Come on, how hard can it be to implement a http regex redirect?

Firefox translations with no SUMO locales are not very attractive for novices this way. If issues like this are not given any priority, why am I bothering to volunteer my time translating?

Comment 7

[Emil Ghitta, QA [:emilghitta]]

The "crh" locale was removed per Bug 1573386 so I don't think that this issue is valid anymore.

Please feel free to re-open this ticket if I'm wrong.

Comment 8

[Francesco Lodolo [:flod]]

This is not crh, it affects any locale that ships in Firefox but is not localized in SUMO.

Comment 9

[Ryan Johnson (:rjohnson)]

As of the release of https://github.com/mozilla/kitsune/pull/5439 more than a week ago, SUMO either directly supports or gracefully falls back to a supported locale for all of the currently supported Firefox locales used within in-product links, so this should be resolved. See https://bugzilla.mozilla.org/show_bug.cgi?id=1733726 and https://github.com/mozilla/sumo/issues/1231 for further reference.

Francesco, do you know of any Firefox locale that SUMO doesn't currently gracefully handle within in-product links?

Comment 10

[Francesco Lodolo [:flod]]

(In reply to Ryan Johnson (:rjohnson) from comment #9)

Francesco, do you know of any Firefox locale that SUMO doesn't currently gracefully handle within in-product links?

AFAIK, there are cases where the locale is reported as und (bug 1537704), and these still seem to fail
https://support.allizom.org/und/products/firefox

The approach in https://github.com/mozilla/kitsune/pull/5439 might not be scalable. For example, we add new locales from time to time (e.g. tg in 113): is there automation warning SUMO when that happens?

Would it be possible to look at the accept-languages header instead, when the current mechanism fails? For example, fur and sc  would have it, without SUMO making a call on what locale they should fall back to (and some users might have a different preference).

Comment 11

[Ryan Johnson (:rjohnson)]

Thanks for your comment Francesco. By the way, I'm sorry for closing this as resolved. I meant to just add my comment, so I'll re-open this.

(In reply to Francesco Lodolo [:flod] from comment #10)

(In reply to Ryan Johnson (:rjohnson) from comment #9)

Francesco, do you know of any Firefox locale that SUMO doesn't currently gracefully handle within in-product links?

AFAIK, there are cases where the locale is reported as und (bug 1537704), and these still seem to fail
https://support.allizom.org/und/products/firefox

The approach in https://github.com/mozilla/kitsune/pull/5439 might not be scalable. For example, we add new locales from time to time (e.g. tg in 113): is there automation warning SUMO when that happens?

No, but we could add one, or perhaps if we generalize SUMO's locale fallback mechanism for in-product links we won't need to.

Would it be possible to look at the accept-languages header instead, when the current mechanism fails? For example, fur and sc  would have it, without SUMO making a call on what locale they should fall back to (and some users might have a different preference).

Good point. I think we (SUMO) should generalize the locale fallback mechanism for in-product links, because as you noted, what we've had for years now is too manual. Yes, we could fall back based on the Accept-Language header. I'll add an issue in our GitHub repo to track this. Thanks!