1337562 - In-product links/links without locale in the URL aren't properly redirected to localised versions

Status: RESOLVED INVALID

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

Description

[[:philipp]]

after the migration links to support content without a locale denominator in the url (like we are commonly using in in-product urls) aren't properly redirecting.

one example is an error page like https://wrong.host.badssl.com/ - clicking on the "Learn More..." link there leads to https://support.mozilla.org/kb/what-does-your-connection-is-not-secure-mean which isn't properly resolving in a german build of firefox and ends up on the english homepage.

the same happens when pressing the ALT-key > Hilfe (help) > Tastenkombinationen (keyboard shortcuts) which links to https://support.mozilla.org/1/firefox/53.0a2/WINNT/de/keyboard-shortcuts and ends up on the homepage again.

Comment 1

[Giorgos Logiotatidis [:giorgos]]

I'd suggest that this a broader issue as described in bug 1324426

Comment 3

[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 4

[vesper]

(In reply to Bruce A. Johnson from comment #3)
> 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.

Hi Bruce,

We will have a component on the page that links directly to all available language versions of the viewed article. We had one in the pre-launch version of the platform, but there were issues with character encoding that needed to be addressed offline.

Comment 5

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

(In reply to vesper from comment #4)
> (In reply to Bruce A. Johnson from comment #3)
> > ....
> We will have a component on the page that links directly to all available
> language versions of the viewed article. We had one in the pre-launch
> version of the platform, but there were issues with character encoding that
> needed to be addressed offline.

This bug is marked Critical. Whiteboard as [1st2Weeks] and although a month old is not yet assigned to anyone.
So I am wondering who is it being assigned to ? 
and is this something Sumo or Lithium will need to deal with ?
Is the secondary subject of cross linking KB article with their Localised versions an inclusive part of this bug. Or does that need a separate bug filed for that work ? 

(It might also be noted the double square brackets used created links in Kitsune fora and kb articles that were language agnostic - like the links being discussed here -  and worked correctly in other locales. Also a contributor could merely replace the en-US locale  part of the actual link with the other locale to find an article and its specific link.)

Comment 8

[Amir Farsi]

I wanted to inform you when i clicked on learn more link under "send anonymous data usage) in Firefox Focus for Android, i redirected to a page with locale fa-IR which means Persian(Iran). In older version of sumo it was fa (Persian) only. Please be sure if you want to choose fa-IR or fa only. If you change languages codes, you should be sure they are same in links.

Note: I understood it, because first time when i touched that link, the browser couldn't load show error page of sumo. It shows the internal browser error page. It happens because sumo using SSL and in countries like Iran, SSL pages have lower speed. Sometimes SSL pages will not load in first time and user should reload the page.

Thanks.

Comment 9

[vesper]

+NI Madalina for handling & prioritization.

Comment 11

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

Madalina any comments on what is happening with this critical bug and who it is being assigned to ?

 &  from my comment #5
> .... and is this something Sumo or Lithium will need to deal with ?
> Is the secondary subject of cross linking KB article with their Localised
> versions an inclusive part of this bug. Or does that need a separate bug
> filed for that work ?

Comment 12

[madalina]

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

Comment 13

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

Might it be a good idea to update bugs when they are assigned to show who they are assigned to. This bug is still shown as unassigned.
Presumably if being worked on by Lithium and the Lithium person is not registered of bugzilla the Sumo contact could be assigned to the bug.

Comment 14

[madalina]

John, there's a quite a number of people working on fixing this. Lithium support folks are not registered on Bugzilla.

I'm happy to have this assigned to me if that helps.

Latest update: the short-term fix for the ~6500 links has been deployed to prod and tested. Around 1000 are still failing but they look like easy fixes. We are sending the data back to Lithium to get an ETA for these.