I will test this after patch of T279256 get deployed.

Maybe we should add more comments to define parameter type and provide document for ParserOutput so that phan and other CI tests can take part in.

In Change 675291, @Nikerabbit wrote:
From product perspective this should just work out of the box and not require any configuration.

The underlying cause, which makes Chinese not work here, is that none of the Chinese languages include zh in their fallbacks. Adding zh to their fallback chains should be a simple fix, assuming there aren't any negative side effects.

In Change 680687, @Umherirrender wrote:
Returning false with that value acts the same as returning true with a fatal Status?

Why this change? What does this change fix? Is there an error with the hook to fix?

If this is for the deprecation of the fatal Status usage here, that should be done with a deprecation cycles.

@daniel and @Pchelolo: I found you are authors of files under \tests\phpunit\data\ParserCache, could you please check this out? Thanks!

https://codesearch.wmcloud.org/extensions/?q=EditFilterMergedContent

This checkbox is enabled by Js.

I found there is oo-ui-fieldLayout-disabled class in the outer div, but the inputbox has aria-disabled="false" attitude.
Maybe a problem related to OOUI.

In T278658#6992034, @matej_suchanek wrote:

Very good idea! It seems not to break, but the form is now prefilled with -{ (not a big problem)...

In T278658#6991622, @Func wrote:

Oh, the problem is that title with big quote isn't a valid title, and unpaired big quotes broke the parsing process. Maybe we can check the title in lua module, with mw.title.new and check the return value...

Oh, the problem is that title with big quote isn't a valid title, and unpaired big quotes broke the parsing process. Maybe we can check the title in lua module, with mw.title.new and check the return value...

@hashar: Are there any problematic backend changes? The mediawiki-fresnel-patch-docker didn't work properly still.

13:12:57 INFO:quibble.commands:<<< Finish: User commands: mediawiki-fresnel-patch, in 52.834 s
13:12:57 INFO:backend.ChromeWebDriver:Terminating ChromeWebDriver
13:12:57 INFO:backend.PhpWebserver:Terminating PhpWebserver
13:12:57 INFO:backend.MySQL:Terminating MySQL
13:12:59 Traceback (most recent call last):
13:12:59   File "/usr/local/bin/quibble", line 11, in <module>
13:12:59     load_entry_point('quibble==0.0.46', 'console_scripts', 'quibble')()
13:12:59   File "/usr/local/lib/python3.5/dist-packages/quibble/cmd.py", line 639, in main
13:12:59     cmd.execute(plan, dry_run=args.dry_run)
13:12:59   File "/usr/local/lib/python3.5/dist-packages/quibble/cmd.py", line 402, in execute
13:12:59     quibble.commands.execute_command(command)
13:12:59   File "/usr/local/lib/python3.5/dist-packages/quibble/commands.py", line 22, in execute_command
13:12:59     command.execute()
13:12:59   File "/usr/local/lib/python3.5/dist-packages/quibble/commands.py", line 838, in execute
13:12:59     subprocess.check_call(cmd, shell=True, cwd=self.mw_install_path)
13:12:59   File "/usr/lib/python3.5/subprocess.py", line 271, in check_call
13:12:59     raise CalledProcessError(retcode, cmd)
13:12:59 subprocess.CalledProcessError: Command 'mediawiki-fresnel-patch' returned non-zero exit status 1
13:13:00 Build step 'Execute shell' marked build as failure

In T269341#6987805, @Func wrote:

Some warnings appeared on later changes, I found it related to this task.

23:19:51 Running "banana:core" (banana) task
23:19:57 >> 1 message lacks documentation in qqq.json.
23:19:57 >> Message "cant-block-nonexistent-page" lacks documentation in qqq.json.
23:19:57 Warning: Task "banana:core" failed. Use --force to continue.

Some warnings appeared on later changes, I found it related to this task.

23:19:51 Running "banana:core" (banana) task
23:19:57 >> 1 message lacks documentation in qqq.json.
23:19:57 >> Message "cant-block-nonexistent-page" lacks documentation in qqq.json.
23:19:57 Warning: Task "banana:core" failed. Use --force to continue.

In T278658#6952684, @matej_suchanek wrote:

Reopening because I don't know how to solve it locally (other than by reverting T263258 or even T132729).

I think because the fallback chains are mainly for system message and title lookup.
Chinese have two major scripts, zh-hans and zh-hant, there are many different character between them, so mediawiki maintained them in the center of fallback chains, and others(e.g. zh-hk) which slightly different from one of them can fallback to them.
Maybe according to population of zh-hans and zh-hant users, zh-hant and zh fallback to zh-hans.
So, message storage file of zh is empty, should't be a fallback target.
This fallback method works well in message display, but not fit for wiki subpages.

In fact users of almost all languages(variants) in $wgTranslateBlacklist (CommonSettings.php#2902) would face this problem.

https://gerrit.wikimedia.org/r/676291
Did this change make anything wrong with mediawiki-fresnel-patch-docker?
See: https://integration.wikimedia.org/ci/job/mediawiki-fresnel-patch-docker/37231/consoleFull

15:02:28 + find log/ -name '*trace.json' -exec gzip '{}' +
15:02:28 gzip: log/fresnel_records/before/scenario-View recent changes-run-3/trace--trace.json.gz: Permission denied
15:02:28 gzip: log/fresnel_records/before/scenario-View recent changes-run-5/trace--trace.json.gz: Permission denied
15:02:28 gzip: log/fresnel_records/before/scenario-View history of a page-run-3/trace--trace.json.gz: Permission denied
...
15:02:28 gzip: log/fresnel_records/after/scenario-Read a page-run-6/trace--trace.json.gz: Permission denied
15:02:28 gzip: log/fresnel_records/after/scenario-Read a page-run-4/trace--trace.json.gz: Permission denied
15:02:28 Build step 'Execute scripts' changed build result to FAILURE
15:02:28 Build step 'Execute scripts' marked build as failure

@matmarex Thanks! And would you like help to check the problem below?

In T273354#6806753, @Func wrote:

And maybe use $status->fatal() without returning false in this hook should be deprecated? There is a bug with this undocumented usage: T271037

Acording to codesearch, up to now, NO extension returning false will "display an error message on its own", so user can see nothing about their mistake.
See:

1. TranslateHooks.php#1153
2. NewsletterHooks.php#359
3. GadgetHooks.php#329
4. AkismetKlik.php#39

In T273354#6820315, @matmarex wrote:

After looking into it, I don't think the proposed change is correct… I believe that with the AS_HOOK_ERROR status, it's expected that your extension has already displayed an error message on its own. Changing it to AS_HOOK_ERROR_EXPECTED could break compatibility.

Haha, the patchset I created for T274122 can also solve this problem...Surprise...

In T273354#6805178, @matmarex wrote:

Can you explain what are the consequences of this change? What extensions are affected?