Support global preferences
Open, NormalPublic

Subscribers
Tokens
"Like" token, awarded by Elitre."Like" token, awarded by Liuxinyu970226."Like" token, awarded by Amire80."Love" token, awarded by santhosh."Love" token, awarded by TerraCodes."Like" token, awarded by Cosine02."Like" token, awarded by matej_suchanek."Love" token, awarded by MarcoAurelio."Love" token, awarded by Dalba."Love" token, awarded by Pathoschild."Love" token, awarded by MGChecker."Like" token, awarded by Morten_Haan."Love" token, awarded by Luke081515."Love" token, awarded by Ltrlg."Love" token, awarded by Neil_P._Quinn_WMF."Like" token, awarded by Kozuch."Like" token, awarded by Nemo_bis."Love" token, awarded by He7d3r.
Assigned To
None
Authored By
bzimport, Jul 27 2008

Description

It would be nice if users and developers could designate certain preferences to automatically apply across all wikis. This will require A Lot of Work™.

Extension:GlobalPreferences is a rough draft of the functionality.

RFC: Global user preferences

There are a very large number of changes, so older changes are hidden. Show Older Changes
  • Bug 19161 has been marked as a duplicate of this bug. ***
  • Bug 19161 has been marked as a duplicate of this bug. ***

jeremias.np wrote:

what's the status on this? is anyone currently working on it?

