Last modified: 2011-01-25 00:30:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10837 - Interface "variant" overruling "language" preference [bug in StubUserLang::_newObject()]
Interface "variant" overruling "language" preference [bug in StubUserLang::_n...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: High major with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 10704 11194 12397 13226 14162 14351 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-07 17:08 UTC by とある白い猫
Modified: 2011-01-25 00:30 UTC (History)
10 users (show)

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


Attachments
Language and variant setting for a logged on user (language=zh-hk, variant=zh-hans) (318.59 KB, image/png)
2009-06-25 12:59 UTC, Shinjiman
Details

Description とある白い猫 2007-08-07 17:08:51 UTC
At http://ku.wikipedia.org/wiki/Taybet:Preferences the "variant" setting is overruling my language preference. I am uncertain if this is a local or global problem.
Comment 1 Raimond Spekking 2007-08-07 17:20:25 UTC
Same problem with http://kk.wikipedia.org and http://zh.wikipedia.org

First help: set the variant to "ku" instead of "ku-arab" or "ku-latn" / "kk" instead of "kk-kz"/"kz-cn"/"kz-tr" ...

But I think it's a global problem with the variant thing. 
Comment 2 Brion Vibber 2007-08-08 17:06:03 UTC
Please specify:

1) An exact set of steps to reproduce the problem

2) A description of what the problem is

3) An example of what would be correct behavior

4) An example of actual incorrect behavior
Comment 3 Brion Vibber 2007-08-08 17:06:12 UTC
*** Bug 10704 has been marked as a duplicate of this bug. ***
Comment 4 とある白い猫 2007-08-10 12:46:48 UTC
1) Select a non local language (say English) at the local-language Wikipedia. Hit save. Works fine. Now select a "variant" from prefs and hit save. You see the variant even though the language you selected is different. 

Alternatively choose a language and variant at the same time. Regardless of what language you pick you will be forced to use the "variant".

2) The interface is not set to my preference (of English) but overruled to the "variant".

3) If I change my language preferences to something that has no "variant" the variant option should be disabled or/and any value it holds should be disregarded.

4) The "variant" overrules the language preference. The interface of the entire wiki becomes a foreign language until I alter my "language setting" twice to reset it back to what I want (I just found out this trick).
Comment 5 Shinjiman 2007-08-17 12:18:19 UTC
Changing the severity from normal to major, this problem exists in all languages which have variants enabled (kk/ku/sr/zh), and a variant is selected.
Comment 6 Rob Church 2007-08-17 12:34:18 UTC
StubUserLang::_newObject() checks that the content language ($wgContLang) has variants, but doesn't check the selected user language itself, nor does it appear to validate the selected variant with respect to the user language (i.e. "is the selected variant valid for this language?").

