Page MenuHomePhabricator
Create Task
Maniphest T3495

Improve message source fallback flow
Open, LowPublic
Actions

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
See Also:
T10960: [Fallback language] MediaWiki:Key/en messages are ignored when en is the wiki default language
T50956: Can't override optional message in all languages with local customisation
T13267: User should be able to set fallback language(s) in preferences
T40662: Document how fallback language and message loading order in general works
T57473: i18n fallback uses message from i18n file before customized message from DB (MediaWiki: namespace)

Details

Reference
bz1495
TitleReferenceAuthorSource BranchDest Branch
Thank you, omnibus, for your service!repos/abstract-wiki/wikifunctions/function-evaluator!154apineapine-thank-you-omnibusmain
Provide Airflow metrics development environmentrepos/data-engineering/airflow-dags!549aquT349532_airflow_metricsmain
Add statsd as a dependency to our setuprepos/data-engineering/airflow-dags!537aquprovide_platform_agnostic_dependencies_listmain
pull up common filters (wiki-based, canary events)repos/search-platform/cirrus-streaming-updater!47pfischercommon-canary-handlingmain
jenkins-rel: remove GitHub pluginsrepos/releng/jenkins-deploy!44jnucheremove-github-pluginsmaster
Customize query in GitLab

Related Objects
Search...

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 21 2014, 8:13 PM
• bzimport added projects: MediaWiki-Internationalization, I18n, TestMe.
• bzimport set Reference to bz1495.
• brion created this task.Feb 8 2005, 5:55 PM
• brion added a comment.Mar 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.Jun 15 2005, 4:05 PM

beesley wrote:

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

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

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

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

Is this a duplicate of bug 8188?

• demon added a comment.Dec 15 2009, 10:59 AM
  • Bug 8188 has been marked as a duplicate of this bug. ***
siebrand added a comment.Jan 11 2012, 10:13 AM
  • Bug 33655 has been marked as a duplicate of this bug. ***
liangent added a comment.Aug 14 2012, 6:37 PM
  • Bug 17107 has been marked as a duplicate of this bug. ***
liangent added a comment.Aug 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.Aug 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.Nov 17 2012, 5:00 PM
  • Bug 37949 has been marked as a duplicate of this bug. ***
• bzimport added a comment.Jan 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.Jan 16 2013, 8:00 AM

mwalker wrote:

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

siebrand added a comment.Mar 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.Mar 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

Mormegil added a comment.Mar 25 2013, 11:33 PM

Merged in commit 0f3d17edd4ef967930b31149123fabaef8276b59

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

This causes bug 46579.

siebrand added a comment.Mar 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.Mar 28 2013, 9:09 PM

Reopening since the change was reverted.

MF-Warburg added a comment.Apr 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.Apr 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.Apr 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.Apr 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.Apr 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.Apr 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.Apr 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.Apr 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.May 12 2013, 8:54 AM

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

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

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

Nemo_bis added a comment.May 29 2013, 11:31 PM

https://gerrit.wikimedia.org/r/#/c/57518/ was merged

gerritbot added a comment.Jul 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.Jan 6 2014, 10:03 PM

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

Tgr added a comment.Jan 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.Jan 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

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.Jan 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.Jan 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.Jan 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.Dec 12 2014, 8:04 AM
Nemo_bis added a project: Epic.Jan 2 2015, 7:01 PM
Nemo_bis set Security to None.
He7d3r mentioned this in T50956: Can't override optional message in all languages with local customisation.Jun 27 2015, 9:45 PM
matej_suchanek updated the task description. (Show Details)Aug 11 2015, 7:16 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 11 2015, 7:16 AM
Antanana subscribed.Oct 2 2015, 10:03 PM
Nikerabbit mentioned this in T122712: Revert Engllish Wikisource to no differentiation between en/en-gb/en-ca mediawiki namespace messages and language settings.Jan 26 2016, 9:20 AM
Meno25 unsubscribed.Feb 22 2016, 5:47 PM
Umherirrender mentioned this in T134128: {{int:}} returns the English message rather than the default.May 6 2016, 3:36 PM
Danny_B merged a task: T134128: {{int:}} returns the English message rather than the default.May 6 2016, 7:24 PM
Danny_B added subscribers: Umherirrender, Danny_B, V111P.
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptMay 6 2016, 7:24 PM
matej_suchanek mentioned this in T13267: User should be able to set fallback language(s) in preferences.Aug 22 2016, 4:38 PM
Liuxinyu970226 mentioned this in T57473: i18n fallback uses message from i18n file before customized message from DB (MediaWiki: namespace).Jan 1 2017, 1:06 PM
Liuxinyu970226 mentioned this in T40662: Document how fallback language and message loading order in general works.Feb 10 2017, 6:50 AM
Liuxinyu970226 subscribed.
Umherirrender mentioned this in T183848: MediaWiki:Movepage-summary is not forced to content language.Jan 4 2018, 8:20 PM
Liuxinyu970226 awarded a token.Jan 6 2018, 10:32 AM
Tgr mentioned this in T188983: Special:Upload on Wikimedia Commons is unusable in languages in which MediaWiki:Licenses isn't explicitly translated.Mar 6 2018, 7:47 PM
Tgr mentioned this in T188822: Create fallback for MediaWiki:Licenses.Mar 6 2018, 9:24 PM
Steinsplitter awarded a token.Mar 7 2018, 1:10 PM
Steinsplitter subscribed.
Amire80 moved this task from Untriaged to Fallback on the I18n board.Mar 18 2018, 2:10 PM
Tgr mentioned this in T204018: fixcopyright wiki translations are missing some messages.Sep 11 2018, 6:45 AM
abian subscribed.Sep 11 2018, 11:34 AM
Tgr mentioned this in T205003: Improve translation workflow for sites with rapid language update needs.Sep 20 2018, 7:26 PM
Umherirrender unsubscribed.Feb 27 2021, 10:10 PM
MarioGom subscribed.Oct 28 2021, 2:13 PM
Pppery edited projects, added Patch-Needs-Improvement; removed Patch-For-Review, TestMe.Nov 5 2021, 4:56 PM
Winston_Sung merged a task: T39949: I need to set 3 times MediaWiki:Uploadtext when $wgLanguageCode = "zh";.Dec 27 2023, 5:37 PM
Winston_Sung added a subtask: T34971: Use language converter for converting system messages as fallback messages like Wikibase item labels.
Winston_Sung added subscribers: Zoglun, • wikibugs-l-list.
Winston_Sung subscribed.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL