As far as I know:

Fixing the bug 7605 on r17173 produces bug 10837,
however the bug 7605 has marked as wontfix,
the changes for r17173 did not reverted.

The changes on r37662 which would produces bug, though.

fdcn64 wrote:

the interface (UI language and even include content language) and the variants are separated from the actual demand, and it is meaningful. the difference like view (internationalization) and the data (article content) , the text of article converted by variants we should regarded it as content.

In Chinese, there are UI language and variants choose by many people are different , such as the UI language with Traditional Chinese (zh-hant or zh-tw), but the variant have chosen to variant with Chinese (zh).

In addition, under the current implementation code, when the UI language is not in several variants of the main content language, the conversion are prevented, this is not correct. why prohibit conversion in this case? for example, I have a friend whose mother-tongue is english, he is learning Simplified Chinese (zh-hans), so does not understand Traditional Chinese (zh-hant), in his need to read zhwiki, he will be set UI language to English, but set variant to Simplified Chines (zh-hans). However, he cant read in Simplified Chinese for conversion disable.

If it is need in one multi-variants language for simplify the choice, such as set variant converted to UI language, should not deal with LanguageConverter class, it should be in the LanguageConverter derived class for that main language, Of course LanguageConverter may have to do some restructuring.

To return to the current a few bad results you mentioned, seems to have such a problem from r17173. Changes in the r17173, I feel puzzled, in my view, bug 7605 at the request should not be fix, because with confused concept between UI an generated content. he hoped that 'copyright' message displayed as a latinica text at click to 'latinica' tab ,the request is unreasonable, he should set UI language to 'latinica'. if we make interface messages transliterable too, we will inevitably face bug 10837 (Interface "variant" overruling "language" preference).

BTW: Perhaps we should consider add a choice of the drop-down menu for UI language, similar variants tab, used to increase the URL postfix "&uselang=XX".

rainman wrote:

My original change in r17173 was a reaction to comments on bug 7605, not on the base issue which was WONTFIXed. The change did cause bug 10837. Here is a justification for the change:

When an anonymous user comes to a wiki with variants, he/she sees the variant tabs, and understands these mean "show me the wiki in script X" - i.e. both content and interface. This was the default behavior for anonymous users well before r17173. However, when the user logs in, this behavior would just stop working, and some of the content (e.g. article text) would be converted, and other (e.g. navigation) wouldn't. To an average user this is a regression in tab behavior. My original commit tried to fix this by supposing that the interface should always be consistent with the variant in which the article is viewed.

Using interface language for conversion will indeed produce problems outlined in #c2, but I wonder if basic interface consistency is worth sacrificing for extensive customizations I suspect very few would use, or know how to use. Most user don't even know they can change the interface language, let alone the distinction between interface language, content language and variant conversion.

The changes in r17173, the variant setting would override the user language
preferences, even if the user was logged on. This would not only applies
on the anonymous users, this would applies on the logged on users too.

Suggesting WONTFIX per description denoted on comment 2 and attachment 6264.