Page MenuHomePhabricator

reuse $wgDisableLangConversion to be able to disable the conversion entirely
Open, LowPublic


The initial introduction of the $wgDisableLangConversion value was implemented on r6569, and this value has been abandoned on r6817. I think this value should be useful to disable the conversion entirely.

see also bug 18870.

Version: 1.16.x
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:40 PM
bzimport set Reference to bz18958.
bzimport added a subscriber: Unknown Object (MLST).

Negative settings like this are confusing; if it's necessary at all as a site setting it should be something like $wgEnableLangConversion (or $wgEnableLangVariants?). This was false means off and true means on, which is easier to remember. :)

Hopefully this could be fixed on r51128.

The variabled is changed from $wgDisableLangConversion to $wgEnableVariants
to make this more clear. :)

A type check has been applied on r51390 to check whether is is 0 (disabled) or null (not set, by default).

Reverted in r51460 by Werdna, per issues pointed out on Code Review.

I'm not sure if it is related to this bug, but if I add

$wgDisableLangConversion = true;

to LocalSettings.php and create a page with <math>a+b</math>, it is displayed -{R|a + b}- (and if I remove the setting, the formula works as expected).

Should this be reported as a new bug or is it a consequence of this one?

Current state:

  1. $wgDisableLangConversion is still there as a working conf setting.
  2. User pref setting hadn't been used for years, and was removed in I92e8de7d. *
  • No good reason to make this working, as this user will not be able to view pages written by others with any conversion syntax. It's more usable to set user variant to the main language code.

The issue reported by mybugs.mail:

Have to be fixed after I90965346 is merged or there'll be a conflict (not merging conflict but designing conflict), but I90965346 depends on Iec98e472 which is pending review.