No longer getting this, so closing.

In T227766#5324739, @Legoktm wrote:

Is there a replacement target, or should it just be removed outright?

In T206613#5311274, @Smalyshev wrote:

I've reindexed testwikidata last week, the patch should already be there.

This is affecting Citoid as well, see T227415.

Looks like it's probably an IP range block, given it's also affecting sourcemd and toolforge tools, see: T226088

Which is to say, my response there on that thread was to the first comment, but not to the later report of the all of pubmed being down, as these are two separate issues- I should have read the whole thread instead of just the first message! Thanks for tagging this @Aklapper so it reached my attention again, definitely not good.

In T227415#5311732, @Aklapper wrote:

See the reply in https://www.mediawiki.org/w/index.php?title=Topic:V2pf99neqh2qupud&topic_showPostId=v2sd70b9r9165l32#flow-post-v2sd70b9r9165l32

We're going to try to deploy this first on test.wikidata, can this be reindexed as well? Or do they both get re-indexed at the same time?

I'm not sure whether to resolve or decline this as Research wasn't involved here :).

No worries; I wasn't aware the train was broken and wondered if the
reindexing had to be triggered manually or something, thanks for the update!

In T206613#5235476, @Smalyshev wrote:

Now after it's deployed reindex will be needed.

In T225064#5239356, @hashar wrote:

T224239 was for mobileapps and was originally titled: All mobileapps CI tests requiring external HTTP requests are throwing 504s which seems to indicate they had some test to exercise it and that it failed on patch proposal.
Can we investigate why the test failed on post merge but NOT when the patch has been proposed? I find that concerning. On https://gerrit.wikimedia.org/r/#/c/mediawiki/services/citoid/+/513975/ we had:

Zuul pipe	Status	Pipeline view	Legacy view
gate-and-submit	SUCCESS	service-pipeline-test #1890	https://integration.wikimedia.org/ci/job/service-pipeline-test/1890/
postmerge	FAILURE	service-pipeline-test-and-publish #209	https://integration.wikimedia.org/ci/job/service-pipeline-test-and-publish/209/

I have flagged both builds to be kept forever by Jenkins so we can investigate.

In T220415#5236246, @Lucas_Werkmeister_WMDE wrote:

Thanks for merging!

Also I should point out that using an indexed search is *much* better performance wise!

This has been "undeclined" and is resolved in T224004 - before deploying I was wondering if anyone knew of any adjustments made (.i.e. in bots) to strip out the leading PMC that returning it without the leading PMC would break? Otherwise I'll deploy it (relatively) shortly. I imagine such bots know what to do with the "correct" format anyway for user entered data.

What is the status of this?

Seconding, I just ran into this.

In T220415#5194765, @Lucas_Werkmeister_WMDE wrote:

Demo screenshot as of PS9:

In T208981#5193973, @Der_Keks wrote:

Just wanna ask if you could explain me the current status. I currently stuck on this problem while editing :)

In T223349#5191561, @matmarex wrote:

So there are two possible solutions:

1. The lazy one: Change the "cite-ve-othergroup-item" message to something less grammatically abhorrent, such as "Citation: $1" or "$1 (citation)".
2. The proper one: Add a separate message for each of the possible 6 options when it's used in the "Insert" menu rather than the "Cite" menu.

It's possible we can get rid of these messages entirely. It seems to be down to a config wgCiteVisualEditorOtherGroup = true, which I don't understand why we have at all. It might be a legacy thing we can get rid of?

In T222878#5171933, @cahyo.ramadhani wrote:

@Mvolz Ah, I see. I have added each template with TemplateData in the documentation. Could you please re-enable that so that I can try if it works?

The good news this only affects wikis with wgCiteVisualEditorOtherGroup = true, which as far as I can tell is only the case on mediawiki.org and not in any other wiki, including none of the Wikipedias.

@Esanders did this change recently I think?

Or perhaps we should have just refractored the existing keys in other
languages in the source...

Ah, that's not ideal - I'm afraid that's perhaps an issue with
translatewiki? Unfortunately it seems that if a key is changed, it's marked
for re-translation rather than moved.

They've just been renamed so they can just be copied over exactly... not
sure if that's what you're asking?

This is because it has been incorrectly configured; there is no template data in the cite web template. I've temporarily disabled it.

The cs1 module on en wiki recently changed to sniff these templates in the page. This is a better approach than doing it from inside ve anyway :).

Is there a way to at least disable the link on namespaces that aren't supported? It's pretty confusing to have the link there and have it be a dead link :).

In T98618#5135369, @Whatamidoing-WMF wrote:

So we'll end up with two systems:

1. The one currently on MediaWiki.org (no templates/no citoid/no nothing)
2. The one currently on most Wikipedias (templates+citoid) – the only difference being that for some of them, the "Automatic" tab will be grayed out.

Right?

In T98618#5135180, @Whatamidoing-WMF wrote:

We have three systems:

1. no templates
2. templates but no citoid
3. citoid

Will all of them move to this system?

Before change:
(Wikis with automatic tab disabled)

Ah never mind, looks like it'll make the cut without cherry picking?

In T216775#5093447, @Esanders wrote:

@Mvolz I've pushed this change to the test server.

Thanks!