Brion Vibber <brion@...> writes:
Shinjiman wrote:
Please note that the original purpose/goal of the Language Converter is to changing the page(article, project page, portal, etc.)'s content *only*
(For
example: [中国↔中國] in Chinese and also [standardize↔standardize] in English). Seems Brion is not understanding the original purpose/goal of
this,
I understand it just fine. I have no idea how it relates to what you're proposing, which appears to be something totally unrelated trying to snag the user-agent's Accept-Language string (?!??!!?)
As this, we still don't have any values that defines the lang attribute in
the
HTML tag, but currently defined by the $wgContLanguageCode. However, if
Brion
(or any developers having the shell access) changed the
$wgContLanguageCode
from "simple" into "en" in the LocalSettings.php at simple, it can correct
the
mislabelled tag. But this change is going to *break up* the user language settings to using the English messages instead of Simple English messages,
No it won't. There is no "simple English" language, it's just English. The defined user interface messages on the wiki will be shown when English is
selected.
On the posts that I've mentioned, as there's some users that using the [zh- tw/zh-hk] user interface language, but have the language variant *turned
off*
[zh]. It is impossible to determining the new lang attribute by the
language
variant.
I don't understand what this means. Can you explain it?
If you mean, "some people haven't selected a language variant", then in that case we cannot assign anything more specific than "zh" to that page display.
Yes, that's what I said in this issue, for my perferences, I've use the Traditional Chinese user interface, and having the language variant disabled [i.e. the language variant is set to zh]. And it is not "some people *haven't* selected a language variant", however it is likely to said that "they have *disabled* the language variant". That's the problem happens as your suggestion that using the language varient to determine the lang attribute.
I've concerned for the problem above, it shows that there is not possible to determine the lang attribute by using the language variant value.
Hence, I've trying to write a method to determine the lang attribute by *both* user interface language value and $wgContLanguageCode. (It's the same design as the submitted function in Bug:5790, I would like to explain these procedures in sentenses.) (And it has been mentioned *in your Point Of View*, this code is writtened totally difficult that you wanted.)
Firstly, we need to check is the $wgContLanguageCode is on the change list, if it is *not*, returns the $wgContLanguageCode value. (This is determined by the first array $wgDispLangNeedChanges)
If the language code *is* on the change list, do the following procedures:
- If the key is found in the correctto list, returns the value which associated to the key (Defined in the second array $wgDispLangChangeTo)
For logged on users ------------------- - A method that can get the lang attribute is trying to get a language code value by User Interface perferences for logged in users.
For anonymous visitors ---------------------- - Then for anonymous visitors, it need to know which font character sets should be used (Simplified Chinese fonts / Traditional Chinese fonts) determine by the HTTP_ACCEPT_LANGUAGE only if the browser *supports and enabled* this function. - If the method determining the lang attribute *fails*, it will use the $wgContLanguageCode for final fallback.
- Finally do the language tag changes as some font character sets supports incorrectly, for example, zh-hk and zh-mo is assigned to use the Simplified Chinese fonts, we need to fix this into zh-hant or something like that as zh- hant is assigned to using the Traditional Chinese fonts charsets. If the key that cannot found in the array, it returns the value $wgContLanguageCode for final fallback. (This is defined in the third array $wgDispLangChanges)
This code would not affects the return value of lang attribute which the $wgContLanguageCode value is *outside* of the lang attribute change list (which is defined in the first array, for example, en, de, fr, ja, ko, etc., i.e. the return value of lang attribute is the same as $wgContLanguageCode)
I think that it win't have problems in my design. However, I did not get *how* this design affects the cache as you've mentioned before. As the best I've done is trying to make a design as good as possible, and solving the problem more effective. :)