1324426 - Redirects should auto-detect language from Accept-Language

Status: RESOLVED INVALID

(support.mozilla.org - Lithium :: General, defect)

Description

[Giorgos Logiotatidis [:giorgos]]

For example 

 https://support.mozilla.org/kb/websites-look-wrong-or-appear-differently

redirects to

  https://support.mozilla.org/en-US/kb/websites-look-wrong-or-appear-differently

for a user with en-US in Accept-Languages  

but to

  https://support.mozilla.org/el/kb/websites-look-wrong-or-appear-differently

for a user with el-GR in Accept-Languages  


This redirect serves two things:

 1. Set the proper language in the UI
 2. For KB articles: fetch the proper, localized content if it exists.

I understand that (2) is out of scope for now. (1) needs to be fixed.

Comment 1

[scott.riley]

We need to understand how it should work differently on our platform.

The current/how the platform works:

Our redirects are only to direct users to the correct location of the content that has moved from one platform (URL) to another.  A users browser settings can dictate the language that the application appears, but not at the content level.

Content level is based on the community structure.  All French content lives in the French category, etc.

Each of those categories have a default setting in the Admin to display the application in that language (This is set up by the community team).

In addition to the node default language, there is also the user level default language they can select in their settings.  This has only to do with the application, the content itself assumes that all the French content is in the French category.  There is no additional redirecting to content.  The user has to either get there from Search or Google directly.

Per discussions w/Michal, we've built two custom components to assist users who want to navigate to other languages.  There is the nav at the top that lets users switch to the different categories.  There is also a component that lists all the other languages that the article is available in with direct links.

From the original bug that is reported, for #1 as described is not supported.  for #2 we have built that connection via the custom component and ID feature.  Would like Michal to weigh in as the most common use cases appear to be supported (landing from google and navigation within the app itself).

Comment 2

[vesper]

Thank you for all the details, Giorgos and Scott.

For the navigation within the community and the users finding content via their fave search engine, I think we won't need redirects, since we will either have the content in a language (searchable) or not. The custom components should make it easier for users to find content in their locale if they land on the English page.

For linking from within a localized article to a different localized article, we'll have to rely on contributors to make sure they link properly during localization, since Kitsune's [[double bracket syntax]], which used the English article title as a referrer to pull & include links to localized content will no longer available. This step/requirement will have to be included in the l10n documentation for contributors.

As an aside - Scott, could you just confirm that I remember/understand the below correctly:

"Each of those categories have a default setting in the Admin to display the application in that language (This is set up by the community team)."

This is the locale setting in "Users > Profile Defaults"?

"In addition to the node default language, there is also the user level default language they can select in their settings."

This is the setting in each user's profile that overrides the above, if necessary?

Comment 3

[Caspy7]

Just wanted to point out that this is probably breaking search result links from places like Google for this type of content.  So that could make it much more difficult for non-English users to find support from a web search.

Comment 4

[u277459]

The differences in URLs for the same KBs for different languages is also making it difficult for English speakers/readers/writers (like me), who are trying to help people who are using another language.  It is very difficult to determine what the proper link is for a KB in another locale when I don't understand the language.

In some forums/boards, some support requests don't get responded to unless someone uses Google Translate to try to help.

Comment 5

[Andrei Hajdukewycz [:sancus]]

Just in case it's unclear what's supposed to be happening, here are 4 curl attempts:

curl -IL https://support.mozilla.org/kb/new-thunderbird-45
HTTP/1.1 404 Not Found

curl -IL https://support.mozilla.org/kb/new-thunderbird-45 -H 'Accept-Language:
en-US'
HTTP/1.1 301 Moved Permanently
location: /t5/Install-Migrate-and-Update/New-in-Thunderbird-45-0/ta-p/38985
HTTP/1.1 200 OK

curl -IL https://support.mozilla.org/kb/new-thunderbird-45 -H 'Accept-Language:
es'
HTTP/1.1 301 Moved Permanently
HTTP/1.1 302 Found
Location:
https://support.mozilla.org/t5/Mozilla-Support-English/ct-p/Mozilla-EN

