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;