Page MenuHomePhabricator

UniversalLanguageSelector doesn't work if language is set globally in global preferences
Open, HighPublic

Description

Problem

The Universal Language Selector ('ULS') is used as a shortcut to allow users to quickly set language preferences without visiting Special:Preferences.

Currently on production, if a user has set their global preference of interface language and has not enabled a local override the ULS will not successfully set a local override and will therefore fail to display the newly selected language.

The ULS:


Steps to reproduce
  1. go to https://meta.wikimedia.org/wiki/Special:GlobalPreferences
  2. set language globally and save
  3. go to wiki and try to change your language through UniversalLanguageSelector

Result: page get loaded but language is not changed.


Expected behavior
  • Changing the language preference in the ULS should enable a local override for that wiki, if the interface language preference is set globally.

Event Timeline

Stryn created this task.Jun 3 2018, 4:43 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 3 2018, 4:43 PM
Nikerabbit triaged this task as High priority.Jun 3 2018, 5:01 PM
Nikerabbit added a subscriber: Nikerabbit.

Can the Global Preferences devs clarify why this is happening? I would expect existing code changing preferences would keep working.

Restricted Application added a project: Community-Tech. · View Herald TranscriptJun 3 2018, 5:01 PM
Legoktm added a subscriber: Legoktm.Jun 3 2018, 6:34 PM

ULS is sending an API request to change the local wiki preference, which succeeds. But the global preference will still mask the local preference.

TBolliger updated the task description. (Show Details)Jun 4 2018, 9:58 PM
Arrbee added a subscriber: Arrbee.Jun 5 2018, 5:31 PM
TBolliger added subscribers: pau, TBolliger.

This is a problem that should be fixed in the ULS itself. Pinging @pau and the language team. We expect this to be used less frequently, as the global preference for language should lower usage of the ULS, correct?

There is currently no way to write via API to Global Preferences (T62856 will build this, but it is not prioritized) nor is there a way to see if the user is using Global Preferences at all.

Restricted Application added a subscriber: Pginer-WMF. · View Herald TranscriptJun 5 2018, 11:31 PM
Arrbee added a subscriber: Amire80.Jun 6 2018, 6:47 AM

This is a problem that should be fixed in the ULS itself. Pinging @pau and the language team.
...
There is currently no way to write via API to Global Preferences (T62856 will build this, but it is not prioritized) nor is there a way to see if the user is using Global Preferences at all.

As a short term solution, until T62856 is supported, we considered to show a descriptive message to indicate the current language set by the global preference and provide a link to the place where users can enable a local exception. Something along the lines of what we do for logged-out users:

However, since the lack of a "way to see if the user is using Global Preferences" is also preventing this kind of solution. Are there plans in the short term to have visibility on this?

Without these tools is not clear which options we have left to solve this from the ULS side. We can coordinate to explore possible options.

We expect this to be used less frequently, as the global preference for language should lower usage of the ULS, correct?

Global preferences will help for some usecases. I expect that those users defining a global language to be happy with it for most of the wikis, but they may need for local overrides. For example a user speaking 3 languages (English, French and German) may use English by default except for French and German Wikipedias where the local language will be used. ULS may be the closest entry point to set the language next to the content itself, and not working without further notice would be problematic.

kaldari added subscribers: MaxSem, kaldari.EditedJun 7 2018, 5:24 PM

@TBolliger: I think we're going to have to bite the bullet and build an API method to read global preferences (sooner rather than later). My suggestion would be to split T62856 into two subtasks: One API module for setting global preferences and one API module for reading global preferences. I would consider the reading module a blocker for deployment to the Wikipedias (as otherwise ULS and other tools are not going to be able to fix their issues). We could have @MaxSem go ahead on work on that if we want to put it into the current sprint.

@TBolliger: I think we're going to have to bite the bullet and build an API method to read global preferences (sooner rather than later). My suggestion would be to split T62856 into two subtasks: One API module for setting global preferences and one API module for reading global preferences. I would consider the reading module a blocker for deployment to the Wikipedias (as otherwise ULS and other tools are not going to be able to fix their issues).

API module for setting global preference or local preference? Or both? I think local preference makes more sense. Global preferences are more powerful and apps/scripts should not be allowed to change those without explicit permission from the user.

We could have @MaxSem go ahead on work on that if we want to put it into the current sprint.

I'll go ahead and create the tickets and estimate them in the next kick-off. I would have Max work on the already estimated tasks before these.

@TBolliger: I think we're going to have to bite the bullet and build an API method to read global preferences (sooner rather than later).

