Page MenuHomePhabricator

Special:Preferences is not working on gu.wiki
Closed, ResolvedPublic

Description

Special:Preferences on gu.wiki:
http://gu.wikipedia.org/wiki/Special:Preferences

It is showing an error message:
Global default '1' is invalid for field math

Backtrace:

#0 /usr/local/apache/common-local/php-1.17/includes/Preferences.php(1154): Preferences::getPreferences(Object(User))
#1 /usr/local/apache/common-local/php-1.17/includes/specials/SpecialPreferences.php(70): Preferences::getFormObject(Object(User))
#2 /usr/local/apache/common-local/php-1.17/includes/SpecialPage.php(579): SpecialPreferences->execute(NULL)
#3 /usr/local/apache/common-local/php-1.17/includes/Wiki.php(250): SpecialPage::executePath(Object(Title))
#4 /usr/local/apache/common-local/php-1.17/includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#5 /usr/local/apache/common-local/php-1.17/index.php(114): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#6 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#7 {main}


Version: unspecified
Severity: major

Details

Reference
bz28152

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:27 PM
bzimport set Reference to bz28152.
bzimport added a subscriber: Unknown Object (MLST).

This only appears when using Gujarati. Preferences work when using English.

Fixed. This was caused by two of the options for the math preference having the same description:

'mw_math_simple' => 'જો સરળ હોય તો HTML અનયથા PNG',
'mw_math_html' => 'જો સરળ હોય તો HTML અનયથા PNG',

I edited [[gu:MediaWiki:mw_math_simple]] to replace PNG with png so the options would be different. I'll add a warning in the message documentation that these options MUST be different, otherwise things break.

  • Bug 28250 has been marked as a duplicate of this bug. ***

Some kind soul deleted a message, and this bug resurfaced. Guess we need a more stable solution.

Please note that you will not notice this bug if you do not have your language set as gu on gu.wikipedia, as it only affects that translation.

Apologies. I had deleted [[gu:MediaWiki:mw_math_simple]] thinking it was vandalism, I now have reverted that, and the issue seems resolved. Max that (un)kind soul was me.. Apologies once again.

(In reply to comment #6)

Apologies. I had deleted [[gu:MediaWiki:mw_math_simple]] thinking it was
vandalism, I now have reverted that, and the issue seems resolved. Max that
(un)kind soul was me.. Apologies once again.

You may want to check a user's global groups before you decide something is vandalism ;)

(In reply to comment #4)

Some kind soul deleted a message, and this bug resurfaced. Guess we need a more
stable solution.

Yes, the gu translations need to be fixed in TWN.

(In reply to comment #7)

Yes, the gu translations need to be fixed in TWN.

Ideally, the whole prefs interface shoulde be changed to work as 'value' => 'ui message' instead of the other way around as we currently do it. Unfortunately, there's no clear way to do that except for a backward-incmpatible rewrite of HTMLForm. Sigh.

(In reply to comment #8)

(In reply to comment #7)

Yes, the gu translations need to be fixed in TWN.

Ideally, the whole prefs interface shoulde be changed to work as 'value' => 'ui
message' instead of the other way around as we currently do it. Unfortunately,
there's no clear way to do that except for a backward-incmpatible rewrite of
HTMLForm. Sigh.

I agree that using translated strings as array keys is not nice, but the expectation that different choices for the same preference are not translated to byte-identical strings is not an unreasonable one IMO.

(In reply to comment #8)

(In reply to comment #7)

Yes, the gu translations need to be fixed in TWN.

Ideally, the whole prefs interface shoulde be changed to work as 'value' => 'ui
message' instead of the other way around as we currently do it. Unfortunately,
there's no clear way to do that except for a backward-incmpatible rewrite of
HTMLForm. Sigh.

This is a deliberate design decision in HTMLForm, used to support grouped options in select boxes. In theory it could have been done differently, I suppose, but why would you want two options to be the same anyway? That's just deliberately confusing.

closing since the specific problem with gu.wiki is fixed. Filed Bug #28313 against HTMLForm.