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.

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

• Bug 10704 has been marked as a duplicate of this bug. ***

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).

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.

robchur wrote:

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]

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.

• Bug 11194 has been marked as a duplicate of this bug. ***

robchur wrote:

(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. :)

Added check that interface language === content language before using the variant in r28802.

alefzet wrote:

(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.

How it is intented to work then?

alefzet wrote:

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!

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.

• Bug 12397 has been marked as a duplicate of this bug. ***

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.

alefzet wrote:

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

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?

alefzet wrote:

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.

alefzet wrote:

r28802 is reverted now. Thanks for Your understanding, Niklas.

Merry Xmas!

AlefZet

• Bug 13226 has been marked as a duplicate of this bug. ***

• Bug 14162 has been marked as a duplicate of this bug. ***

• Bug 14351 has been marked as a duplicate of this bug. ***

rainman wrote:

Fixed in r37662.

fdcn64 wrote:

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

fdcn64 wrote:

sorry for my poor english.

rainman wrote:

Thanks for the report. Hopefully fixed in r37703.

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

rainman wrote:

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.

Can this issue be closed, or what remains to be done, and who volunteers to do it?

Hopefully this was fixed in r51204.

Please reopen the bug if the issue still exists.

rainman wrote:

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.

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.

rainman wrote:

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?

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?

(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.

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)

Attached:

(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.