heard from Andrew Garrett that it was reverted because there was no reasonable UI for it (http://www.mediawiki.org/wiki/Special:Code/MediaWiki/49932)

i'd be interested in taking this up as a project for GSoC (http://lists.wikimedia.org/pipermail/wikitech-l/2012-February/058141.html)

thanks

sumanah wrote:

Hi, Jeremias! No, I think no one is working on it - please come into IRC with us and chat about it. Thanks!

I've done some work on this, see [[mw:Extension:GlobalPreferences]]. It's not even close to deployment-ready yet and needs UI love.

(In reply to Kunal Mehta (Legoktm) from comment #22)

I've done some work on this, see [[mw:Extension:GlobalPreferences]]. It's
not even close to deployment-ready yet and needs UI love.

legoktm: Now I'm tempted to assign this ticket to you. ;) Out of curiosity, are there long term plans to try getting GlobalPrefs deployed on Wikimedia sites?

In the long term, yes. I don't plan on working on the extension anytime soon though, so assigning the bug to me would probably just end up being cookie licking.

He7d3r rescinded a token.
He7d3r awarded a token.
werdna removed a subscriber: werdna.Dec 10 2014, 5:14 PM
Nemo_bis set Security to None.

This task was mentioned in https://www.mediawiki.org/w/index.php?title=Outreach_programs/Possible_projects&oldid=1404823#Very_raw_projects as a possible candidate for Google Summer of Code or similar programs. Do you think it is a good candidate?

Qgil added a comment.Feb 11 2015, 1:44 PM

Wikimedia will apply to Google Summer of Code and Outreachy on Tuesday, February 17. If you want this task to become a featured project idea, please follow these instructions.

Qgil added a comment.Feb 16 2015, 11:30 PM

Do you think the size and complexity of this project makes it a good GSoC/Outreachy project?

Qgil lowered the priority of this task from "High" to "Normal".

To create an extension of sufficient quality to be deployed in WMF production (which IMO the end goal should be), there will need to be refactoring to the preferences system in core to make it easily extendable, as well as UX/design work to figure out a user interface that is sane and not scary. My general impression is that refactoring core will end up being most of the work and could easily take an experienced contributor more than 2-3 weeks.

To create an extension of sufficient quality to be deployed in WMF production (which IMO the end goal should be), there will need to be refactoring to the preferences system in core to make it easily extendable, as well as UX/design work to figure out a user interface that is sane and not scary. My general impression is that refactoring core will end up being most of the work and could easily take an experienced contributor more than 2-3 weeks.

Could we make "Refactoring core" into a different project altogether, in that case? Maybe combine it with other smaller tasks to make it big enough for a GSoC/Outreachy project?

Jidanni removed a subscriber: Jidanni.Feb 17 2015, 3:17 AM
In T16950#1042772, @NiharikaKohli wrote:

Could we make "Refactoring core" into a different project altogether, in that case? Maybe combine it with other smaller tasks to make it big enough for a GSoC/Outreachy project?

Er sorry, I meant that I thought the refactoring core part would be too large/complicated for a GSoC project.

Qgil added a comment.Feb 17 2015, 8:55 AM

Thank you for the quick feedback. I will remove this task from Possible-Tech-Projects, then.

-jem- added a subscriber: -jem-.Jun 8 2015, 7:45 PM
WTM added a subscriber: WTM.Sep 15 2015, 11:49 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 15 2015, 11:49 AM
Man77 added a subscriber: Man77.Oct 13 2015, 8:47 PM
Neil_P._Quinn_WMF changed the title from "Global preferences" to "Support global preferences".Nov 11 2015, 11:01 PM
Neil_P._Quinn_WMF edited the task description. (Show Details)
Luke081515 added a subscriber: Luke081515.
MGChecker added a subscriber: MGChecker.
Dalba awarded a token.Jan 24 2016, 4:50 AM
Dalba added a subscriber: Dalba.

Is there a bot or script that can do this now? ("This" = set a preference like gender at every wiki)

Qgil removed a subscriber: Qgil.Jan 25 2016, 10:12 PM

Is there a bot or script that can do this now? ("This" = set a preference like gender at every wiki)

Last month, I wrote a quick script to change preferences on all wikis and now I have rewritten it so that it can be used by others as well. It doesn't have a GUI yet (you have to run it on the browser console) but maybe I'll do that some time in the future. It'll take a while to complete if you have an account on all the wikis. Link: https://meta.wikimedia.org/wiki/User:Glaisher/setGlobalPrefs.js

Thanks, Glaisher. That looks like a scary amount of technical detail for most users, but it will work for some editors with advanced technical skills.

Meno25 removed a subscriber: Meno25.Feb 22 2016, 6:09 PM
RobLa-WMF edited the task description. (Show Details)
TerraCodes added a subscriber: TerraCodes.
santhosh added a subscriber: santhosh.

@GWicke, @Krinkle, and I spoke about this in the ArchCom planning meeting today. I offered to talk to @Legoktm about the status of this, which we did later in the day. That conversation caused Lego to also add the ArchCom-RfC tag to T64559. We plan to bring this up at the next ArchCom discussion that @Catrope is able to attend.

I'm not sure why this task is seemingly so difficult. Is it "just" the user interface portion or are there other complicated pieces?

daniel added a subscriber: daniel.Apr 1 2016, 7:22 AM

@MZMcBride Yes. When looking closely, it becomes clear that we don't really know how we want this to behave, and what we want this to look like. Which settings can be overwritten locally? How do we make it obvious whether a local or a global setting is being used? How to we make it easy to change global and local settings? How do multi-value settings behave? Etc...

@MZMcBride Yes. When looking closely, it becomes clear that we don't really know how we want this to behave, and what we want this to look like. Which settings can be overwritten locally? How do we make it obvious whether a local or a global setting is being used? How to we make it easy to change global and local settings? How do multi-value settings behave? Etc...

Why not start with the simplest approach that could work? You have a binary "enable global user preferences" toggle per-user. (The user can access this toggle at Special:GlobalPreferences or similar probably.) If this toggle is enabled, preferences on all public Wikimedia wikis read from a single global set of preferences, rather than reading from the local wiki.

We can focus on per-setting overrides and wiki sets later, can't we? I think it's a pretty limited use-case to, for example, want to use MonoBook on every wiki except one. Same with user signatures, etc. I think we solve over 80% of use-cases by implementing a simple (read: dumb) binary switch to enable global user preferences. The other 20% we can deal with later.

When I talked to Lego about this task, there was a fair bit of hand-waving about how the current preferences system sucks and should support anonymous users, etc. I agree that there's room for improvement with the current user preferences system, but I think we're letting perfect be the enemy of the good here. On Wikimedia wikis, we have unified login and we have infrastructure in place for sharing data across our wiki family.

Some specific behaviors, such as printing every user option into the HTML page source, may need to be changed before we can proceed, but what I'd like to see on this task (or on a MediaWiki.org page) is a concrete list of action items that get us to a "minimum viable product," as people like to say.

jayvdb added a comment.Apr 7 2016, 2:31 AM

I agree with @MZMcBride that the 80/20 rule applies here. Most casual users will want (or be happy with) the same preferences everywhere, and this would be a sane default for anyone who hasnt modified their preferences.

T22153: Implement global gadgets (WMF-wide) would be necessary for global gadget preferences?

I vaguely recall that Beta features may not be rolled out to all sites, so that could be a headache for global prefs, if beta prefs are stored in the local prefs.
Likewise prefs for extensions that are not globally installed. Currently these prefs are sprinkled around the prefs panels -- if global prefs was active, those local-only extension prefs should be on a separate panel so they are easier to find.

Settings I would want per-site, but maybe this can be fixed by provided a saner default.

I use English language by default, but choose the local languages on Wikipedia sites that I am x-1 or above in the language. I suspect this will be quite common. It would be great if language pref was overridden with the first language in {{#babel:...}} on the user page, like Wikidata uses it to customise the editing languages. That would allow one language in global prefs, and it can be overridden on each site with a custom userpage.

For me, "Email me when a page or a file on my watchlist is changed" needs to be disabled on English Wikipedia, due to volume, but I enable it everywhere else. I would be more than happy if there was a sanity check like "Never email me when my watchlist exceeds 5,000 main space pages".

The same applies for "Page link" notification -- I usually enable it, but I disable it on English Wikipedia. And it would be great if notification types can be digest vs immediate -- then I could have immediate notification as the default, but set "Page link" notifications to be digest notifications. Then my notification preferences can be global ;) And if "watchlisted edit" becomes a notification, I would configure that to also be digest mode, and "Email me when a page or a file on my watchlist is changed" could be disabled everywhere.

Likewise my Recentchanges and Watchlist thresholds (number of days, number of changes) are one set of values on English Wikipedia (very low values), a different set of values on English Wikisource (very high values), and everywhere else I use the defaults. These are harder to globalise, as they reflect my interest level in each site and usage patterns that are very site specific.

I think this solution would be a relly good first step, but you should note that there are problems with a few settngs, for example the signature setting: Most customised signatures are written in a single language, so they shouldn't be used globally. Maybe it would be useful for this case to define a list of settings that can't be set globally. (Gadgets, Signature)

In a second step of implementing this it would be really nice (and propably not too difficult) if you can define a list of Wikis which have independent local preferences instead of using the default global preferences. On this way, users can change the settings for the few wikis they are using more frequently without the need of implementing a complex interface of en/disabling global preferences for single settings in single wikis (which colud be a possible further step).

daniel added a comment.Apr 7 2016, 5:52 PM

@MZMcBride If we find a good, non-confusing way to start simple, I'm all for it. But a simple on/off switch won't cut it, especially since this feature is a lot less useful if it's not on per default.
The most setting that seems most obviously problematic is the UI language: We have a clash of two use cases here. On the one hand, we have plyglot users, who want the UI to be consistent with the content. On the other, we have cross-wiki maintainers, who edit on many wikis with content languages the users don't actually speak, so they want to force the UI language globally. Having the UI language global would cater to the latter, but would be really annoying for the former.

He7d3r added a comment.Apr 7 2016, 8:56 PM

Maybe it would be useful for this case to define a list of settings that can't be set globally. (Gadgets, Signature)

Yeah. I wouldn't like if I enabled a "gadget-foo" globally and then when I access xyzwiki I see that local users created a totally different gadget with the same name as the global one, and which does something I do not want.

Maybe it would be useful for this case to define a list of settings that can't be set globally. (Gadgets, Signature)

Yeah. I wouldn't like if I enabled a "gadget-foo" globally and then when I access xyzwiki I see that local users created a totally different gadget with the same name as the global one, and which does something I do not want.

Worse than some people simply not liking it, that would most likely be considered a security issue.

Stryn added a subscriber: Stryn.Apr 24 2016, 9:00 AM
Nikki added a subscriber: Nikki.Wed, May 18, 12:06 PM

Add Comment