Last modified: 2014-03-08 21:42:18 UTC
Currently user can set the only one interface language. However, if the message in such language is missing, he's getting the default fallback language which doesn't necessarily have to be the one he understands. So he should have ability to set at least one fallback lang which would be used before the global default. If possible, there should be configurable list of more langs. Kind of similar to browser's accept language settings.
*** Bug 17612 has been marked as a duplicate of this bug. ***
Working on these modifications (please comment, if you disagree, or something is missing): - Add $wgUserFallbackLanguages = 0...N - in [[Special:Preferences]], after user language/version, add N=$wgUserFallbackLanguages fields, labelled 'Fallback language' (for N=1) or 'Fallback language n' (n=1..N, for N>1) with a language selector which can be left blank. - add a field FallbackLanguage to the user object holding a string of comma separated language codes - with duplicates, and anything behind "en", removed. (Should there be an error message saying, "you cannot go beyond English?") - keep it in the options field in the data base, too. - introduce it to message retrieval, and - follow user fallback languages before any language fallback languages are evaluated, stacking them to the end, thereby - avoid checking any language a second time, or anything at all after "en". - replace user language by the complete chain of user language plus user fallback languages, where appropriate for proper caching.
Bug 17608 related.
Why not go one step further and use the browser's accept-language setting for the user's default UI and fallback languages? That's what it's for, after all. The preference could then exist to override it for logged-in users.
(In reply to comment #4) > Why not go one step further and use the browser's accept-language setting for > the user's default UI and fallback languages? That's what it's for, after all. > The preference could then exist to override it for logged-in users. This is not feasible for anonymous users because it would break or at least severely fragment the Squid cache. I believe zhwiki does do something with Accept-Language, but IIRC that's very limited.
@Purodha: The assumption that English is the definitive and final fallback is not necessarily valid. Customized local messages don't have to exist in English. For example, an English native speaker visiting a Russian wiki might want to set 'en,ru'.
(In reply to comment #6) > @Purodha: The assumption that English is the definitive and final fallback is > not necessarily valid. Customized local messages don't have to exist in > English. For example, an English native speaker visiting a Russian wiki might > want to set 'en,ru'. Such a fallback chain would make no sense, because there are no missing messages in English. Only if a message is missing in a language does the fallback take effect. For this same reason, all fallback chains must end with en to ensure there are no undefined messages.
But another in-between would be nice. For example when visiting the Frisian Wikipedia (fr.wikipedia) I prefer to have it primarily on fr with a fallback to 'nl' (and for technical reasons a default under that to 'en'). This way it's pretty much guranteed that the interface will be all Frysian or Dutch. And only ever English if neither is specified.
(In reply to comment #8) > For example when visiting the Frisian Wikipedia (fr.wikipedia) I prefer to have > it primarily on fr with a fallback to 'nl' (and for technical reasons a default > under that to 'en'). This way it's pretty much guranteed that the interface > will be all Frysian or Dutch. And only ever English if neither is specified. s/fr/fy/ ;-)
(In reply to comment #7) > (In reply to comment #6) > > @Purodha: The assumption that English is the definitive and final fallback is > > not necessarily valid. Customized local messages don't have to exist in > > English. For example, an English native speaker visiting a Russian wiki might > > want to set 'en,ru'. > Such a fallback chain would make no sense, because there are no missing > messages in English. Only if a message is missing in a language does the > fallback take effect. For this same reason, all fallback chains must end with > en to ensure there are no undefined messages. Well, there are some local messages used on some wikis, which are not part of MediaWiki core or its extensions, so such fallback is not nonsense in general, however those are rare cases.
(In reply to comment #10) > Well, there are some local messages used on some wikis, which are not part of > MediaWiki core or its extensions, so such fallback is not nonsense in general, > however those are rare cases. Well, there is a fallback for missing messages: <messagename> This assures, no message goes undisplayed, even if <messagename> may be not functioning is some very special contexts, and for those "messages" of a more technical nature, that are not plainly displayed or sent out as e-mails. Btw: One of the disadvantages of our current language (and fallback) treatment is, we cannot choose to have this fallback. Being able to ?uselang=und (undefined) or ?uselang=zxx (no linguistic content) would imho be a great help to localizers who happen to stumble over messages having typing errors, or not translated optimally regarding context. Redisplaing a wiki page with messages replaced by <messagename> usually tells you at once, which message to amend. Currently, localizers have to find messages via text searches in the message contents, which is cumbersome for text made up from several messages, and at least is quite time consuming.
Encountered another problem: We have some partial localisations, that heavily depend on their respective fallbacks, without which they were incomplete. These are several "xzz-formal" ones where only those messages are translated that directly address users, overriding informal/familiar/direct wording with formal/respectful/polite wording, and "arz" which localizes only those Egypt-spoken-Arabic having computerese terms and/or being different from "ar", the common macrolanguage standard Arabic ones. These fallback languages have to be consulted *before* user-set fallback chains are being checked. What if, for each language, we specify a fallback chain including the point where a user-specified chain is to be inserted, if any?
Until a better design is decided upon, is it possible to implement something very simple - to let the user choose in the preferences ONE language that will show up when a message in his first language is not available? I am going to work with the Circassian community in Israel to help them develop the Wikipedia in their language. The fallback language for their language in MediaWiki is Russian, which is good for the many Circassians that live in Russia, but for Circassians in Israel the preferred second language is Hebrew and for Circassians in Turkey and Jordan it's Turkish and Arabic, respectively. In the current state of affairs they get a mix of Circassian and Russian, which isn't helpful for them and they are forced to switch the whole interface to Hebrew, Turkish or Arabic. The problem with this is that it won't be apparent to them which messages still need translation. Forcing English as a fallback language for all of them isn't a good solution either.
Unless we have language- (and btw. directionality-) aware message handling and proper caching for it, there is imho no way to make this happen. Meeting these requirements requires imho a major rewrite of code.
Isn't support for that already present with the $fallback variable that some language codes have ?
No. My current understanding of the situation is this: Both caching and message handling are in most of their parts not language aware. That means, when for any given language L, messages are taken from one of its (static and fixed) fallback languages, X, Y, Z, these messages are both cached and rendered as if they were in language L. This is wrong but acceptable, because fallback languages rarely change, and so do untranslated messages causing them to be used. If any user can put their own fallback languages somewhere into the chain, some fallback languages depend an arbitrary user viewing a page. Whether or not fallback languages are used at all depends on arbitrary things like cache state. If individual fallback languages are used, they may be cached, and thus are shown to users having the same language L, but may have different fallback languages. That is not acceptable. We need, so to say, to make every message aware of the language it is in, and caching must be done in a way that distinguishes existing language combinations of cached data on a per message basis. Please correct me, if I overlooked something.
(In reply to comment #16) > No. > > My current understanding of the situation is this: Both caching and message > handling are in most of their parts not language aware. That means, when for > any given language L, messages are taken from one of its (static and fixed) > fallback languages, X, Y, Z, these messages are both cached and rendered as if > they were in language L. > That's correct.
Quick note -- chatting with Danny B at Wikimania, agree this could be useful. May or may not be easy with the current message caching infrastructure, but should be easy if it gets clean enough if it's not already. :) Fallbacks in *content* need to be pretty consistent; fallbacks in UI can be more flexible. Messages as exported to eg JS may also need such custom orders to be specially marked, or else loaded up in a slightly different way.
Just to explain the current message caching architecture a bit. Like mentioned, fallbacks are cached as if they were in the original language. There is quite literally no way to find out the actual language of a cached message (until my patch is merged). Note that this is only the CDB cache I'm talking about. Messages can also be overridden in the DB. With that said, we obviously cannot construct user-specific CDB caches, because that'd be insane. The only way to implement this would be to manually query each language in the user's fallback sequence until it gets a hit. I'm not sure exactly how feasible such a situation would be. Fetching interface messages is slow enough as it is...
(In reply to comment #13) > I am going to work with the Circassian community in Israel to help them > develop > the Wikipedia in their language. The fallback language for their language in > MediaWiki is Russian, which is good for the many Circassians that live in > Russia, but for Circassians in Israel the preferred second language is Hebrew > and for Circassians in Turkey and Jordan it's Turkish and Arabic, > respectively. Could we use pseudo language definitions that define a fallback list? e.g. kbd_RU, kbd_IL, kbd_TR and kbd_JO