Thanks. It probably makes sense not just for this preference, but for more.

A couple of comments about this particular preference:

  1. ULS is one way to set this preference. Special:Preferences is another. The global version of Special:Preferences has a UI to make it global or local, but ULS doesn't have it. What is the right thing to do in ULS: to set it globally or to set it locally? I can imagine users that may want both things, and I cannot think of a default that is right for everyone. It makes sense to me to ask the user whether they want to make it local or global in ULS itself. Google's language preference on desktop do something similar: for example, if you change the language to German in Google Docs, you'll be asked whether you want to use all Google apps in German.
  2. This preference is special because its default is different in every wiki. The default is currently the content language of the wiki. I suspect that at some point, possibly soon, it may have to be changed, in core MediaWiki, to something more explicit, so that my explicit global default will be "The content language of the wiki", and I'll be able to change it locally.
kaldari added a comment.EditedJun 7 2018, 7:32 PM

ULS is one way to set this preference. Special:Preferences is another. The global version of Special:Preferences has a UI to make it global or local, but ULS doesn't have it. What is the right thing to do in ULS: to set it globally or to set it locally? I can imagine users that may want both things, and I cannot think of a default that is right for everyone. It makes sense to me to ask the user whether they want to make it local or global in ULS itself. Google's language preference on desktop do something similar: for example, if you change the language to German in Google Docs, you'll be asked whether you want to use all Google apps in German.

I think there are 2 solutions for this. A short-term solution and a long-term solution. The short-term solution should check to see if the language is set globally (once we have the read API in place) and if so either disable ULS or show a message letting the user know that it is set globally and thus they can't use ULS. The long-term solution would be to have ULS ask the user what they really want to do and set the global preferences or local overrides as appropriate (once we have the write APIs in place).

> What is the right thing to do in ULS: to set it globally or to set it locally? I can imagine users that may want both things, and I cannot think of a default that is right for everyone.

I think it makes more sense for the ULS to change the language locally by default, it seems to cause less problems when the assumption is wrong than the other way around. For those users who have already a global preference set, we can show a message telling that the change only affects the current wiki, and that they can adjust the global preferences to make the effects of the change broader (this could be a link to Global Preferences or a one click action). But I would only show that option after making a choice not surfacing too many options from the beginning which may just add complexity that is not needed in most cases.

Agree with Pau.

@TBolliger: I think we're going to have to bite the bullet and build an API method to read global preferences (sooner rather than later). My suggestion would be to split T62856 into two subtasks: One API module for setting global preferences and one API module for reading global preferences. I would consider the reading module a blocker for deployment to the Wikipedias (as otherwise ULS and other tools are not going to be able to fix their issues).

API module for setting global preference or local preference? Or both? I think local preference makes more sense. Global preferences are more powerful and apps/scripts should not be allowed to change those without explicit permission from the user.

OK, sounds good. Thank you @Niharika.

I defer to the language team about the behavior of the ULS.

We could have @MaxSem go ahead on work on that if we want to put it into the current sprint.

I'll go ahead and create the tickets and estimate them in the next kick-off. I would have Max work on the already estimated tasks before these.

I'm currently working on API for GlobalPreferences, however there are lots of higher level questions:

  • Is every extension modifying preferences supposed to know about GlobalPreferences?
  • In UI, we make modifying globally overridden preferences impossible - should the normal core action=options API follow the suit and return an error if something attempts to modify these?

I'm currently working on API for GlobalPreferences, however there are lots of higher level questions:

  • Is every extension modifying preferences supposed to know about GlobalPreferences?

Can you elaborate on this? What do you mean by "supposed to know"?

  • In UI, we make modifying globally overridden preferences impossible - should the normal core action=options API follow the suit and return an error if something attempts to modify these?

Yes, good point. I think giving an error and letting them know they can set a local override for the global preference might be the way to go. @kaldari thoughts on this?

Vvjjkkii renamed this task from UniversalLanguageSelector doesn't work if language is set globally in global preferences to 5pbaaaaaaa.Jul 1 2018, 1:06 AM
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from 5pbaaaaaaa to UniversalLanguageSelector doesn't work if language is set globally in global preferences.Jul 2 2018, 9:42 AM
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.

GlobalPreferences APIs are documented here https://www.mediawiki.org/wiki/Extension:GlobalPreferences/API

ULS should now be able to use these APIs to set the preference as local (or global?) as required.

Nikki added a subscriber: Nikki.Jul 26 2018, 11:59 AM