For MediaWiki (recent comments | status changes | tags | authors | states | release notes | statistics)
It's so totally broken that I can only assume it's untested. There's no default defined for the variantconversion user preference, so the default comes out of $wgUser->getOption() as null. LanguageConverter::parserConvert() then tests if null == 0, which it is, and so it sets $wgEnableVariants = false. This makes the variant links disappear from the tab list, and the variant preferences disappear from the Special:Preferences. $extraUserToggles doesn't appear to actually do anything in the new preferences system, so there's no way to turn the variant tabs back on. But they will come back on a parser cache hit, since LanguageConverter::parserConvert() is not called in that case and so $wgEnableVariants is true.
I was looking for parser cache pollution, which I'm quite sure is possible, but I couldn't get that far because the feature doesn't work at all.
Please revert these changes and anything else that is related. In the future, please test your code thoroughly before you commit it.
The type check had been added in r51390.
The $extraUserToggles variable on Special:Preferences is currently blocked by the bug 18870.
You missed the point, which was that you have to add a default for every preference, and that preference should default to true. Hacking in a special-case for "no preference" isn't the correct solution.
Seems to also include an unrelated change of name for a configuration variable. Don't do this, and if you do, include backwards-compatibility code.
Reverted in r51460.
