Page MenuHomePhabricator

$wgLanguageCode in LocalSettings.php not respected
Closed, InvalidPublic


Author: mediazilla

If I set $wgLanguageCode in LocalSettings.php then I expect the value set to be
respected. That is, if I specifically make the effort to set it to be "fr" in
LocalSettings.php, I expect, when I refer to $wgLanguageCode, to get the value
"fr". This is not the case.

As it is, when I set it, sometimes it IS respected (for example, when I run the
maintenance/rebuildMessages.php) but at other times (for example, if I naively
use $wgLanguageCode as a variable and expect it to correspond to what I have
explicitly set in LocalSettings.php).

To some degree, it seems simply "working as designed" since the code in
"Setup.php" seems to make the concious decision to take the value from the
current user. However, there seems to be something screwy about the logic that
a user can set a value in LocalSettings which is then blatently ignored.


$IP = "c:\\program files\\apache group\\www\\chainki dev";
ini_set( "include_path", ".;$IP;$IP/includes;$IP/languages;$IP/wikilink/class" );

define( 'MEDIAWIKI', true );

echo("after LocalSettings, wgLanguageCode=$wgLanguageCode<br>");

echo("after Setup, wgLanguageCode=$wgLanguageCode<br>");


The above code, with $wgLanugageCode = "fr" in LocalSettings.php, but with an

"en" user gives:

after LocalSettings, wgLanguageCode=fr
after Setup, wgLanguageCode=en
Finally, wgLanguageCode=en

From "includes/Setup.php"
// wgLanguageCode now specifically means the UI language
$wgLanguageCode = $wgRequest->getText('uselang', '');
if ($wgLanguageCode == '')
$wgLanguageCode = $wgUser->getOption('language');

Validate $wgLanguageCode, which will soon be sent to an eval()

if( empty( $wgLanguageCode ) || !preg_match( '/^[a-z]+(-[a-z]+)?$/',
$wgLanguageCode ) ) {
$wgLanguageCode = $wgContLanguageCode;

What to do? It seems to me that there are 2 fundamentally diffent language
codes represented here: the language code used to build the messages and the
language code of the user. Unfortunately both of these seem to be tried to be
stored in the same global variable. The solution I imagine is to seperate the
two: keep $wgLanguageCode to represent the current user language code (and this
would NOT ever be in DefaultSettings, nor therefore ever in LocalSettings), and
a user configurable language code, e.g. $wgMessageLanguage.

Version: 1.5.x
Severity: normal
OS: Windows XP
Platform: PC



Event Timeline

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

During runtime, $wgLanguageCode refers to the user's selected interface language.
$wgContLanguageCode is always the global setting.

mediazilla wrote:

As it is meaningless for the user to ever set the $wgLanguageCode this variable
should therefore be removed from DefaultSettings.php

There are two variables at runtime:
$wgLanguageCode -- user interface language
$wgContLanguageCode -- content language

Since this feature was not always present, $wgLanguageCode continues
to be used as the configuration setting for compatibility.

Please do not reopen this "bug" simply because you find it distasteful.