Page MenuHomePhabricator
Create Task
Maniphest T229992

Locally created fallback should take precedent over config fallback
Open, Needs TriagePublic
Actions

Description

zh-my, zh-sg, zh-mo, zh-tw, zh-cn, zh are no longer maintained as an interface language variant, thanks to the fallback scheme. currently maintained ones are: zh-hant zh-hans and zh-hk. It should be stressed although these are disabled, the existing have not been removed from the system, which cause maintenance overhead to downstream administrators. Suppose a system message have all the legacy variants set in mediawiki software, it means the interface administrator of a site need to create all the 8ish pages for a single message, which fallback to default mediawiki message instead of its fallback message on local instance.
So if MSG/zh-my and its identical MSG/zh-hans exist in mediawiki software, and the MSG/zh-hans is updated to use some templates maybe. MSG/zh-my needs to be created as well, otherwise it fallback to system message.

After further digging, it seems the problem exist because the read order seems to be MW:MSG/zh-sg, SYS:MSG/zh-sg, SYS:MSG/zh-hans, MW:MSG/zh-hans.
I would propose something like MW:MSG/zh-sg, SYS:MSG/zh-sg; MW:MSG/zh-hans; SYS:MSG/zh-hans. where SYS denotes default in config file, and MW denotes messages created locally in db.

Related Objects
Search...

Event Timeline

Viztor created this task.Aug 7 2019, 5:39 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 7 2019, 5:39 AM
Viztor renamed this task from Do not pull disabled language from translate.wiki to Do not pull disabled language from translatewiki.net.Aug 7 2019, 5:41 AM
Viztor updated the task description. (Show Details)
Viztor closed this task as Invalid.Aug 7 2019, 5:50 AM
Viztor renamed this task from Do not pull disabled language from translatewiki.net to Remove disabled language from i18n files.Aug 7 2019, 5:57 AM
Viztor reopened this task as Open.
Viztor updated the task description. (Show Details)

Though most messages don't seem have this problem, it still exist.

Viztor added a comment.EditedAug 7 2019, 6:11 AM

I'm not sure if language updater bot will add them back even if I delete them in a patch if these messages still exist on translatewiki

Viztor renamed this task from Remove disabled language from i18n files to Locally created fallback should take precedent over config fallback.Aug 7 2019, 6:52 AM
Viztor updated the task description. (Show Details)
Viztor updated the task description. (Show Details)
Aklapper edited projects, added MediaWiki-Internationalization; removed I18n.Aug 7 2019, 9:50 AM

Which system is meant in "have not been removed from the system"?

Viztor added a comment.Aug 7 2019, 3:50 PM
In T229992#5398803, @Aklapper wrote:

Which system is meant in "have not been removed from the system"?

I initially thought these messages still exist in the software, then I realize the software is written in a way where if you set a fallback, these message will still psudo-exist, even if they are not defined in that specific variation. So if SYS:MSG/zh-sg do not exist, but fallback is set to SYS:MSG/zh-hans, it seems the system still interprets it as if the message exist.
So it appears the fallback system is written in two place, one happens at reading MSG, one happens while reading default, which pseudo-create non-existent MSG/zh-sg using its fallback MSG/zh-hans.

Viztor added a comment.Aug 8 2019, 4:24 AM

This may also have caused T228876#5392631

Aklapper removed a project: Core Platform Team.Aug 8 2019, 11:25 AM
Aklapper added a subscriber: RazeSoldier.

@RazeSoldier: It's up to teams what they plan to have on their workboard, so I'm removing Core Platform Team again.

RazeSoldier added a comment.Aug 9 2019, 12:10 PM

Almost all interface messages are obtained via Message::fetchMessage(), it get real message from MessageCache::get().

The logical for MessageCache::getMessageForLang() (called by ::get()) display, first try to get the message from MediaWiki namespace, if it fails, check the CDB cache, and finally check the database for all of the fallback languages. This means that if the CDB cache exists, the fallback languages will never be used. But the logic of this method has not changed for a long time, I suspect the problem related to CDB cache.

gerritbot added a comment.Aug 9 2019, 12:37 PM

Change 529350 had a related patch set uploaded (by 星耀晨曦; owner: 星耀晨曦):
[mediawiki/core@master] [DO NOT MERGE] Debug for T229992

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

RazeSoldier added a comment.Aug 9 2019, 1:09 PM

I wrote a test to illustrate the situation. But the integration test results are very strange, the test fails under PHP and the test passes under HHVM.

Krinkle moved this task from Backlog to MessageCache on the MediaWiki-Cache board.Thu, Aug 29, 1:45 AM
RazeSoldier added a comment.Fri, Sep 13, 10:09 AM
In T229992#5405026, @RazeSoldier wrote:

I wrote a test to illustrate the situation. But the integration test results are very strange, the test fails under PHP and the test passes under HHVM.

According to my assumption, the CI test of the patch should fail. But the job under HHVM did not fail. I don't know what is causing this difference. But given that we are about to drop HHVM, we don't have to care about this difference. (although this difference is likely to be the cause for T228876)

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or 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