Seems this change was causing the bug 10837.
Or is that any other method to catching the user variant to getting
the variant setting for the current user?
The problem that is, for axample, if a user selected the user language
with "zh-hk", and a variant with "zh-cn", then the value of the code
should be the user language (zh-hk), but not the variant (zh-cn). The
variant setting *should not* override the user language setting
(userlanguage =/= uservariant).
However, seems this kind of settings was spread out though out the JS
in the kk message file. I think we can have a method to catch the user
variant, but not modifying the current user language in the StubObject
class.
Shinjiman
-----------------------------------------------------------------------------------------------------------------------------------------
Revision: 17173
Author: rainman
Date: 2006-10-21 18:24:39 -0700 (Sat, 21 Oct 2006)
Log Message:
-----------
Fix bug #7605. For logged-in users use the selected variant(if any)
insted the one from user settings.
Modified Paths:
--------------
trunk/phase3/includes/StubObject.php
Modified: trunk/phase3/includes/StubObject.php
===================================================================
--- trunk/phase3/includes/StubObject.php 2006-10-22 00:56:28 UTC (rev 17172)
+++ trunk/phase3/includes/StubObject.php 2006-10-22 01:24:39 UTC (rev 17173)
@@ -92,6 +92,15 @@
$code = $wgRequest->getVal('uselang', '');
if ($code == '')
$code = $wgUser->getOption('language');
+
+ // if variant is explicitely selected, use it instead the one from wgUser
+ // see bug #7605
+ if($wgContLang->hasVariants()){
+ $variant = $wgContLang->getPreferredVariant(false);
+ if($variant != $wgContLanguageCode)
+ $code = $variant;
+ }
+
# Validate $code
if( empty( $code ) || !preg_match( '/^[a-z]+(-[a-z]+)?$/', $code ) ) {
$code = $wgContLanguageCode;