Last modified: 2014-11-17 10:35:35 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 1495 - Improve message source fallback flow
Improve message source fallback flow
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.4.x
All All
: Low normal with 4 votes (vote)
: ---
Assigned To: Matt Walker
: i18n, testme
: 2036 8188 17107 17384 31305 33655 37949 (view as bug list)
Depends on: 46579
Blocks: 48956
  Show dependency treegraph
 
Reported: 2005-02-08 17:55 UTC by Brion Vibber
Modified: 2014-11-17 10:35 UTC (History)
18 users (show)

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


Attachments

Description Brion Vibber 2005-02-08 17:55:07 UTC
When a message fetched with wfMsg() is not defined *for the user's 
selected language* in either the MediaWiki: namespace (with language 
suffix) or the language file, the language class will fall back to the English-
language default in Language.php.

An example where this is problematic is customized menu items defined in 
$wgNavigationLinks; since they are not present in Language.php, an 
unsightly <message> is displayed.

It may be better behavior to fall back to the MediaWiki: copy. Probably the 
getMessage method should return false, and wfMsgReal can handle the 
fallback behavior.
Comment 1 Brion Vibber 2005-03-13 12:12:52 UTC
The special case of custom messages is now fixed.

For standard messages, it still goes to the English defaults for everything.
Comment 2 Angela 2005-06-15 16:05:26 UTC
*** Bug 2036 has been marked as a duplicate of this bug. ***
Comment 3 Laurence 'GreenReaper' Parry 2006-07-06 21:54:57 UTC
We made a Template:Sitenotice on furry to handle this issue.
Comment 4 Siebrand Mazeland 2009-02-07 23:35:23 UTC
*** Bug 17384 has been marked as a duplicate of this bug. ***
Comment 5 Niklas Laxström 2009-05-21 13:11:27 UTC
Is this a duplicate of bug 8188?
Comment 6 Chad H. 2009-12-15 10:59:37 UTC
*** Bug 8188 has been marked as a duplicate of this bug. ***
Comment 7 Siebrand Mazeland 2012-01-11 10:13:12 UTC
*** Bug 33655 has been marked as a duplicate of this bug. ***
Comment 8 Liangent 2012-08-14 18:37:01 UTC
*** Bug 17107 has been marked as a duplicate of this bug. ***
Comment 9 Liangent 2012-08-14 18:50:27 UTC
The current is (see MessageCache::get, if I read correctly):

* (if database is used:) Use page MediaWiki:<message name>/<requested language code> or MediaWiki:<message name> if $wgLanguageCode === <requested language code>
* Message from requested language object, which is: from PHP files in requested language and its fallbacks
* (if the message key contains a slash which is used to specify an alternative language code:) Message from the alternative language object, see above
* (if database is used and $wgLanguageCode !== <requested language code>) Use page MediaWiki:<message name>

There can be an extra source:

* (if database is used:) Use page MediaWiki:<message name>/<fallback language code of requested language>

But where should we put it?
Comment 10 Liangent 2012-08-14 18:50:57 UTC
The current is (see MessageCache::get, if I read correctly):

* (if database is used:) Use page MediaWiki:<message name>/<requested language code> or MediaWiki:<message name> if $wgLanguageCode === <requested language code>
* Message from requested language object, which is: from PHP files in requested language and its fallbacks
* (if the message key contains a slash which is used to specify an alternative language code:) Message from the alternative language object, see above
* (if database is used and $wgLanguageCode !== <requested language code>) Use page MediaWiki:<message name>

There can be an extra source:

* (if database is used:) Use page MediaWiki:<message name>/<fallback language code of requested language>

But where should we put it?
Comment 11 Liangent 2012-11-17 17:00:00 UTC
*** Bug 37949 has been marked as a duplicate of this bug. ***
Comment 12 Matt Walker 2013-01-16 07:54:35 UTC
Well, I started an initial attempt here. It has some performance issues still.

