Improve message source fallback flow
OpenPublic

Description

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.


Version: 1.4.x
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=8960
https://bugzilla.wikimedia.org/show_bug.cgi?id=48956
https://bugzilla.wikimedia.org/show_bug.cgi?id=11267
https://bugzilla.wikimedia.org/show_bug.cgi?id=38662
https://bugzilla.wikimedia.org/show_bug.cgi?id=55473

bzimport set Reference to bz1495.
brion created this task.Via LegacyFeb 8 2005, 5:55 PM
brion added a comment.Via ConduitMar 13 2005, 12:12 PM

The special case of custom messages is now fixed.

For standard messages, it still goes to the English defaults for everything.

bzimport added a comment.Via ConduitJun 15 2005, 4:05 PM

beesley wrote:

*** Bug 2036 has been marked as a duplicate of this bug. ***

GreenReaper added a comment.Via ConduitJul 6 2006, 9:54 PM

We made a Template:Sitenotice on furry to handle this issue.

siebrand added a comment.Via ConduitFeb 7 2009, 11:35 PM
  • Bug 17384 has been marked as a duplicate of this bug. ***
Nikerabbit added a comment.Via ConduitMay 21 2009, 1:11 PM

Is this a duplicate of bug 8188?

demon added a comment.Via ConduitDec 15 2009, 10:59 AM
  • Bug 8188 has been marked as a duplicate of this bug. ***
siebrand added a comment.Via ConduitJan 11 2012, 10:13 AM
  • Bug 33655 has been marked as a duplicate of this bug. ***
liangent added a comment.Via ConduitAug 14 2012, 6:37 PM
  • Bug 17107 has been marked as a duplicate of this bug. ***
liangent added a comment.Via ConduitAug 14 2012, 6:50 PM

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?

liangent added a comment.Via ConduitAug 14 2012, 6:50 PM

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?

liangent added a comment.Via ConduitNov 17 2012, 5:00 PM
  • Bug 37949 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJan 16 2013, 7:54 AM

mwalker wrote:

Well, I started an initial attempt here. It has some performance issues still.

https://gerrit.wikimedia.org/r/#/c/44224/1

bzimport added a comment.Via ConduitJan 16 2013, 8:00 AM

mwalker wrote:

*** Bug 31305 has been marked as a duplicate of this bug. ***

siebrand added a comment.Via ConduitMar 7 2013, 3:24 PM

Gerrit 44224 being merged. Thanks for popping up 8 years after the bug was created, Matt!

Mormegil added a comment.Via ConduitMar 25 2013, 11:03 PM

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

siebrand added a comment.Via ConduitMar 26 2013, 10:47 PM

This causes bug 46579.

siebrand added a comment.Via ConduitMar 28 2013, 10:38 AM

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.

Parent5446 added a comment.Via ConduitMar 28 2013, 9:09 PM

Reopening since the change was reverted.

MF-Warburg added a comment.Via ConduitApr 4 2013, 8:04 AM

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.

Nemo_bis added a comment.Via ConduitApr 4 2013, 8:29 AM

(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).

MF-Warburg added a comment.Via ConduitApr 4 2013, 9:01 AM

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.

Parent5446 added a comment.Via ConduitApr 4 2013, 11:58 AM

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?

MF-Warburg added a comment.Via ConduitApr 4 2013, 2:26 PM

Of course, why would someone not want it? :)
Can you explain in which way the problem with bug 46579 would be solved then?

Parent5446 added a comment.Via ConduitApr 4 2013, 2:30 PM

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.

Nikerabbit added a comment.Via ConduitApr 4 2013, 3:30 PM

(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.

Parent5446 added a comment.Via ConduitApr 4 2013, 3:49 PM

(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

gerritbot added a comment.Via ConduitMay 12 2013, 8:54 AM

Related URL: https://gerrit.wikimedia.org/r/63365 (Gerrit Change I5ea8af299a14e052b265ebf9f21914ab0a4eb922)

gerritbot added a comment.Via ConduitMay 13 2013, 12:57 AM

https://gerrit.wikimedia.org/r/63365 (Gerrit Change I5ea8af299a14e052b265ebf9f21914ab0a4eb922) | change APPROVED and MERGED [by jenkins-bot]

gerritbot added a comment.Via ConduitJul 9 2013, 11:19 PM

Change 72867 had a related patch set uploaded by Parent5446:
Complete usage of message fallback chain

https://gerrit.wikimedia.org/r/72867

Nemo_bis added a comment.Via ConduitJan 6 2014, 10:03 PM

For clarity, the current plan is Niklas' option 1 as per bug 46579 comment 17.

Tgr added a comment.Via ConduitJan 7 2014, 1:19 AM

(In reply to comment #32)

For clarity, the current plan is Niklas' option 1 as per bug 46579 comment

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.

liangent added a comment.Via ConduitJan 7 2014, 9:33 AM

(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).

Nemo_bis added a comment.Via ConduitJan 7 2014, 9:44 AM

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).

MF-Warburg added a comment.Via ConduitJan 7 2014, 9:52 AM

(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.

Nemo_bis added a comment.Via ConduitJan 7 2014, 9:54 AM

(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.

Nemo_bis awarded a token.Via WebDec 12 2014, 8:04 AM
Nemo_bis added a project: Epic.Via WebJan 2 2015, 7:01 PM
Nemo_bis set Security to None.

Add Comment