Adding wmf-legal as suggested on the patch set

Git references in the i18n shims are not needed to fix, because the files should be removed, see T168353

Happen by the MediaWiki.Usage.ExtendClassUsage.FunctionVarUsage sniff - https://gerrit.wikimedia.org/r/#/c/301335/

See https://gerrit.wikimedia.org/r/#/c/170304/3/includes/specials/SpecialRandomInCategory.php for an example

In T153505#3416707, @Anomie wrote:

Only standalone &$this causes this warning in PHP 7.1, as far as I know. Constructs such as &$this->..., &$this[...], and &$this::... are fine.

You can download from https://www.mediawiki.org/wiki/Special:ExtensionDistributor/GoogleLogin
no need to install the extension on your own machine

Is this issue for standalone &$this or also for &$this->member ?

Scribunto is ready to load over extension.json after deployment of 1.30.0-wmf.8

I would say when the template does not automatically add a category it works.

New tracking categories has to be created, so you have still to supervision the newly created ones.

Another from yesterday:

[WV5L9wpAEK4AAEG3X9YAAACC] 2017-07-06 14:41:12: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBQueryError“

Two from yesterday

[WVjxggpAIDIAAF7OXrEAAAAK] 2017-07-02 13:13:54: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBQueryError“
[WVjx5ApAEKcAAFy1dIYAAAAT] 2017-07-02 13:15:32: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBQueryError“

It is possible to set args in the ruleset.xml as in phpcs.xml?

emailuser is used in navigation menu, the context is set to the user.

When the name of the user is not listed, it should be the neutral form.

Last fixes in https://gerrit.wikimedia.org/r/#/c/307103/

Would be nice to have a sniff for this to avoid adding new cases and to change extensions as needed.

This seems to be the reason why this sniff is disabled on mediawiki/core.

Not sure, but possible is:

list( , , $var )

Hint: LogFormatter is also used on Special:RecentChanges or Special:Watchlist to show log entries

Use el_to instead in the select list.

Than the default of disallowBlankTranslations in banana is wrong or not useful for use in mediawiki.

The upstream bug has some information, that this was already fixed in 3.17. The test is using 3.18.2.

There is only one change which affects the TOCEnabled in the list of changes to 1.30wmf.4[1] and that is in WikidataPageBanner[2]

In T168012#3360873, @cicalese wrote:

Is it possible for an admin to delete my draft change https://gerrit.wikimedia.org/r/359241 from the backend? I still cannot access that change, and I no longer need it since I created another change to replace it. I would like to have it removed from my list of open changes. Thanks!

on dewiki this is happen when a page is first created and than a page is imported under same name with older timestamps

Have found the following extension where the php entry point should be checked against extension.json and may removed, because it could be duplicate the config

Sounds for some pollution of the parser cache, because both have the same key, but storing different parser results.

Why you cannot output the newline in the lua module? Why is <br /> the only option? Add a new option to the lua module sounds easier than changing the mediawiki code (which can have side effects, when an file description contains <br/>)

There is a big different in syntax between a real newline and the html break <br />