When changing the language with ULS on an article page, the page refreshes and takes you to the language you previously had set in your global preferences.
ULS behaves as expected on system pages, as demonstrated here:
Description
Description
Event Timeline
Comment Actions
Just wondering if anyone had a second to look at this, one of our community proposed to remove i18n altogether because our non-english-speaking users are struggling
Comment Actions
Hi,
I looked into this (on my own machine but by reproduce the same scenario) and I came to one conclusion: $wgTranslatePageTranslationULS is the imposter.
When a I tried to change the language on (probally) any translatable page, they call /w/index.php?title=Special:MyLanguage/<your_page>&setlang=<language_code> when the config variable is true.
But for a unknown reason, there don't fetch setlang and there ignore it for return on the actual language page without changing the interface lang.
Making the config variable to false resolve the problem because there remove Special:Mylanguage.
This is probally a bug, but if someone else can review it for have a second look (and for found or create a upstream ticket because I don't find one and I am not sure this is intended).
Comment Actions
I concur.
This is probally a bug, but if someone else can review it for have a second look (and for found or create a upstream ticket because I don't find one and I am not sure this is intended).
It does seem like a bug, I presume it is because Translate when $wgTranslatePageTranslationULS is true, it overwrites the function that does the change.
This should be reported upstream to Wikimedia's Phabricator to resolve, the temporary solution would be to disable the PageTranslationULS feature.