[See includes/StubObject.php, lines 94-99]
Comment 7 Shinjiman 2007-08-17 14:09:11 UTC
Should the part added on r17173 moved to another new class like StubUserVariant or something like that? Also adding another JavaScript variable wgUserVariant into includes/Skin.php are considerable.
Comment 8 Brion Vibber 2007-09-05 15:16:09 UTC
*** Bug 11194 has been marked as a duplicate of this bug. ***
Comment 9 Rob Church 2007-09-05 15:56:03 UTC
(In reply to comment #7)
> Should the part added on r17173 moved to another new class like StubUserVariant
> or something like that? Also adding another JavaScript variable wgUserVariant
> into includes/Skin.php are considerable.

No, because there's no such thing as a UserVariant object (there's a converter, but that's different matter) - the bug should just be fixed. :)

Comment 10 Niklas Laxström 2007-12-23 18:09:36 UTC
Added check that interface language === content language before using the variant in r28802.
Comment 11 AlefZet 2007-12-23 19:53:22 UTC
(In reply to comment #10)
> Added check that interface language === content language before using the
> variant in r28802.
Doesn't work as intended at all in any multi-script language. Should reverted immediately, because blocked normal functioning.
Comment 12 Niklas Laxström 2007-12-23 20:23:44 UTC
How it is intented to work then?
Comment 13 AlefZet 2007-12-23 20:54:16 UTC
Intended:
> 3) If I change my language preferences to something that has no "variant" the
> variant option should be disabled or/and any value it holds should be
> disregarded.

With applied r28802, content conversion is disabled, interface is mix from selected language variant and from fallback variant, changing language/variant in preferences doesn't take any effect. Links (eg interwikis) are converted but shouldn't it. Nightmare!
Comment 14 Niklas Laxström 2007-12-23 21:53:39 UTC
Maybe you have stale variant set in preferences? I tested with different combinations:

interface = sr: Variant settings determines which variant to use for both interface and content, changing variant in tabs changes both.
interface = sr_ec or sr_el: interface stays constant, content depends on selected variant form preferences or tabs

kk seems to be broken, it throws php notices.
Comment 15 Niklas Laxström 2007-12-24 13:16:55 UTC
*** Bug 12397 has been marked as a duplicate of this bug. ***
Comment 16 Niklas Laxström 2007-12-24 13:24:13 UTC
From above:
>With changes in r28802 on all special pages: disabled variants conversion,
>disabled switching interface language, interface is mix from selected variant
>and fallback language.

I do not understand how that change would disable interface language selection, its only point was to *allow* interface language selection other than content language.

There is clearly something wrong how and when conversion is applied, but disabling interface language preference like this is not a solution. 
Comment 17 AlefZet 2007-12-24 14:25:11 UTC
What we have now with this "solution"? We have wrecked conversion...

This bug need some other way. 

I think need remove variants code from $wgLanguageNames and add something like:

$wgLanguageNames = array(
...
	'kj' => array('Kwanyama', 0)		# Kwanyama
	'kk' => array('Қазақша', 1)	# Kazakh
	'km' => array('ភាសាខ្មែរ', 0)	# Khmer, Central
...
);

where 0 - means without variant, 1 - multi-variant

$wgVariantsNames = array( 
	'kk-arab' => "\xE2\x80\xABقازاقشا (تٴوتە)\xE2\x80\xAC",	# Kazakh Arabic
	'kk-cyrl' => "\xE2\x80\xAAҚазақша (кирил)\xE2\x80\xAC",	# Kazakh Cyrillic
	'kk-latn' => "\xE2\x80\xAAQazaqşa (latın)\xE2\x80\xAC",	# Kazakh Latin
	'kk-cn' => "\xE2\x80\xABقازاقشا (جۇنگو)\xE2\x80\xAC",	# Kazakh (China)
	'kk-kz' => "\xE2\x80\xAAҚазақша (Қазақстан)\xE2\x80\xAC", # Kazakh (Kazakhstan)
	'kk-tr' => "\xE2\x80\xAAQazaqşa (Türkïya)\xE2\x80\xAC",	# Kazakh (Turkey)
);

Advantage of this is that we not display variants in  Language list for languages witout languages
Comment 18 Niklas Laxström 2007-12-24 16:29:13 UTC
Forgot to mention that I reverted in r28824 in last comment.

Why do you want to remove variants from language list? Why shouldn't user be allowed to choose some specific variant as interface language?
Comment 19 AlefZet 2007-12-24 16:54:36 UTC
It is no problem if variant choice will display only when is variants for such language. Not need so many words: anyway r28802 should be reverted for now.
Comment 20 AlefZet 2007-12-24 20:48:49 UTC
r28802 is reverted now. Thanks for Your understanding, Niklas.

Merry Xmas!

AlefZet
Comment 21 Niklas Laxström 2008-03-02 16:34:30 UTC
*** Bug 13226 has been marked as a duplicate of this bug. ***
Comment 22 Brion Vibber 2008-05-19 17:07:27 UTC
*** Bug 14162 has been marked as a duplicate of this bug. ***
Comment 23 Brion Vibber 2008-06-02 15:55:12 UTC
*** Bug 14351 has been marked as a duplicate of this bug. ***
Comment 24 Robert Stojnic 2008-07-14 21:33:25 UTC
Fixed in r37662.
Comment 25 fdcn 2008-07-15 13:18:49 UTC
something is wrong on r37662. when language that user set isn't mMainLanguageCode, then conversion is prevent. this is not we want.

don't modify converter for problem about language 
Comment 26 fdcn 2008-07-15 13:19:39 UTC
sorry for my poor english.
Comment 27 Robert Stojnic 2008-07-15 16:59:38 UTC
Thanks for the report. Hopefully fixed in r37703.

Comment 28 Brion Vibber 2008-07-15 21:08:14 UTC
Woohoo!

But some quick follow-up: I still see variant tabs being displayed on the page, but they have no function when the UI language is not set to the content language.

Most likely, one of the following should occur:

* Variant tabs should be hidden in this case

or

* Variant tabs should be functional for page content, while not disturbing UI
Comment 29 Robert Stojnic 2008-07-16 17:39:29 UTC
I guess the second option would be preferable. However, as implemented currently, messages passed through the parser (e.g. via parseinline) and special page names are also converted, which produces цyриллиц енглисх for en interface in sr-ec variant.
Comment 30 Siebrand Mazeland 2008-09-14 10:10:34 UTC
Can this issue be closed, or what remains to be done, and who volunteers to do it?
Comment 31 Shinjiman 2009-05-30 19:50:07 UTC
Hopefully this was fixed in r51204.

Please reopen the bug if the issue still exists.
Comment 32 Robert Stojnic 2009-06-23 04:36:56 UTC
It looks like it's now impossible to have the wiki consistently in any except the main script. 

If I pick the default 'sr' language interface then the interface is in cyrillic and I can use language conversion, and e.g. have content in latin (sr-el). However, if I pick sr-el as my interface then I cannot pick any language conversion and the content is in mixed latin-cyrillic (mostly cyrillic). So now as I result, if I want the whole wiki being in one script I need to use sr + sr-ec, all other combinations will give me mixed script.

IMO this is a bigger issue than the behavior reported in this bug. 
Comment 33 Shinjiman 2009-06-23 05:44:56 UTC
Tried the following combinations so far:

*'sr' as interface and 'sr-el' as variant: Content would be in latan script.
*'sr' as interface and 'sr-ec' as variant: Content would be in cyrillic script.
*'sr' as interface and 'sr' as variant: Content would be mixed.

*'sr-el' as interface and 'sr-el' as variant: Content would be in latan acript.
*'sr-el' as interface and 'sr-ec' as variant: Content would be in cyrillic script.
*'sr-el' as interface and 'sr' as variant: Content would be mixed.

*'sr-ec' as interface and 'sr-el' as variant: Content would be in latan acript.
*'sr-ec' as interface and 'sr-ec' as variant: Content would be in cyrillic script.
*'sr-ec' as interface and 'sr' as variant: Content would be mixed.

Seems all of the combinations above was works.
Please note that the interface mesages 'sr' has a fallback to 'sr-ec', so choosing 
the 'sr' as interface would showing the cyrillic script in the interface message 
is the default behaviour on the message file.
Comment 34 Robert Stojnic 2009-06-23 08:27:10 UTC
Something quite weird is going on. If I select sr-el + sr-el and hit Save in preferences it works the first. However, if I hit save again without changing anything it resets to sr + sr. Not sure if it is related? 
Comment 35 Shinjiman 2009-06-23 09:00:06 UTC
It does the same on comment 34 using zh and kk.
Seems it does not related to this one and could it be related to the new preference system?
Comment 36 Shinjiman 2009-06-23 09:54:16 UTC
(In reply to comment #34)
> Something quite weird is going on. If I select sr-el + sr-el and hit Save in
> preferences it works the first. However, if I hit save again without changing
> anything it resets to sr + sr. Not sure if it is related? 

Tested the changes before r51204, it does the same matter.
I think there would be more chance for the issue related to the new preferences.
Comment 37 Shinjiman 2009-06-25 12:59:00 UTC
Created attachment 6264 [details]
Language and variant setting for a logged on user (language=zh-hk, variant=zh-hans)

(In reply to comment #32)
> It looks like it's now impossible to have the wiki consistently in any except
> the main script. 
> If I pick the default 'sr' language interface then the interface is in cyrillic
> and I can use language conversion, and e.g. have content in latin (sr-el).
> However, if I pick sr-el as my interface then I cannot pick any language
> conversion and the content is in mixed latin-cyrillic (mostly cyrillic). So now
> as I result, if I want the whole wiki being in one script I need to use sr +
> sr-ec, all other combinations will give me mixed script.
> IMO this is a bigger issue than the behavior reported in this bug. 

Tested and this only happens when a user has been logged in.
For anonymous users the interface message will follow the variant so the language is consistent.

For the logged on users it is suggested to change the interface language via Special:Preferences or atttach the "?uselang=xx" on the URL instead of mixing the interface language and variant together.

It's actually the interface language and variant does the different matter and they cannot treated as the same thing. (see also bug 14823)
Comment 38 Shinjiman 2009-06-25 13:02:01 UTC
(In reply to comment #34)
> Something quite weird is going on. If I select sr-el + sr-el and hit Save in
> preferences it works the first. However, if I hit save again without changing
> anything it resets to sr + sr. Not sure if it is related? 

Seems this does not related to this issue as previously committed.
Thus remarking this bug as FIXED as the variant is no longer overruling language preference.

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


Navigation
Links