Change #1147813 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Fix SharedDomainHookHandlerTest::testOnSiteNoticeBefore without WebAuthn

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

Change #1144564 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] cx_translations: Add index to make purging of unpublished draft faster

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

I'll let @Pginer-WMF evaluate the visual differences between the current state of the Compare content screen with the mock ups in this task.

Change #1143070 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] cx_translations: Add index to make fetching language trends faster

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

In T390072#10844726, @DLynch wrote:

@Ryasmeen Interesting -- it works perfectly fine for me in Chrome. Is it still not working for you there?

Change #1143062 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] cx_lists: Add index to make user suggestion fetching faster

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

In T392118#10845254, @cscott wrote:

"Extra update MedaiWiki jobs due to Wikifunctions content" will be the mediawiki_refreshlinks_parsercache_operations_total metric with status=cache_miss and has_async_content=true. This the total number of refresh links jobs with async content. If you look at the label async_not_ready=true then these are jobs which are going to need to be repeated once the async content is ready, and so they are "extra" update jobs. In addition, there will be a few extra update jobs with async_not_ready=false when entries fall out of the parser cache, do to the way we currently handle updating async content. So the range of "extra" jobs is between the lower bound of the # of jobs with async_not_ready=true and the upper bound of the # of jobs with has_async_content=true. We can refine this metric further if/when the upper bound gets close to our SLI limit.

Unfortunately, this metric is fixed at 0 right now because we don't use Parsoid to trigger refreshlinks jobs, only legacy parses. Since WF is Parsoid-only at the moment, WF can't affect page metadata and therefore there are currently no extra refreshlinksjobs being created for WF. This will change in the future though (T393716: RefreshLinksJob should use Parsoid-generated metadata).

"Extra update MedaiWiki jobs due to Wikifunctions content" will be the mediawiki_refreshlinks_parsercache_operations_total metric with status=cache_miss and has_async_content=true. This the total number of refresh links jobs with async content. If you look at the label async_not_ready=true then these are jobs which are going to need to be repeated once the async content is ready, and so they are "extra" update jobs. In addition, there will be a few extra update jobs with async_not_ready=false when entries fall out of the parser cache, do to the way we currently handle updating async content. So the range of "extra" jobs is between the lower bound of the # of jobs with async_not_ready=true and the upper bound of the # of jobs with has_async_content=true. We can refine this metric further if/when the upper bound gets close to our SLI limit.

Verified that limit report appears on https://de.wikipedia.org/wiki/Johanne_Karoline_Wilhelmine_Spazier

Change #1143050 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] cx_suggestions: Add index to make deletion by title and language faster

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

Added a patch to add 'href'.

Change #1148913 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Add `href` attribute to `<link rel="mw:PageProp/redirect">` in legacy parser

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

Currently
https://en.wikipedia.org/w/index.php?title=H2O&redirect=no&useparsoid=1 contains <link rel="mw:PageProp/redirect" href="./Water" id="mwAg"> and
https://en.wikipedia.org/w/index.php?title=H2O&redirect=no&useparsoid=0 contains <link rel="mw:PageProp/redirect"> I'm not sure why the href is missing?

Moving this to QA. Testing steps are in an earlier comment: T376315#10651771.

Huh, checking on iOS Safari right now, I experience the following:

@Ryasmeen Demonstration in Chrome: https://youtube.com/shorts/0sBtPfK3U3c

@Ryasmeen Interesting -- it works perfectly fine for me in Chrome. Is it still not working for you there?

@DLynch: oh, it works correctly on Safari but I checked on Chrome. Should it not work on Chrome as well?

Change #1148885 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/ConfirmEdit@master] tests: Skip AbuseFilter tests is AbuseFilter not installed

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

Works now, see https://wikidata.beta.wmflabs.org/wiki/Lexeme:L57547

Change #1146572 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Handle expiries in automatic global groups

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

Change #1143498 merged by jenkins-bot:

[mediawiki/core@master] In messages, make {{USERLANGUAGE}} always return the user's language

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

QA is completed, I have verified the new code has been implemented and is functioning as expected (Global Contributions count has been added to the IPInfo infobox).

Status: ✅ PASS
Environment: Prod
OS: macOS
Browser: Chrome
Device: MS