curl -IL https://support.mozilla.org/kb/new-thunderbird-45 -H 'Accept-Language:
es-ES'
HTTP/1.1 301 Moved Permanently
HTTP/1.1 302 Found
Location:
https://support.mozilla.org/t5/Mozilla-Support-English/ct-p/Mozilla-EN

This is actually horrible. If Accept-Language isn't set for some reason, we should rewrite to the en-US article. If Accept_Language: es is set, it should rewrite to the spanish article or, in the worst case, it should rewrite to the en-US article not to the generic support page which is completely useless!

Only the 2nd result out of 4 here is correct.

Comment 6

[Andrei Hajdukewycz [:sancus]]

This IS breaking Firefox and Thunderbird in-product links for every language other than English as we speak, also.

Comment 7

[alex_mayorga]

¡Hola!

Just a sample of what https://bugzilla.mozilla.org/show_bug.cgi?id=1324426#c6 describes.

In the es-MX version of Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170309030216 CSet: c40ca7a1bdd93632c6bdc5e23bd33d984d508b19 

In product URL: https://support.mozilla.org/1/firefox/55.0a1/WINNT/es-MX/prefs-security
In-product location: ? at the top right in about:preferences#security
Lithium URL: https://support.mozilla.org/t5/Administrar-preferencias-y/Configuraci%C3%B3n-de-seguridad-y-contrase%C3%B1as/ta-p/8705

¡Gracias!
Alex

Comment 8

[Pascal Chevrel:pascalc]

Note that IMO the severity of this bug should be higher than "normal", currently all in-product links in Firefox going to SUMO in our preferences for example lead to a 404 for the majority of our user base. This is for example the case for the warning about NPAPI deprecation in Firefox 52 which is a 404 from Firefox.

At the very least, until locale negociation is fixed (implemented?) in the new platform, localized urls should fall back to the English version of the articles instead of a 404 page.

Comment 10

[madalina]

Pascal, this is treated as critical by Lithium, just not marked as such in Bugzilla. I will change it now to make that clear if it helps.

Comment 11

[madalina]

Quick update to clarify what is going on:

Short-term solution: we’re manually creating a spreadsheet with all the in-product links in different locales that we’re going to send to Lithium. They will create a mapping for links that we have in the product so that the redirects arrive at the right pages and do not produce 404s. If there’s no localized page, they will redirect to English. Long-term we are looking at an automated solution with the help of the Lithium developers.

Comment 12

[John Hesling [:John99] (NeedInfo me)]

