Page MenuHomeMiraheze

Universal Language Selector issues
Closed, InvalidPublic

Description

Hello, the Universal Language Selector has issues with language selection.

Wikis on Miraheze that I know experience this problem: Dragon Tamer wiki and Stardust Labs wiki.

*Note: both of those wikis use a JS script that adds Special:MyLanguage/ to most links before page names. This is done after a page has fully loaded. This is not interfering with the selector though, links could as well have this part added manually for the same effect. We turned off the script before as a test and used manually changed links, and the issues still remain. We didn't know any other wikis that use this extension to check, otherwise the above list would be longer.

Issues with the selector:

  • When selecting a language, the page properly reloads but the change is not applied, and the previous language still remains. This mostly happened when switching from a non-main language (English in both wiki examples) to another language. This issue fixes itself after reloading the page, but it's consistently appearing again after performing such a switch.
  • The language sometimes gets changed to the previous language without user input when visiting another page, or when visiting a translated page.
  • Selector has other similar issues that could have rules to them but they seem random for now. Both wikis have only up to a few translated pages currently, so testing wasn't possible.

I am not sure if the Translate extension could be involved, but both wikis are using it. It could possibly also be something with how the language is saved/cached rather than the selector itself.

Can something be done about it?

Event Timeline

RhinosF1 triaged this task as Normal priority.May 3 2022, 14:39
RhinosF1 edited projects, added Extensions; removed MediaWiki.

There's a lot to tell in this topic to be honest. I've actually observed so many issues with the USL extension and probably the translate extension too (I think the extension is involved to some extent), including but not limited to @Xena 's point 1.

There's a Translate configuration (can't remember the wgTranslate**** right now) that described that, setting it to true will make the Page language change to the language that's been selected from USL, but upon changing the language, everything remains the same, nothing changes.
Let me give an example, say, Page Miraheze is translated to the Catalan language, giving us page Miraheze/ca, now if you change your language from English to Catalan, and you have the wgTranslate*** set, you're supposed to be seeing page Miraheze/ca now, but that doesn't happen.

Unknown Object (User) added a comment.May 5 2022, 00:11

Unfortunately I'm not sure there is much we can do here, we may have to report the issues upstream. But I could be wrong, and it could be on our end also I guess.

Unknown Object (User) added a comment.EditedMay 5 2022, 20:04

