Community Tech/Global preferences

This page documents a project the Wikimedia Foundation's Community Tech team has worked on or declined in the past. Technical work on this project is complete.

We invite you to join the discussion on the talk page. You may track this project's progress on T16950.

Tracked in Phabricator:
Task T16950

The Global preferences project aims to make it easier for contributors who work on multiple wikis to set some of their preferences once, and have that setting apply across all wikis. The prime example is setting the interface language -- without global preferences, a user whose primary language is French has to change the language in their preferences on Meta, Commons, Wikidata, Spanish Wikipedia, etc. For people whose work involves multiple wikis -- functionaries, developers, program organizers, gadget creators -- this is a tedious step that should be handled automatically.

This was the #4 wish on the 2016 Community Wishlist Survey, and the Community Tech team is currently working on it. Community Tech's work is building on the GlobalPreferences extension, which was created by Kunal Mehta (User:Legoktm). The team is rewriting some of the backend code, and making some changes to the user interface.

Project updates

July 9, 2018

Global Preferences has finally been enabled on all Wikipedias! Work is ongoing to allow API edits to global preferences and local overrides. We expect to launch that in the next week or so.

May 30, 2018

Global Preferences is now enabled on all non-Wikipedia wikis! We have a few small issues to address (local overrides for notifications does not work - phab:T195288, the 'select all' message is not clear enough - phab:T194908, and a performance optimization - phab:T192503) before we enable on all Wikipedians.

Community Tech is currently focusing all attention on another 6-week project so development will resume in July. We hope to have Global Preferences completed and rolled-out by the end of July or early August.

April 26, 2018

We are still battling some database errors with Global Preferences and attempt bi-weekly releases. We still intend to complete this project but the final stretch is proving to be more difficult than anticipated. We're hopeful that we can get it by the end of May.

March 17, 2018

Global Preferences will be going out on all projects next Monday, if all goes well. We've fixed all of the design issues and bugs that were brought to our attention during the testing phase. Note that signatures will not be globalizable right now due to issues surrounding localization across multiple projects. This is being tracked in task T188200.

February 23, 2018

Global Preferences can be tested on Beta wikis here: https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page !

February 13, 2018

Development of GlobalPreferences for Wikimedia wikis is nearly complete. We aim to release it to beta wikis (which can be found at https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page) by the end of February 2018. If QA and testing goes according to plan, we aim to enable GlobalPreferences on all Wikimedia wikis in early March 2018.

August 23, 2017

Work has started in earnest on Global preferences, and we've got some questions about how to approach local exceptions in the section above.

So far, the responses on the talk page about local exceptions have mostly focused on language and notifications. If we build local exceptions for specific preferences like language, here's one way that could work: an extra checkbox under the preference that says "Set an exception to this global preference". When you click that checkbox, a field opens underneath it, which says "If you want to use the default language on specific wikis instead of your global preference, list the wiki(s) in the field below, one wiki per line, using the form en.wikipedia."

Extra checkbox
Opening the field

July 28, 2017

Here's wireframes for a tweak to the UI, putting the global checkboxes in a column on the left, along with a dropdown switch to set "all" or "none" at once.

Current questions

We haven't figured out how to handle local overrides yet.
Which sections can't be globalized? Sam says in phab:T68869#3480376: Email address, gadgets, timezone offset. These should be removed from the GlobalPreferences interface. (Also signature? These sometimes have links to specific wiki pages.)

Signatures should not be localized. Not only because different wikis have different conventions regarding these, but also because this will enable users to shoot themselves on foot: for example, a Spanish user might set their signature to [[Usuario:Foo|Bar]], but that will not work on most wikis. Max Semenik (talk) 23:33, 28 July 2017 (UTC)[reply]

Timezone can be globalized I think, it's not at the moment but that's a bug. The current list of non-globalisable preference form items is: 'realname', 'userid', 'usergroups', 'editcount', and 'registrationdate'. To this list should be added gadgets, but surely it'd be good to find a way to globalize email addresses? How many people want different email addresses on different wikis? Although, perhaps because it's a different storage structure we could leave it for now? Other things to remove from globalpreferences are 'Edit watchlist', and 'Watchlist RSS Token'. Sam Wilson 01:47, 31 July 2017 (UTC)[reply]

How will new settings be handled, when they're introduced on Preferences?

This doesn't need anything from us, GlobalPreferences just uses whatever preferences available. Max Semenik (talk) 23:33, 28 July 2017 (UTC)[reply]

The only thing might be to provide some way for extensions to say whether their preferences should be allowed to be global? e.g. Gadgets would do that. Sam Wilson 01:47, 31 July 2017 (UTC)[reply]

Would this release as a Beta feature?

Beta features are enabled per wiki, which makes no sense for this extension. And because GlobalPreferences is already opt-in based, an extra beta feature would not make sense anyway. Just flip it on and advertize it to users. Max Semenik (talk) 23:33, 28 July 2017 (UTC)[reply]

July 19, 2017

Kunal (User:Legoktm) has worked on two different solutions for this problem: an extension (Extension:GlobalPreferences) and a Toolforge tool (Legoktm/globalprefs).

Extension:GlobalPreferences is currently being used on Shoutwiki -- see swmerchandise.shoutwiki.com (or any other Shoutwiki site) for an example. The extension adds a link on the first box ("Basic information") in the user's preferences: "Set your global preferences". This links to another special page, Special:GlobalPreferences, which offers the same options as the regular Preferences page, plus an extra checkbox for each item that says "Use this preference on all wikis."

The Toolforge tool is an experiment in a different direction -- a separate form that a user could use to set a preference, and then copy it to all wikis. The existing tool only changes the user's interface language.

Community Tech could go in either direction -- there's pros and cons to both -- but we've decided to adapt the extension, improve it and get it released. The extension's strongest advantage is that it's adaptable -- it can include new settings as they're added to Preferences, and it would only show preferences for the wiki that the user is currently on. A separate tool would have to keep updating with new settings as they're released, which isn't likely in the long-term.

One drawback for the extension is that it adds extra checkboxes under each choice on the preferences page, which is messy and difficult to use. We can improve the UI to make things clearer.

Important links

Wishlist proposal and votes
Phabricator ticket tracking the work
GlobalPreferences workboard
Meeting notes
Dev Summit 2017 notes
Community Tech/Global preferences/How it works — Previous help documentation from this page.