https://gerrit.wikimedia.org/r/#/c/44224/1
Comment 13 Matt Walker 2013-01-16 08:00:27 UTC
*** Bug 31305 has been marked as a duplicate of this bug. ***
Comment 14 Siebrand Mazeland 2013-03-07 15:24:06 UTC
Gerrit change #44224 being merged. Thanks for popping up 8 years after the bug was created, Matt!
Comment 15 Mormegil 2013-03-25 23:03:40 UTC
The change has one small problem (well, more, but let’s keep it simple for start): It does not include the site language itself in the fallback chain. Obviously, the problem appears only when the site language is not English, because English is included always as the fallback language of last resort.

But for non-English sites, we need to add it explicitly (Language::getFallbacksFor does not return it in the list), otherwise we do not see the modified messages in the local language at all.

Pushed to Gerrit as Ib607a446d3499a3c042dce408db5cbaf12fa9e3d
Comment 16 Mormegil 2013-03-25 23:33:20 UTC
Merged in commit 0f3d17edd4ef967930b31149123fabaef8276b59
Comment 17 Siebrand Mazeland 2013-03-26 22:47:47 UTC
This causes bug 46579.
Comment 18 Siebrand Mazeland 2013-03-28 10:38:42 UTC
Bug 46579 comment 19 explains why the current solution should be reverted now, and readded in an updated way once the needed rework is done.
Comment 19 Tyler Romeo 2013-03-28 21:09:27 UTC
Reopening since the change was reverted.
Comment 20 MF-Warburg 2013-04-04 08:04:30 UTC
Is there any chance to get this again? I must say I was quite enchanted by the chance which finally allowed me to see useful interface customizations (I'm mainly on meta & incubator) while having the rest of the interface in my native language. I don't understand the whining at bug 46579.
Comment 21 Nemo 2013-04-04 08:29:46 UTC
(In reply to comment #20)
> I don't understand the whining at bug 46579.

You answered yourself on why: you're speaking of Meta and Incubator, while en.wiki has an extended habit of customising things that probably shouldn't be customised (or at least should not according to those who complain).
Comment 22 MF-Warburg 2013-04-04 09:01:18 UTC
Mmmpfff. They should challenge enwiki customizations on enwiki then. Could the solution be to enable an option to not show any custom messages? (that way even the people who need to suffer under the evilness of en's customization who prefer en as their interface language can be helped!)

Sorry for the polemic, but it makes me facepalm that a bug fix that comes 8 years after the bug opening is reverted because some people disagree with enwiki MediaWiki: edits.
Comment 23 Tyler Romeo 2013-04-04 11:58:46 UTC
The issue with bug 46579 can be fixed by including the Language object check, i.e., $requestedLangObj->getMessage() inside the fallback chain check. If people want, I can pull the reverted patch, rework it to try and fix both bugs, and then re-push it. Should I do this?
Comment 24 MF-Warburg 2013-04-04 14:26:32 UTC
Of course, why would someone not want it? :)
Can you explain in which way the problem with bug 46579 would be solved then?
Comment 25 Tyler Romeo 2013-04-04 14:30:50 UTC
Well if you look at the patch, the issue was that it executed the following process:

* Check the DB for every language in the fallback
* Check the actual Language object

It was because of this that customized messages in fallback languages were taking precedence over default messages in the requested language object, thus leading to localization issues.

If we change the process to:

* Check the DB and then the Language object for each language in the fallback

Then the precedence becomes proper again.
Comment 26 Niklas Laxström 2013-04-04 15:30:18 UTC
(In reply to comment #25)
> If we change the process to:
> 
> * Check the DB and then the Language object for each language in the fallback
> 
> Then the precedence becomes proper again.

It's not that simple. Some times the wiki version (or translations of it) should take precedence of stock translations, sometimes not.

Another issue is that you cannot loop through l10n cache (what you call language object) per language. In the caches the whole fallback chain has been merged already, and you have no information of what language is returned. Fixing that is a project of its own.
Comment 27 Tyler Romeo 2013-04-04 15:49:51 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > If we change the process to:
> > 
> > * Check the DB and then the Language object for each language in the fallback
> > 
> > Then the precedence becomes proper again.
> 
> It's not that simple. Some times the wiki version (or translations of it)
> should take precedence of stock translations, sometimes not.
> 
> Another issue is that you cannot loop through l10n cache (what you call
> language object) per language. In the caches the whole fallback chain has
> been
> merged already, and you have no information of what language is returned.
> Fixing that is a project of its own.

How so? The current implementation right now is that there is no fallback chain. The issue with the gerrit change was that it inserted stuff midway in the process. I'm saying have the fallback chain actually be a fallback chain, i.e., it only uses it if it actually needs to fall back.

FWIW, here's what I got: https://gerrit.wikimedia.org/r/57518
Comment 28 Gerrit Notification Bot 2013-05-12 08:54:23 UTC
Related URL: https://gerrit.wikimedia.org/r/63365 (Gerrit Change I5ea8af299a14e052b265ebf9f21914ab0a4eb922)
Comment 29 Gerrit Notification Bot 2013-05-13 00:57:38 UTC
https://gerrit.wikimedia.org/r/63365 (Gerrit Change I5ea8af299a14e052b265ebf9f21914ab0a4eb922) | change APPROVED and MERGED [by jenkins-bot]
Comment 30 Nemo 2013-05-29 23:31:09 UTC
https://gerrit.wikimedia.org/r/#/c/57518/ was merged
Comment 31 Gerrit Notification Bot 2013-07-09 23:19:00 UTC
Change 72867 had a related patch set uploaded by Parent5446:
Complete usage of message fallback chain

https://gerrit.wikimedia.org/r/72867
Comment 32 Nemo 2014-01-06 22:03:44 UTC
For clarity, the current plan is Niklas' option 1 as per bug 46579 comment 17.
Comment 33 Tisza Gergő 2014-01-07 01:19:59 UTC
(In reply to comment #32)
> For clarity, the current plan is Niklas' option 1 as per bug 46579 comment
> 17.

Using [[MediaWiki:Foo]] for changes which are specific to the English language and [[MediaWiki:Foo/en]] for language-independent customizations seems totally counterintuitive to me.
Comment 34 Liangent 2014-01-07 09:33:15 UTC
(In reply to comment #33)
> (In reply to comment #32)
> > For clarity, the current plan is Niklas' option 1 as per bug 46579 comment
> > 17.
> 
> Using [[MediaWiki:Foo]] for changes which are specific to the English
> language
> and [[MediaWiki:Foo/en]] for language-independent customizations seems
> totally
> counterintuitive to me.

Huh I didn't follow these bugs closely but this is exactly what's being used somewhere: on zhwiki [[MediaWiki:Foo]] is for changes specific to zh and [[MediaWiki:Foo/zh]] is for zh and all its variants (a bot synchronizes message pages).
Comment 35 Nemo 2014-01-07 09:44:41 UTC
Multilingual wikis are also getting used to copying their customisations to language subpages since a few months ago per the plan above, e.g. [[m:Special:PrefixIndex/MediaWiki:sp-contributions-footer]] (though it's definitely not widespread yet).
Comment 36 MF-Warburg 2014-01-07 09:52:35 UTC
(In reply to comment #35)
> Multilingual wikis are also getting used to copying their customisations to
> language subpages since a few months ago per the plan above, e.g.
> [[m:Special:PrefixIndex/MediaWiki:sp-contributions-footer]] (though it's
> definitely not widespread yet).

Well, it's more an ugly hack to work around bug 48956 and this one, not really a solution.
Comment 37 Nemo 2014-01-07 09:54:21 UTC
(In reply to comment #36)
> Well, it's more an ugly hack to work around bug 48956 and this one, not
> really
> a solution.

Yep, the solution is fixing the bug. :D Once it's fixed, it needs to be properly documented and communicated.

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


Navigation
Links