Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to "1" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).

Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, "1"/"0" or null. You should just check for truthiness in this case.

I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.

The integer came from $wgDefaultSettings. Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.

(In reply to Bartosz Dziewoński from comment #1)

...
normalizing values of boolean prefs to true/false just before building this
list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.

+1 for normalizing boolean preferences so that either

mw.user.options.get( 'anyBooleanPreference' ) === true
mw.user.options.get( 'anyBooleanPreference' ) === false

and nothing else.

The current behavior is *very* inconvenient:

• If I do not set $wgDefaultUserOptions['usebetatoolbar']

(i.e., if I use WikiEditor's default):

• • If I don't change the preference mw.user.options.get( 'usebetatoolbar' ) === null
  • If I enable the preference mw.user.options.get( 'usebetatoolbar' ) === "1"
• If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
  • If I don't change the preference mw.user.options.get( 'usebetatoolbar' ) === 1
  • If I disable the preference mw.user.options.get( 'usebetatoolbar' ) === "0" (non-empty string == true!)
• On English Wikipedia
  • If I don't change the preference mw.user.options.get( 'usebetatoolbar' ) === 1
  • If I disable the preference mw.user.options.get( 'usebetatoolbar' ) === "" (empty string!)

[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641

I have had similar difficulties and personally prefer booleans wherever possible. They're more reliable and less likely to be unpredictable. They are either true or false or they're invalid.

Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.

However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.

So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:

rclimit: 50
rows: "30"
searchNs0: true
searchNs1: false
..
searchNs10: "1"
searchNs11: false
searchNs12: false
searchNs13: false
searchNs14: "1"

Quite the mix up.

Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a kind property (for int, bool or str). Or perhaps something we can derive from the type property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.

Hello, we at Russian Wikipedia had months of interwiki gadgets not working for some users, because at first compact-language-links user option was set to "" when switched off, but after some change switching it on and off turns it to "0". (Was finally fixed here.) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.

I have no idea why this task's priority is set to "Low". I don't know the site policy regarding changing priorities, I will try change to "Normal" at least, maybe needs "High".

Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?

Also, just to note that email-blacklist is another outlier and is actually an array.

@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.

This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).