Page MenuHomePhabricator

Unexpected "Page contents not supported in other languages" in non-article namespace
Closed, ResolvedPublic

Description

Screenshot - 12_1_2023 , 17_25_19.jpg (565×1 px, 84 KB)

rhymes page Mon Wiktionary and English Wiktionary page I have encountered an error that I don't understand to connect the Wikidata link, See the Rhymes:English/aɪə(ɹ) page.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Func renamed this task from "Page contents not supported in other languages" in language dropdown on English Wiktionary to Unexpected "Page contents not supported in other languages" in non-article namespace.Jan 13 2023, 6:24 AM

Change 879670 had a related patch set uploaded (by Func; author: Func):

[mediawiki/skins/Vector@master] LanguageDropdown:

https://gerrit.wikimedia.org/r/879670

Change 879670 merged by jenkins-bot:

[mediawiki/skins/Vector@master] LanguageDropdown: Check if the page is in talk namespaces instead

https://gerrit.wikimedia.org/r/879670

This should be backported as soon as possible since wikis like French Wikipedia currently don’t have language switching at their main pages:
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal
Tagging @Jdlrobson to make sure that happens.

Jdlrobson added a subscriber: santhosh.

Tagging @santhosh and language team as I'm not too familiar with the work they are doing here.

It seems that, although the merged change fixes the issue somewhat, the code in question should be rewritten to check if there are any interwiki data for the page, as opposed to just making assumptions about what page can link to other languages and what page cannot. Judging by how interwiki links act when on talk pages (example in ruWP, usually [[en: type link creates an interwiki link, but that doesn’t happen on a talk page), that kind of limitation might already exist somewhere and maybe can be referenced as a more reliable way to know what pages are allowed to have interwiki links.

This should be backported as soon as possible since wikis like French Wikipedia currently don’t have language switching at their main pages:
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal

There are no backport windows recently, otherwise, I would have added this patch to the calendar.
Is next Tuesday soon enough? I will be around if no one claim to be there during deployment.

This might qualify for emergency deployment tbh. Main pages are extremely visible parts of Wikimedia projects, and a number of them are in a non-content namespace [1] and don’t have interwiki links right now if new Vector is the default skin. But if it doesn’t, then Tuesday is fine, I suppose.

[1]: https://www.wikidata.org/wiki/Q5296 for the list of all main pages, from what I can spot, French, Esperanto, Javanese, Portuguese Wikipedias currently have it broken

Just to show the extent of the bug, as reported here on fawikipedia, all non-article namespaces on English and Persian (Farsi) Wikipedia have their language links missing and "Page contents not supported in other languages" is shown in place of the list of language links (for example, w:en:Template:Deep fried foods which has a corresponding template in fawikipedia and the link can be seen using vector legacy skin).

The same problem applies to namespaces except "main" on Wikisources (i.e. Help).
When the "vector 2022" skin is used, the message "Page contents not supported in other languages." appears instead of links:
see:
https://en.wikisource.org/wiki/Help:Contents?useskin=vector
vs
https://en.wikisource.org/wiki/Help:Contents?useskin=vector-2022
or
https://pl.wikisource.org/wiki/Pomoc:Spis_tre%C5%9Bci?useskin=vector
vs
https://pl.wikisource.org/wiki/Pomoc:Spis_tre%C5%9Bci?useskin=vector-2022

image.png (434×1 px, 60 KB)

vs
image.png (391×1 px, 56 KB)

This is especially annoying on the wiki, where vector 2022 is the default already (ie. pl ws).

Interestingly, in "vector-2022" the Sticky header shows the actual number of links, but... no links, and the message is: "No languages yet. No languages are available for now":

iwlinks.gif (610×1 px, 2 MB)

see: https://en.wikisource.org/wiki/Wikisource:Scriptorium?useskin=vector-2022

This is also discussed in T316559.

Yes, the issue that caused this is already fixed on the side of the code, you don’t need to document it further. What we need now is to deploy the patch ASAP.

Change 879798 had a related patch set uploaded (by Func; author: Func):

[mediawiki/skins/Vector@wmf/1.40.0-wmf.18] LanguageDropdown: Check if the page is in talk namespaces instead

https://gerrit.wikimedia.org/r/879798

RhinosF1 triaged this task as Unbreak Now! priority.Jan 15 2023, 1:31 PM
RhinosF1 subscribed.

Hi,

Can someone from SRE or releng please look to facilitate an emergency deploy?

MustafaMVC reopened this task as In Progress.
MustafaMVC claimed this task.
MustafaMVC subscribed.

I don't know what I just unintentionally did. The problem is also present in Turkish Wikipedia.

Hi,

Can someone from SRE or releng please look to facilitate an emergency deploy?

I am close by my computer for a bit if there's someone who can help me verify the fix.

I'm around in my capacity as SRE. Going to help on this.

Change 879798 merged by jenkins-bot:

[mediawiki/skins/Vector@wmf/1.40.0-wmf.18] LanguageDropdown: Check if the page is in talk namespaces instead

https://gerrit.wikimedia.org/r/879798

Mentioned in SAL (#wikimedia-operations) [2023-01-16T01:05:09Z] <thcipriani@deploy1002> Started scap: Backport for [[gerrit:879798|LanguageDropdown: Check if the page is in talk namespaces instead (T316559 T326788)]]

Mentioned in SAL (#wikimedia-operations) [2023-01-16T01:15:17Z] <thcipriani@deploy1002> thcipriani and func: Backport for [[gerrit:879798|LanguageDropdown: Check if the page is in talk namespaces instead (T316559 T326788)]] synced to the testservers: mwdebug1001.eqiad.wmnet, mwdebug2001.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet

I'd appreciate an incident report on this: https://wikitech.wikimedia.org/wiki/Incident_status Why it passed the tests and QA, why it reached production, why the fix took too long to be deployed, and so on.

Mentioned in SAL (#wikimedia-operations) [2023-01-16T01:29:57Z] <thcipriani@deploy1002> Finished scap: Backport for [[gerrit:879798|LanguageDropdown: Check if the page is in talk namespaces instead (T316559 T326788)]] (duration: 24m 47s)

Func lowered the priority of this task from Unbreak Now! to High.Jan 16 2023, 2:05 AM

Lower the priority since backported.

Func changed the task status from In Progress to Open.Jan 16 2023, 2:06 AM

The deployment went way bumpier than anticipated. I assume a portion of codfw mw nodes didn't get the php-fpm reboot and might still be shown in small subset of users. In a couple of hours, the Europe wakes up and we can take a look.

More context: T327041

Change 880423 had a related patch set uploaded (by Nik Gkountas; author: Nik Gkountas):

[mediawiki/extensions/UniversalLanguageSelector@master] ULS: Display "Page contents not supported" body in missing and talk pages

https://gerrit.wikimedia.org/r/880423

Change 880423 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] ULS: Display "Page contents not supported" body in missing and talk pages

https://gerrit.wikimedia.org/r/880423

The issue described seems no longer to be present. Sharing some examples similar to the one from the ticket description:

Pages available in other languages (example) show them in the list
en.wiktionary.org_wiki_Rhymes_English_a%C9%AA%C9%99(%C9%B9)(iPad Air).png (1×2 px, 393 KB)
Pages available in only the current language (example) show options to add more (option to edit links pending for T310259 to be completed)
en.wiktionary.org_wiki_Rhymes_English_e%C9%AAt%C9%99(%C9%B9)(iPad Air).png (1×2 px, 435 KB)
Pages that do not exist yet (example) show less prominent entry point with message indicating that is not possible to connect this kind of page
en.wiktionary.org_wiki_Rhymes_English_invented(iPad Air).png (1×2 px, 439 KB)

If there is some case that is not properly supported, feel free to report and reopen the ticket.