Last modified: 2010-05-15 15:38:27 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 T8406, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 6406 - $wgLanguageCode in LocalSettings.php not respected
$wgLanguageCode in LocalSettings.php not respected
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
PC Windows XP
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-06-22 14:38 UTC by Hugh Prior
Modified: 2010-05-15 15:38 UTC (History)
0 users

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


Description Hugh Prior 2006-06-22 14:38:48 UTC
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.
Comment 1 Brion Vibber 2006-06-22 15:35:46 UTC
During runtime, $wgLanguageCode refers to the user's selected interface language.
$wgContLanguageCode is always the global setting.
Comment 2 Hugh Prior 2006-06-22 15:48:56 UTC
As it is meaningless for the user to ever set the $wgLanguageCode this variable
should therefore be removed from DefaultSettings.php
Comment 3 Brion Vibber 2006-06-22 16:04:10 UTC
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.

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