Change Details

Investigate possible approach for {T16950} -- wish #4 on this year's Community Wishlist. * Would this be a change to the Preferences interface, or an external tool? * Should we use the GlobalPreferences extension? * Does this need to be a gadget? * Does making a change to global prefs result in a push action, or do we need to call every time the user's on a wiki? * What happens when an existing user joins a new wiki? * Are there preferences that should not be able to be set globally?

Investigate possible approach for {T16950} -- [[ https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Miscellaneous#CW2016-R004 | wish #4 ]] on this year's Community Wishlist. * Would this be a change to the Preferences interface, or an external tool? * Should we use the GlobalPreferences extension? * Does this need to be a gadget? * Does making a change to global prefs result in a push action, or do we need to call every time the user's on a wiki? * What happens when an existing user joins a new wiki? * Are there preferences that should not be able to be set globally? ---- //Notes from discussion on 2017-07-20:// A global preferences system could be a tool, extension, or built into core. It could not be a gadget because we do not (yet) have global gadgets, and so a global preferences gadget would have to first be installed in every wiki and this isn't feasible. ## Extension The existing [[https://www.mediawiki.org/wiki/Extension:GlobalPreferences | GlobalPreferences extension ]]. A working installation is here: https://commandos.shoutwiki.com/ (random example, or any other shoutwiki). This introduces a new special page that uses the existing preferences page and adds "make this global" checkboxes to each option. The GlobalPreferences extension works by having a new database table, exactly the same in structure to the normal user_properties table, that is created on only one wiki and accessed by all wikis in the family. It doesn't matter where this table is (i.e. it doesn't even have to be in a mediawiki database, and if it is it doesn't make that wiki special). When a wiki loads user-options, all global ones for that user are loaded to override the local options. It uses a user's [[ https://www.mediawiki.org/wiki/Manual:Central_ID | Central ID ]] to idenfity the user. Pros: - Just one link is added to the standard preferences page. - Will be able to handle new settings when they’re introduced. - Easily handles new wikis - Only shows the prefs that exist on the wiki you’re on - Doesn’t require a ‘central’ wiki (Special:GlobalPreferences is on every wiki in the farm) - Discoverable from preferences Cons: - Inability to override locally (this could be a future feature, see below). - Lots of checkboxes on the global prefs page (one for each option, to say whether it should be used globally; there's no way to determine which should be used otherwise). - NW: UI tweaks are welcome. I submitted T68869 which is why the 2nd checkboxes are now indented! But some unresolved questions still in that task. - The localprefs form is further complicated by showing when an option is global (and thus not settable in the localprefs form). Only for people who have opted in though, so it won't be surprising to them. Overriding with local value over global value: - A local-set value should override a global-value, which should override a local-default value. - One problem with the transition will be that lots of people have local-set values which they'll want to be globalized, but because they're already set locally they won't be. - The globalprefs database would have to store this new local-set value, because otherwise it can't be distinguished from the local-default. For example, if a user sets French globally, but wants Russian on Russian Wikipedia, it's not possible to just set the relevant value in user_options because it's the same as the local wiki default. ## Tool The other option is a Toolforge tool - e.g. Kunal's old experiment https://git.legoktm.com/legoktm/globalprefs Pros: - Could override locally - Easiest to implement - More flexible for UI implementation - Discoverable from preferences - Doesn’t require a central wiki - Could be used to 'unset' a local pref, if the extension did include the override feature (above). Cons: - Won’t include new settings when they’re introduced - May not handle new wikis (the user would have to go back to the tool after logging in to a new wiki for the first time) - Takes a while to copy to all the wikis after saving. (This could happen in the background though, which would be less annoying if no faster. If it did, it could also copy to new wikis; this would require saving OAuth tokens). ## Other ideas: **Having a two-part form, to simplify the UI:** 1. pick notifications you want to change globally (say, language, notifications, and skin) ; 2. then get only those preferences in the global prefs' form. This probably doesn't actually simplify things, because there are up to 60 preferences that would have to be navigated in the first part. At least in the duplicate-the-existing-form approach, the layout is familiar (there's just extra checkboxes added everywhere). **Redesign preferences:** [[ https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences | RFS: Redesign user preferences]] Would a overhaul of preferences (internal structure, and/or UX) help with globalprefs? It might, but probably doesn't need to come first. Redesigning would help with the lack of a preferences system for anonymous users, who at least could have a reduced set of basic preferences (contrast, text-size, Page Previews, fixed-page-width) like [[https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Redesign_user_preferences#The_Appearance_menu | this wireframe]]. ## Summary Perhaps build a tool as a useful and easier thing, but the extension is the better route. This would (at least to start with) provide non-overridable global preferences only.

Investigate possible approach for {T16950} -- [[ https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Miscellaneous#CW2016-R004 | wish #4 ]] on this year's Community Wishlist. * Would this be a change to the Preferences interface, or an external tool? * Should we use the GlobalPreferences extension? * Does this need to be a gadget? * Does making a change to global prefs result in a push action, or do we need to call every time the user's on a wiki? * What happens when an existing user joins a new wiki? * Are there preferences that should not be able to be set globally? ---- //Notes from discussion on 2017-07-20:// A global preferences system could be a tool, extension, or built into core. It could not be a gadget because we do not (yet) have global gadgets, and so a global preferences gadget would have to first be installed in every wiki and this isn't feasible. ## Extension The existing [[https://www.mediawiki.org/wiki/Extension:GlobalPreferences | GlobalPreferences extension ]]. A working installation is here: https://commandos.shoutwiki.com/ (random example, or any other shoutwiki). This introduces a new special page that uses the existing preferences page and adds "make this global" checkboxes to each option. The GlobalPreferences extension works by having a new database table, exactly the same in structure to the normal user_properties table, that is created on only one wiki and accessed by all wikis in the family. It doesn't matter where this table is (i.e. it doesn't even have to be in a mediawiki database, and if it is it doesn't make that wiki special). When a wiki loads user-options, all global ones for that user are loaded to override the local options. It uses a user's [[ https://www.mediawiki.org/wiki/Manual:Central_ID | Central ID ]] to idenfity the user. Pros: - Just one link is added to the standard preferences page. - Will be able to handle new settings when they’re introduced. - Easily handles new wikis - Only shows the prefs that exist on the wiki you’re on - Doesn’t require a ‘central’ wiki (Special:GlobalPreferences is on every wiki in the farm) - Discoverable from preferences Cons: - Inability to override locally (this could be a future feature, see below). - Lots of checkboxes on the global prefs page (one for each option, to say whether it should be used globally; there's no way to determine which should be used otherwise). - NW: UI tweaks are welcome. I submitted T68869 which is why the 2nd checkboxes are now indented! But some unresolved questions still in that task. - The localprefs form is further complicated by showing when an option is global (and thus not settable in the localprefs form). Only for people who have opted in though, so it won't be surprising to them. Overriding with local value over global value: - A local-set value should override a global-value, which should override a local-default value. - One problem with the transition will be that lots of people have local-set values which they'll want to be globalized, but because they're already set locally they won't be. - The globalprefs database would have to store this new local-set value, because otherwise it can't be distinguished from the local-default. For example, if a user sets French globally, but wants Russian on Russian Wikipedia, it's not possible to just set the relevant value in user_options because it's the same as the local wiki default. ## Tool The other option is a Toolforge tool - e.g. Kunal's old experiment https://git.legoktm.com/legoktm/globalprefs Pros: - Could override locally - Easiest to implement - More flexible for UI implementation - Discoverable from preferences - Doesn’t require a central wiki - Could be used to 'unset' a local pref, if the extension did include the override feature (above). Cons: - Won’t include new settings when they’re introduced - May not handle new wikis (the user would have to go back to the tool after logging in to a new wiki for the first time) - Takes a while to copy to all the wikis after saving. (This could happen in the background though, which would be less annoying if no faster. If it did, it could also copy to new wikis; this would require saving OAuth tokens). ## Other ideas: **Having a two-part form, to simplify the UI:** 1. pick notifications you want to change globally (say, language, notifications, and skin) ; 2. then get only those preferences in the global prefs' form. This probably doesn't actually simplify things, because there are up to 60 preferences that would have to be navigated in the first part. At least in the duplicate-the-existing-form approach, the layout is familiar (there's just extra checkboxes added everywhere). **Redesign preferences:** [[ https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences | RFS: Redesign user preferences]] Would a overhaul of preferences (internal structure, and/or UX) help with globalprefs? It might, but probably doesn't need to come first. Redesigning would help with the lack of a preferences system for anonymous users, who at least could have a reduced set of basic preferences (contrast, text-size, Page Previews, fixed-page-width) like [[https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Redesign_user_preferences#The_Appearance_menu | this wireframe]]. ## Summary Perhaps build a tool as a useful and easier thing, but the extension is the better route. This would (at least to start with) provide non-overridable global preferences only.