Can you please try to enable (or disable if you already have it enabled) $wgTranslatePageTranslationULS in ManageWiki? (Special:ManageWiki/settings/translate#mw-section-localisation)

That's the exact config I was referring to above.

Can you please try to enable (or disable if you already have it enabled) $wgTranslatePageTranslationULS in ManageWiki? (Special:ManageWiki/settings/translate#mw-section-localisation)

It was on, so turned it off. Right now the issues don't look impacted in any way, the only change is the current page not adapting when changing the language, which that setting was for.

I'll leave it off for now, so if anyone wants to test, they can ^^

I did some wandering and language switching on MediaWiki (extension documentations), and they do not have any of those issues by the way.
EDIT: They're also using Translate along ULS.

Unknown Object (User) added a comment.May 6 2022, 16:00
In T9174#186174, @Xena wrote:

Can you please try to enable (or disable if you already have it enabled) $wgTranslatePageTranslationULS in ManageWiki? (Special:ManageWiki/settings/translate#mw-section-localisation)

It was on, so turned it off. Right now the issues don't look impacted in any way, the only change is the current page not adapting when changing the language, which that setting was for.

I'll leave it off for now, so if anyone wants to test, they can ^^

I did some wandering and language switching on MediaWiki (extension documentations), and they do not have any of those issues by the way.
EDIT: They're also using Translate along ULS.

So the issues are still there, that didn't help in any way? If that's the case, my recommendation is creating a task on phabricator.wikimedia.org. If the issue is indeed on our end, then they'd at the very least hopefully be able to provide some insight, as I'm not sure what more we can do here.

Unknown Object (User) moved this task from Backlog to Deployed Extension Bugs on the Extensions board.May 6 2022, 16:00
Unknown Object (User) moved this task from Backlog to Short Term on the MediaWiki (SRE) board.
In T9174#186174, @Xena wrote:

Can you please try to enable (or disable if you already have it enabled) $wgTranslatePageTranslationULS in ManageWiki? (Special:ManageWiki/settings/translate#mw-section-localisation)

It was on, so turned it off. Right now the issues don't look impacted in any way, the only change is the current page not adapting when changing the language, which that setting was for.

I'll leave it off for now, so if anyone wants to test, they can ^^

I did some wandering and language switching on MediaWiki (extension documentations), and they do not have any of those issues by the way.
EDIT: They're also using Translate along ULS.

So the issues are still there, that didn't help in any way? If that's the case, my recommendation is creating a task on phabricator.wikimedia.org. If the issue is indeed on our end, then they'd at the very least hopefully be able to provide some insight, as I'm not sure what more we can do here.

@Xena If we are reporting to upstream, they always want a step by step list to get to the error. Would you mind providing one?

Unknown Object (User) closed this task as Declined.May 12 2022, 20:48
Unknown Object (User) claimed this task.

No response in a few days, it can be re-opened with answering the above so we can report upstream, either that or you could report directly to upstream yourself if you want as well.

No response in a few days, it can be re-opened with answering the above so we can report upstream, either that or you could report directly to upstream yourself if you want as well.

Alright, sorry for the delay! While I was doing more detailed testing I noticed that $wgTranslatePageTranslationULS does indeed impact some things. More details below to reproduce some issues:


Language selection can fail with $wgTranslatePageTranslationULS on
  1. Open any page with English selected (for example, the main page of dragontamer wiki).
  2. Change the language through the Universal Language Selector to a different language (for example, French/français)

Result: In most cases, the language does not change from English.

  1. If it failed to change the language, refresh the page.

Result: In some cases, refreshing the page changes the language to the one chosen before that failed.

  1. If it still hasn't worked, select the language again.

Result: There is a chance selecting again will actually work.

  1. If it's still showing English, repeat points 3 and 4 until it successfully changes the language.

Note: This issue works in reverse as well, changing from a non-English language to English can fail similarly. It's also possible to happen regardless of languages changed but I mostly encountered it to/from English. Also, if the page has a translation in that language, it can still fail to load the translated page, even if the language changes properly.

This issue completely doesn't exist with $wgTranslatePageTranslationULS being turned off. My guess is that the refresh done by ULS to load the correct version of the page collides with the language changing process itself.


Language gets changed to an incorrect one with $wgTranslatePageTranslationULS on
  1. Change your language through the ULS. If needed, follow the steps in the first issue. (for example, English > français)
  2. Change the language through the ULS to a different language than the previous ones. (français > español)
  3. Change the language to the initial language. (español > English)

Result: The language can change to the incorrect language. It always happened to be the 2nd language (français in the example). A page refresh has always fixed that to the correct language in my testing.

Note: This can happen when selecting more languages in a row as well. I had French keep selecting itself instead of other languages 3 times in a row. As the first issue it's only happening when the $wgTranslatePageTranslationULS setting is turned on.


Language changes when leaving a page
  1. Change your language through the ULS. If needed, follow the steps in the first issue.
  2. Click on a link to a different page.

Result: The language can change back to the previous language.

  1. Go back to the previous page.

Result: In some cases, the language gets changed again, or if it didn't change previously, it can change now (both pages "remember" a different language).

Note: I've been reproducing it consistently on those two pages (1, 2, you can use either the top navigation or copy-paste urls to move between them. I also used safemode=1 and it still happened, so no JS or CSS is triggering this behavior). Without Special:MyLanguage links this issue seemed to happen even more consistently.

The Translate extension might be involved here: The Stardust Labs wiki doesn't use it anymore and I couldn't reproduce this issue on there.


Those are the issues I could find consistent behaviors for, but there can be more I couldn't pin down yet.


Also a note about dragontamer wiki specifically: We will be soon implementing a simplified language selector on that wiki (that is mostly a js-made copy of the user dropdown ULS selector with some CSS tweaks to it). However the original will be kept in the user dropdown if more testing/checking needs to be done there, and we will not modify it in any way.

Notes from the main post to send over upstream:
Wikis on Miraheze that I know experience this problem: Dragon Tamer wiki and Stardust Labs wiki.

  • dragontamer wiki has $wgTranslatePageTranslationULS turned off, stardustlabs wiki doesn't have this option because it doesn't use Translate anymore.
  • Both of those wikis use a JS script that adds Special:MyLanguage/ to most links before page names. This is done after a page has fully loaded. This is not interfering with the selector though, links could as well have this part added manually for the same effect. We turned off the script before as a test and used manually changed links, and the issues still remain.


Could you please send this upstream? You'll probably know how to do that better than me. Thank you! ^^

Unknown Object (User) reopened this task as Open.Jun 6 2022, 16:10
Unknown Object (User) removed Unknown Object (User) as the assignee of this task.

Reopening until it is reported upstream.

The task that was reported upstream was closed:
https://phabricator.wikimedia.org/T311053

Apparently, the issue is on Miraheze's side. Could this task here be reopened please?

Citing the last message of the upstream task for context:

When the issue happens, I see x-cache: cp21 HIT (4) or similar in the response. I think your Varnish is not configured correctly to split the cache.

I'm closing this task since there isn't evidence that this is a bug. No such issues has been reported from e.g. those Wikimedia sites where this option is enabled.

The upstream task contains a bit more information about the issue, as well as a video. Could someone confirm that this is indeed a problem with Varnish on Miraheze?

Unknown Object (User) added a comment.Sep 12 2022, 21:11

https://phabricator.wikimedia.org/T311053#8230574 if that does not lead to any solution then I will continue to investigate the Varnish angle, but I did try and could not find anything right now.

Unknown Object (User) closed this task as Invalid.Sep 12 2022, 22:11
Unknown Object (User) claimed this task.

Going to go ahead and close this as upstream again, but if they respond and what I mentioned there has nothing to do with it, this can be re-opened. Thanks!

Unknown Object (User) reopened this task as Open.Sep 24 2022, 20:26

Reopening, as a response from upstream made me realise this could've been a simple issue in our own MirahezeMagic, I have patched that, and will update MirahezeMagic shortly. If it doesn't work this task will be closed again, and I will reply upstream with that information. Thank you!

Unknown Object (User) added a comment.Sep 24 2022, 21:52

I updated MirahezeMagic. Please let me know if the issue still persists. Thanks!

Unknown Object (User) moved this task from Unsorted to Short Term on the Universal Omega board.Sep 24 2022, 22:31
Unknown Object (User) closed this task as Invalid.Sep 25 2022, 02:01

Seems it did not work, so I am going to try and respond to upstream, and look further into it.

To streamline complex tasks, integrating a tool like TG Macro can significantly enhance productivity and efficiency in project management.