(In reply to madalina from comment #11)
> Quick update to clarify what is going on:
> 
> ... Long-term we are looking at
> an automated solution with the help of the Lithium developers.

Is the long term solution being dealt with from this bug or are one or more additional bugs being filed ?


(In reply to Giorgos Logiotatidis [:giorgos] from comment #0)
> For example 
>  https://support.mozilla.org/kb/websites-look-wrong-or-appear-differently
> redirects to
> https://support.mozilla.org/en-US/kb/websites-look-wrong-or-appear-
> differently
> for a user with en-US in Accept-Languages  
> but to
>   https://support.mozilla.org/el/kb/websites-look-wrong-or-appear-differently
> for a user with el-GR in Accept-Languages  
> 
> This redirect serves two things:
>  1. Set the proper language in the UI
>  2. For KB articles: fetch the proper, localized content if it exists.
> 
> I understand that (2) is out of scope for now. (1) needs to be fixed.

Is this still out of scope for this bug, If so does a suitable bug need filing for that.
If not does the bug title need modifying.

Note Madalina has posted in the contribs forum
"Redirect issue update"
> https://support.mozilla.org/t5/SUMO-community-discussions/Redirect-issue-update/m-p/1374199#U1374199

I also note we have Bug 1325046 but that is unassigned, and appears to have stalled despite having multiple open NI.  (Also does this bug1324426 still require NI reply from Scott or can that be cleared now?)

Comment 14

[Johann Hofmann [:johannh]]

Since this bug has fallen silent I just wanted to re-emphasize that all of our localized security SUMO articles are inaccessible from the browser. We have a lot less information on our certificate error pages than e.g. Chrome and rely on SUMO for that

Users are forced to google for our security errors if they are unable to use the SUMO home page (which is likely since they're redirected to the English one by default). This is extremely dangerous.

I'm really not enjoying waiting for a third-party to fix our security information links. 

Can you please give us an ETA on when the workaround will be in place?

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

This is serious enough to block the 53 release. We should be fixing it for Firefox 52 as well. It's a major regression which affects a wide range of Firefox users on every platform. We need our in-product alerts and links to work correctly.

Comment 16

[Dave Townsend [:mossop]]

Is this also the cause of bug 1347320?

Comment 17

[madalina]

Hi folks,

We’re currently working on the short-term solution: manually mapping all links for all locales in a spreadsheet then sending them to Lithium for implementation. There are around 1000 links identified so far so that takes time. We have no visibility on how many are affected so we have been prioritizing based on feedback received from the community and product teams.

This is where we are so far:
XP EOL - fixed
NPAPI - implemented currently being tested on stage
Firefox for iOS - mapped, waiting for implementation
Focus - mapped, waiting for implementation
Everything else - should be mapped by EOD tomorrow

All of these have been filed and tracked in Lithium's case management system: cases 00136770 and 00137108 (NPAPI plugins).

For transparency and internal tracking we're using Bugzilla and will be updating each time there's an update on the Lithium side.

Currently there are high-level discussions going on for a long term solution. As the SUMO team has no developer resources, hopefully we can connect some FF folks with the Lithium devs for a quicker fix.

Comment 18

[John Hesling [:John99] (NeedInfo me)]

(In reply to Dave Townsend [:mossop] from comment #16)
> Is this also the cause of bug 1347320?

As far as I am aware this is not the direct cause of the bug1347320 which I note has a url of:
> https://support.mozilla.org/t5/How-To/How-does-content-that-isn-t-secure-affect-my-safety/ta-p/27594 
and although that is a redirect it is a Lithium url but does NOT contain any locale. That bug already has a link added to Bug 1336374

Also note that if bug1347320 had been tried from some other locale you would have  run in to this bug1324426 .
Furthermore note there is a special case of this affecting in product links and covered by bug1337562  


NI Madalina
Thanks for the update, however I have asked previously should this bug be renamed and or additional bugzilla bugs be filed to make it easy to follow what is happening now and in the future. It appears some aspects of this bug  are considered critical others are long term goals or out of scope currently and I am wondering if it may be better to separate some of these out so individual bugs may be prioritised assigned and resolved. This bug is even blocking Firefox 53 (comment15) but assigned to Lithium yet some actions will apparently also be needed by uspcified Mozilla staff.
(In reply to madalina from comment #17)
> Hi folks,
> 
> We’re currently working on the short-term solution:    ....   
> Everything else - should be mapped by EOD tomorrow
> 
> All of these have been filed and tracked in Lithium's case management
> system: cases 00136770 and 00137108 (NPAPI plugins).
> 
> For transparency and internal tracking we're using Bugzilla and will be
> updating each time there's an update on the Lithium side.
> 
> Currently there are high-level discussions going on for a long term
> solution. As the SUMO team has no developer resources, hopefully we can
> connect some FF folks with the Lithium devs for a quicker fix.
This bug is still assigned to Scott, but even after the action described above I dont think the objective of this bug will be met. The bug title is still 
>Redirects should auto-detect language from Accept-Language
And I still see no clarification of the summary comment0 efectivly  saying localised content redirects are out of scope. 
>This redirect serves two things:
> 1. Set the proper language in the UI
> 2. For KB articles: fetch the proper, localized content if it exists.
>I understand that (2) is out of scope for now. (1) needs to be fixed.

Comment 19

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to John Hesling [:John99] (NeedInfo me) from comment #18)
> (In reply to Dave Townsend [:mossop] from comment #16)
> > Is this also the cause of bug 1347320?
> 
> As far as I am aware this is not the direct cause of the bug1347320 which I
> note has a url of:
> > https://support.mozilla.org/t5/How-To/How-does-content-that-isn-t-secure-affect-my-safety/ta-p/27594 
> and although that is a redirect it is a Lithium url but does NOT contain any
> locale. That bug already has a link added to Bug 1336374
> 
> Also note that if bug1347320 had been tried from some other locale you would
> have  run in to this bug1324426 .
> Furthermore note there is a special case of this affecting in product links
> and covered by bug1337562  
> 
> 
> NI Madalina
> Thanks for the update, however I have asked previously should this bug be
> renamed and or additional bugzilla bugs be filed to make it easy to follow
> what is happening now and in the future. It appears some aspects of this bug
> are considered critical others are long term goals or out of scope currently
> and I am wondering if it may be better to separate some of these out so
> individual bugs may be prioritised assigned and resolved. This bug is even
> blocking Firefox 53 (comment15) but assigned to Lithium yet some actions
> will apparently also be needed by uspcified Mozilla staff.
> (In reply to madalina from comment #17)
> > Hi folks,
> > 
> > We’re currently working on the short-term solution:    ....   
> > Everything else - should be mapped by EOD tomorrow
> > 
> > All of these have been filed and tracked in Lithium's case management
> > system: cases 00136770 and 00137108 (NPAPI plugins).
> > 
> > For transparency and internal tracking we're using Bugzilla and will be
> > updating each time there's an update on the Lithium side.
> > 
> > Currently there are high-level discussions going on for a long term
> > solution. As the SUMO team has no developer resources, hopefully we can
> > connect some FF folks with the Lithium devs for a quicker fix.
> This bug is still assigned to Scott, but even after the action described
> above I dont think the objective of this bug will be met. The bug title is
> still 
> >Redirects should auto-detect language from Accept-Language
> And I still see no clarification of the summary comment0 efectivly  saying
> localised content redirects are out of scope. 
> >This redirect serves two things:
> > 1. Set the proper language in the UI
> > 2. For KB articles: fetch the proper, localized content if it exists.
> >I understand that (2) is out of scope for now. (1) needs to be fixed.

Hi John: The entire SUMO team is working on the short term and long solution for redirects. We're meeting with Lithium on Monday and will file more bugs and or give an update next week. You now know as much as we do :-)

Cheers and happy weekend!

...Roland

Comment 20

[Alice Wyman]

(In reply to John Hesling [:John99] (NeedInfo me) from comment #18)

> NI Madalina
> Thanks for the update, however I have asked previously should this bug be
> renamed and or additional bugzilla bugs be filed to make it easy to follow
> what is happening now and in the future.

I started a SUMO discussion topic that links to a firefox-dev newsgroup thread with more information on what is happening, in case it helps:
https://support.mozilla.org/t5/SUMO-community-discussions/In-product-SUMO-links-broken-in-non-en-US-builds-bug-1324426/td-p/1382136

Comment 22

[John Hesling [:John99] (NeedInfo me)]

Good to see that it seems like rapid progress is now being made with this. Lets hope next we get rapid progress on some of the other migration issues including the showfor issues otherwise we will be in danger of linking to articles that may well be broken when displayed by some users.
For instance note also bug 1350856

Comment 23

[Masatoshi Kimura [:emk]]

I come from the duplicated bug 1350779 and read <https://mail.mozilla.org/pipermail/firefox-dev/2017-March/005245.html>.
But the spreadsheet does not contain <https://support.mozilla.org/kb/npapi-plugins>. It does not even contain the word "npapi".

Also <https://support-stage.allizom.org/kb/npapi-plugins> did not work.

The short term solution will not fix bug 1350779?

Comment 24

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to Masatoshi Kimura [:emk] from comment #23)
> I come from the duplicated bug 1350779 and read
> <https://mail.mozilla.org/pipermail/firefox-dev/2017-March/005245.html>.
> But the spreadsheet does not contain
> <https://support.mozilla.org/kb/npapi-plugins>. It does not even contain the
> word "npapi".
> 
> Also <https://support-stage.allizom.org/kb/npapi-plugins> did not work.
> 
> The short term solution will not fix bug 1350779?

npapi redirects are in bug 1350214

Sorry for the confusion :emk!

Cheers!
...Roland

Comment 25

[John Hesling [:John99] (NeedInfo me)]

Michał aka Vesper has posted an update in the contribs forum. That mentions a temporary rollback to Kitsune may still be on the table
Redirects update  
> https://support.mozilla.org/t5/SUMO-community-discussions/Redirects-update/m-p/1384527
... The Lithium developers and the Firefox team are working on resolving issue #1324426. If their collaboration does not provide a working solution in time for the next release of Firefox, we may be performing a temporary switch back to Kitsune. If this becomes necessary, the SUMO team will be working with the Firefox team on the Mozilla side on the temporary switch. ....

concluding with 

.... What can or should I do about this?
If you are asked about recent changes to http://support.mozilla.org/ or the issues with in-product redirects, please direct the person asking you about it to this page. [ https://support.mozilla.org/t5/SUMO-community-discussions/Redirects-update/m-p/1384527 ]
We have made a lot of progress on bug prioritization and feature planning that we are going to share with you next week. Stay tuned and thanks for all your hard work.

Comment 26

[Stefan Plewako [:stef]]

This also seems to break Firefox for iOS updated page.

Comment 27

[John Hesling [:John99] (NeedInfo me)]

Hi Stefan,
I wonder if you could provide further details of that please, so that we can determine whether it is this issue or something else.
For instance is the link to some Mozilla help article, or is it a link or problem relating to the itunes App Store.

What is the link you are trying to use, and where is it that you see this link ?
Do you know what any working link 0r page is ?
For instance I see the page for iOS Firefox 7 as  
> https://itunes.apple.com/app/id989804926

Comment 28

[Stefan Plewako [:stef]]

(In reply to John Hesling [:John99] (NeedInfo me) from comment #27)
> Hi Stefan,
> I wonder if you could provide further details of that please, so that we can
> determine whether it is this issue or something else.
> For instance is the link to some Mozilla help article, or is it a link or
> problem relating to the itunes App Store.

It is about the page that is opened in a tab in Firefox for iOS after the app was updated (to version 7.0) and it ends as https://support.mozilla.org/t5/Mozilla-Support-English/ct-p/Mozilla-EN?mobile=1&minimal=1

Comment 29

[John Hesling [:John99] (NeedInfo me)]

Attachment: fyi-slowness

Thanks Stefan


As a general update work is being carried out on this issue.
See now thread posted yesterday 
> FYI: Slowness of support.mozilla.org over the last few days
> https://support.mozilla.org/t5/SUMO-community-discussions/FYI-Slowness-of-support-mozilla-org-over-the-last-few-days/m-p/1386416#U1386416
The support site continues to suffer slowness and broken features, as a result of ongoing testing. I will add the full content of the first post as an attachment for the benefit of anyone who is unable to use the site.

Comment 30

[Richard Newman [:rnewman]]

(In reply to John Hesling [:John99] (NeedInfo me) from comment #27)
> Hi Stefan,
> I wonder if you could provide further details of that please, so that we can
> determine whether it is this issue or something else.

Firefox for iOS opens a link to SUMO on upgrade.

The link looks like

  https://support.mozilla.org/1/mobile/\(appVersion)/iOS/\(langID)/new-ios

e.g.,

  https://support.mozilla.org/1/mobile/7.0/iOS/fr/new-ios

That link is programmatically handled, and redirects to an appropriate page with custom framing to display correctly on mobile devices (e.g., no breadcrumb trail) -- minimal=1, something like

  https://support.mozilla.org/en-US/kb/whats-new-firefox-ios-60?mobile=1&redirectlocale=en-US&redirectslug=whats-new-firefox-ios&minimal=1

See Bug 1240832 or ask Joni for more context.

As this link opens automatically for every user after upgrade, it's *really important* that it not make us look foolish.

Comment 32

[madalina]

Lithium to deploy short term fix today to prod. QA to manually test once this is done.

Comment 33

[Erin Lancaster [:elan]]

Quick status: 797 URLs of 6000 are still broken but the redirect is on production and is working for the rest. A request as been placed with Lithium to have 797 fixed by tomorrow. We have people lined up to test corrected redirects once they are deployed. Contingency plan to roll-back is still on the table if this problem isn't resolved for our users by end of day tomorrow (PST).

Comment 34

[Andrei Hajdukewycz [:sancus]]

I'm assuming the "short term fix" is a list of all the existing necessary rewrites and each correct URL.

What about new pages?

Comment 35

[Erin Lancaster [:elan]]

(In reply to Andrei Hajdukewycz [:sancus] from comment #34)
> I'm assuming the "short term fix" is a list of all the existing necessary
> rewrites and each correct URL.
> 
> What about new pages?

I asked about this today. As I understand it, we have to get redirects setup before a new link goes live. We need the permanent fix before new pages will work without a re-direct. An ETA for the permanent fix should be available as soon as 24 hours from now. It sounds like getting exact steps for adding new links and getting redirects set-up in the interim would be helpful.

Comment 36

[Patrick McClard;pmcclard]

> It sounds like getting exact steps for adding new links and getting redirects set-up in the interim would be helpful.

Joni can provide this tomorrow.

Comment 37

[madalina]

Joni is out today, we will have an update on steps for adding new links on Monday.

Comment 38

[FO-nTTaX]

https://support.mozilla.org/1/firefox/55.0a1/WINNT/en-US/unsigned-addons this "More Information" link on the addons page when installing an unsigned addon in nightly ultimately leads to https://support.mozilla.org/t5/Mozilla-Support-English/ct-p/Mozilla-EN which is not helpful for more information. Screenshot can be found here: https://twitter.com/FO_nTTaX/status/851796315000504322

Comment 39

[alex_mayorga]

¡Hola Madalina!

FWIW https://support.mozilla.org/1/firefox/55.0a1/WINNT/en-US/unsigned-addons should go to https://support.mozilla.org/t5/Problems-with-add-ons-plugins-or/Add-on-signing-in-Firefox/ta-p/30262 IMHO unless somebody has a better link.

¡Gracias!
Alex

Comment 40

[Joni Chan]

Hi, all.

The interim process for new in-product links is:

1) Email request to Joni. The email should say:
a. What the in-product link should be, or we can decide that for you: support.mozilla.org/kb/_______/[locale]
b. To which locales will this new article be visible?

2) SUMO will submit a spreadsheet to Lithium mapping out each link (English and all the localized versions) to the Lithium equivalent.
*If a localized article isn't ready, that link will redirect to the English version.

Comment 41

[Joni Chan]

Correction to comment #40, item 1a. The localized URL format is actually support.mozilla.org/kb/_______-[locale]

If it's an anchor link (not common), it's support.mozilla.org/kb/________-[locale]#[anchorname]

Comment 42

[John Hesling [:John99] (NeedInfo me)]

ROLLBACK TO KITSUNE TODAY

( Further to my comment #25)
> Michał aka Vesper has posted an update in the contribs forum. That mentions
> a temporary rollback to Kitsune may still be on the table
> ....

I understand posting new questions on Lithium is already turned of and a temporary rollback to Kitsune will occur at 7am Today pacific time.

See https://support.mozilla.org/t5/SUMO-community-discussions/Important-Announcement-Temporary-Rollback-to-Kitsune-Tomorrow/td-p/1392543

Comment 45

[Chris Black]

(In reply to Giorgos Logiotatidis [:giorgos] from comment #0)
> For example 
> 
>  https://support.mozilla.org/kb/websites-look-wrong-or-appear-differently
> 
> redirects to
> 
>  
> https://support.mozilla.org/en-US/kb/websites-look-wrong-or-appear-
> differently
> 
> for a user with en-US in Accept-Languages  
> 
> but to
> 
>   https://support.mozilla.org/el/kb/websites-look-wrong-or-appear-differently
> 
> for a user with el-GR in Accept-Languages  
> 
> 
> This redirect serves two things:
> 
>  1. Set the proper language in the UI
>  2. For KB articles: fetch the proper, localized content if it exists.
> 
> I understand that (2) is out of scope for now. (1) needs to be fixed.

Giorgos, (1) should be fixed now. You were right, there was an issue with Accept-Language logic but it was at the apache level. There was a block that if the path to the article started with /kb/, thus no explicit language, it would add the language prefix by using the Accept-Language header like /{Accept-Language}/kb/. We changed it so that if language is missing it will always redirect to the English article at the apache level. Allowing the other Accept-Language logic to take over and redirect to the appropriate language version of the article.

Comment 46

[Ben (:bensternthal)]

Chris:

Can you verify if this is ready for testing and if so confirm the url I should use?

Comment 47

[Chris Black]

Ben,
Yes this is ready for testing. You can use http://migration26.stage.lithium.com/ with any prod path. All urls in prod should be available on migration26. For example http://migration26.stage.lithium.com/kb/websites-look-wrong-or-appear-differently should redirect to the appropriate article depending on the value of Accept-Language

Comment 48

[Ben (:bensternthal)]

OK I will start testing and post results here. One question, how up to date is the content on migration26?

Comment 49

[Ben (:bensternthal)]

Chris:

I started testing and I am finding a few things to check before I go forth and test all these urls. Below is an example problem I am running into.

# Test URL: 

Kitsune: https://support.mozilla.org/kb/get-started-firefox-overview-main-features
Lithium: http://migration26.stage.lithium.com/kb/get-started-firefox-overview-main-features

# Expected Behavior
German page loads when de is supplied as accept language.

Kitsune: https://support.mozilla.org/de/kb/erste-schritte-mit-firefox
Lithium: http://migration26.stage.lithium.com/t5/Lernen-Sie-die-Grundlagen-Erste/Erste-Schritte-mit-Firefox-%C3%9Cberblick-%C3%BCber-die-wichtigsten/ta-p/5843


# Results

*All are with de supplied as accept language* 

If /de/ appears in url you are redirected to http://migration26.stage.lithium.com/
If /de/ is absent in url you are redirected to http://migration26.stage.lithium.com/en-US/kb/get-started-firefox-overview-main-features

# Steps to reproduce

curl -H "Accept-Language: de" -u mozilla:{password} -I http://migration26.stage.lithium.com/de/kb/get-started-firefox-overview-main-features

curl -H "Accept-Language: de" -u mozilla:{password} -I http://migration26.stage.lithium.com/kb/get-started-firefox-overview-main-features

Comment 50

[Ben (:bensternthal)]

Chris, pinging on the above. I can not proceed with testing until we can sort out the previous comment.

Comment 51

[Alice Wyman]

(In reply to Ben (:bensternthal) from comment #49)
> # Test URL: 
> 
> Kitsune:
> https://support.mozilla.org/kb/get-started-firefox-overview-main-features
> Lithium:
> http://migration26.stage.lithium.com/kb/get-started-firefox-overview-main-features

See bug 1370422 comment 1. The Lithium version of the "Get started with Firefox - An overview of the main features" article used to be here on the production site:
https://hwsfp35778.lithium.com/t5/Basic-Browsing/Get-started-with-Firefox-An-overview-of-the-main-features/ta-p/3994
This is one of the Lithium articles that was mysteriously deleted.

Comment 52

[Stefan Plewako [:stef]]

Ben: why invalid?

Comment 53

[Francesco Lodolo [:flod]]

https://blog.mozilla.org/sumo/2017/06/28/important-platform-update/

Sounds more like a WONTFIX than INVALID, but that's a detail.

> We would like to inform you that a decision has been made on Mozilla’s 
> side to keep using Kitsune for the foreseeable future. Our team will 
> investigate alternative options to improve and update Mozilla’s support 
> for our users and ways to empower your contributions in that area.

Comment 54

[Ben (:bensternthal)]

I set most of the lithium bugs to invalid, as we are not moving forward with their platform. WontFix to me means the bug still exists but for one reason or another.. we decided not to fix it. In this context Invalid "felt" more accurate.