Last modified: 2014-11-17 10:35:35 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.
The special case of custom messages is now fixed. For standard messages, it still goes to the English defaults for everything.
*** Bug 2036 has been marked as a duplicate of this bug. ***
We made a Template:Sitenotice on furry to handle this issue.
*** Bug 17384 has been marked as a duplicate of this bug. ***
Is this a duplicate of bug 8188?
*** Bug 8188 has been marked as a duplicate of this bug. ***
*** Bug 33655 has been marked as a duplicate of this bug. ***
*** Bug 17107 has been marked as a duplicate of this bug. ***
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?
*** Bug 37949 has been marked as a duplicate of this bug. ***
Well, I started an initial attempt here. It has some performance issues still. https://gerrit.wikimedia.org/r/#/c/44224/1
*** Bug 31305 has been marked as a duplicate of this bug. ***
Gerrit change #44224 being merged. Thanks for popping up 8 years after the bug was created, Matt!
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
Merged in commit 0f3d17edd4ef967930b31149123fabaef8276b59
This causes bug 46579.
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.
Reopening since the change was reverted.
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.
(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).
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.
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?
Of course, why would someone not want it? :) Can you explain in which way the problem with bug 46579 would be solved then?
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.
(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.
(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
Related URL: https://gerrit.wikimedia.org/r/63365 (Gerrit Change I5ea8af299a14e052b265ebf9f21914ab0a4eb922)
https://gerrit.wikimedia.org/r/63365 (Gerrit Change I5ea8af299a14e052b265ebf9f21914ab0a4eb922) | change APPROVED and MERGED [by jenkins-bot]
https://gerrit.wikimedia.org/r/#/c/57518/ was merged
Change 72867 had a related patch set uploaded by Parent5446: Complete usage of message fallback chain https://gerrit.wikimedia.org/r/72867
For clarity, the current plan is Niklas' option 1 as per bug 46579 comment 17.
(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.
(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).
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).
(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.
(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.
