Last modified: 2009-12-31 17:17:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T23974, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 21974 - Changing content language code causes Special:Preferences to permanently throw an exception for some users
Changing content language code causes Special:Preferences to permanently thro...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Language converter (Other open bugs)
1.16.x
All All
: Normal normal (vote)
: ---
Assigned To: Philip Tzou
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-31 07:39 UTC by Tim Starling
Modified: 2009-12-31 17:17 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Tim Starling 2009-12-31 07:39:05 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.
Comment 1 Andrew Garrett 2009-12-31 09:28:42 UTC
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.
Comment 2 Philip Tzou 2009-12-31 17:17:21 UTC
Fixed on r60523. Add $fromUser to the condition of returning $this->mPreferredVariant. If I did something wrong, please tell me. Thanks.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links