Last modified: 2009-12-31 17:17:21 UTC
Due to a bug in LanguageConverter::getPreferredVariant(), the default option for user variant ends up being whatever variant the current user already selected in their preferences. This is usually not a problem, but when the content language changes, the list of allowed variants changes, and so Special:Preferences can throw an exception on startup: "Global default 'sr-ec' is invalid for field variant". This makes it impossible for the user to change their preferences. The bug in LanguageConverter::getPreferredVariant() is the fact that it doesn't respect $fromUser=false when there's already a variant cached in $this->mPreferredVariant which did come from the user. Annotation suggests that it's been there for years. Assigning to Philip since I made him the default assignee for language converter bugs, CCing to Andrew for his thoughts about whether this is an appropriate failure mode for Special:Preferences.
The point of having that exception thrown in Special:Preferences was primarily to avoid these sorts of bugs from remaining unnoticed when people added preferences with defaults that did not validate (in fact, it was added as debugging code for a preference I added). I still believe that throwing an exception when encountering an invalid preference default is appropriate, but perhaps it could be restricted to wikis with development warnings on. In production environments, it may make sense to find another value that validates.
Fixed on r60523. Add $fromUser to the condition of returning $this->mPreferredVariant. If I did something wrong, please tell me. Thanks.