Last modified: 2014-03-08 21:42:18 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 11267 - User should be able to set fallback language(s) in preferences
User should be able to set fallback language(s) in preferences
Status: NEW
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Normal enhancement with 11 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
: 17612 (view as bug list)
Depends on: 31305
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-10 00:45 UTC by Danny B.
Modified: 2014-03-08 21:42 UTC (History)
17 users (show)

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


Attachments

Description Danny B. 2007-09-10 00:45:46 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.
Comment 1 Raimond Spekking 2009-02-22 09:57:04 UTC
*** Bug 17612 has been marked as a duplicate of this bug. ***
Comment 2 Purodha Blissenbach 2009-03-07 12:01:23 UTC
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.

Comment 3 Danny B. 2010-04-28 23:26:22 UTC
Bug 17608 related.
Comment 4 Martijn Dekker 2010-06-14 13:46:02 UTC
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.
Comment 5 Roan Kattouw 2010-06-14 13:47:42 UTC
(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.
Comment 6 Martijn Dekker 2010-06-14 14:09:32 UTC
@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'.
Comment 7 Roan Kattouw 2010-06-14 14:24:12 UTC
(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.
Comment 8 Krinkle 2010-06-14 14:43:38 UTC
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.
Comment 9 Casey Brown 2010-06-14 14:48:49 UTC
(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/ ;-)
Comment 10 Danny B. 2010-07-21 22:37:40 UTC
(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.
Comment 11 Purodha Blissenbach 2010-07-26 06:01:10 UTC
(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.
Comment 12 Purodha Blissenbach 2010-09-23 20:34:37 UTC
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?
Comment 13 Amir E. Aharoni 2010-10-18 09:47:40 UTC
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.
Comment 14 Purodha Blissenbach 2011-03-08 20:13:15 UTC
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.
Comment 15 Krinkle 2011-03-08 20:40:40 UTC
Isn't support for that already present with the $fallback variable that some language codes have ?
Comment 16 Purodha Blissenbach 2011-03-09 10:45:36 UTC
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.
Comment 17 Roan Kattouw 2011-03-09 11:15:39 UTC
(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.
Comment 18 Brion Vibber 2011-08-04 16:46:35 UTC
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.
Comment 19 Tyler Romeo 2013-07-27 21:04:10 UTC
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...
Comment 20 John Mark Vandenberg 2013-10-02 02:49:47 UTC
(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

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


Navigation
Links