Page MenuHomePhabricator

Changing content language code causes Special:Preferences to permanently throw an exception for some users
Closed, ResolvedPublic

Description

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.


Version: 1.16.x
Severity: normal

Details

Reference
bz21974

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:48 PM
bzimport set Reference to bz21974.

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.

PhiLiP.NPC wrote:

Fixed on r60523. Add $fromUser to the condition of returning $this->mPreferredVariant. If I did something wrong, please tell me. Thanks.