= Background
We want to show all the features that a user will opt into when switching from stable to beta so they know what they are gaining by doing so.
= Proposal
Split the settings into stable features and beta features.
List all of them but control the beta features with a toggleswitch
{F11188481}
1. Show user what features will get enabled when Beta is enabled.
2. show toggleswitch for beta feature
3. activate the said features if the toggle switches are turned on
= Mocks
Here's a click through prototype
https://wikimedia.invisionapp.com/share/BMCCQ3OYQ#/screens/241120755
Show lock icons when the features are not enabled
{F11188493}
Enable the features with a checkmark and opacity when the toggleswitch is tapped
{F11188537}
= Acceptance criteria
[] This should be done inside the specialpages feature branch
[] If user toggles beta, the features becomes enabled with green tick mark
[] With beta features with individual setting, the setting will go in the place of the tick mark
note: Currently, all beta features listed above will be included. We will be promoting them separately after the change.
= Developer notes
Ideal this would be implemented by formalising our feature management. Doing so would be much cleaner and require less maintenance.
Features that are enabled in beta but not stable are config variables which are arrays and have stable and beta keys where stable is false and beta is true. As part of this we might want to consider something like
```
wgMFFeatures = [
"MFEnableFontChanger": {
"base": false,
"beta": true
},
]
```
to provide easy lookup.
There is one exception to the rule: MFDisplayWikibaseDescriptions, the logic for which lives in MobileContext::shouldShowWikibaseDescriptions and the config looks like
```
"MFDisplayWikibaseDescriptions": {
"search": false,
"nearby": false,
"watchlist": false,
"tagline": false
},
```
We may want to rethink the logic there if using wgMFFeatures.
When rendering the MobileOptions page we'll want to:
1) Obtain variables with beta/stable switches that we haven't already rendered (and thus assume are unconfigurable)
2) Print these rows in the UI with appropriate opacity. We'd need to generate message keys from config variables e.g "mobile-frontend-option-MFDisplayWikibaseDescriptions-description", "mobile-frontend-option-MFDisplayWikibaseDescriptions-title" and print these in MobileOptions
The feature-like config variables...
Inside MobileFrontend extension.json:
```
"MFEnableFontChanger": {
"base": false,
"beta": true
},
"MFShowFirstParagraphBeforeInfobox": {
"base": true,
"beta": true
},
"MFLazyLoadImages": {
"base": true,
"beta": true
},
"MFLazyLoadReferences": {
"base": false,
"beta": true
},
"MFExpandAllSectionsUserOption": {
"base": false,
"beta": true
},
"MFDisplayWikibaseDescriptions": {
"search": false,
"nearby": false,
"watchlist": false,
"tagline": false
},
```
Inside Minerva skin.json:
```
"MinervaShowCategoriesButton": {
"base": false,
"beta": true
},
"MinervaEnableBackToTop": {
"base": false,
"beta": true
}
```