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

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.

In T196314#4259558, @TBolliger wrote:

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.

@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.

In T196314#4264965, @kaldari wrote:

@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.

In T196314#4264965, @kaldari wrote:

@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.

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).

In T196314#4265223, @Amire80 wrote:

> 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.

In T196314#4265130, @Niharika wrote:

In T196314#4264965, @kaldari wrote:

@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?

In T196314#4308844, @MaxSem wrote:

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?

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.