Design had concerns with having a redirect at all because if there are any publishing errors, the user won't be able to read them before they redirect to the app. Would this happen? I was thinking the redirect wouldn't occur upon a publishing error (only upon success), so they'll be able to stay in mobile web and read the error.

We could build an initial set of behaviors from https://translatewiki.net/wiki/Special:Translations/MediaWiki:Colon-separator -- not using the message directly, but it does currently represent a list of all the languages that have not-just-a-space options.

In T315893#12126866, @Hakimi97 wrote:

is it hard to make " .mw-page-title-separator::after { content: ' '; }" configurable on language-by-language basis?

@Hakimi97 I think you're misunderstanding the technical side of this -- no change has been made to the URLs. They've always (well, for a long time) been flexible about accepting putting spaces around the :, but we haven't changed how we generate them or what we consider the canonical page URLs to be.

(Sorry for the slow reply, I was getting lunch.)

In T315893#12125567, @stjn wrote:

Ugh. [[Talk: Main Page]] is rendered as a blue link in MediaWiki. [[Wikipedia：首页]] is not. This conversation radicalised me about the need for a wide public vote on this matter much more than any single complaint did, because if this is the level of testing this decision is getting approached with, we should not rely on the WMF’s expertise on what’s better for us.

Currently things appear as “Talk: Main Page” in most languages. We have not seen a spate of complaints about redlinks to “Talk:_Main_Page”. So users are clearly not blindly linking things to whatever it looks like.

I understand what you're saying. I am saying that this does not appear to be a problem in practice, with a lot of evidence that this hypothetical problem has not materialized.

I'm inclined to think that if it was going to cause problems, we'd have seen it already from the discussion pages on those languages. We really do have years of this being deployed without any complaints of it causing issues for users.

Is the plan to redirect https://zh.wikipedia.org/wiki/Wikipedia：首页 to https://zh.wikipedia.org/wiki/Wikipedia:首页 once the downstream effects of this change would be felt by editors?

This is a clear instance where a global community vote should simply happen on whether this style should be present or not.

If you want a fun edge-case, checks and suggestions are mixed together when they overlap, with the gutter section-widget showing the icon for the highest-severity of its contents.

In terms of finishing this, resurrecting @matmarex's https://gerrit.wikimedia.org/r/c/mediawiki/core/+/825418 looks viable. It goes significantly further than the DiscussionTools implementation by exporting-and-using the colon-separator message, so wikis where adding a space wouldn't be typographically-correct will automatically cope with that.

I cannot reproduce this in Chrome on macOS (which should be at least quite close to the Chromium experience):

...there was explicitly a reason given in that ticket.

Ed's snippet above works now (and has for a while). Do we actually want anything else here?

Context: the maintenance script that emits edit_survived was created-and-merged back in April at the SDS offsite by @cjming and myself, and the patch I just attached is the config change required to actually turn it on. The main thing that needs to be done with said patch is tuning it to work out what the right interval to run it at is.

The !important has been there since the original version of this feature was merged back in 2022. I assume it was necessary for something at the time, but I've just tested without it in Vector, Vector-2022, and Monobook, and it doesn't seem to make any difference now.

First fix: a typo meant the image preview wasn't showing.

The main drawback here is that it's quite uncommon to have multi-language captions on commons. The system absolutely supports having loads of languages, but my experience is that most images will have either nothing or just English. It's probably worth providing it when that's present, but it's only occasionally actually going to work.

Mobile web VisualEditor wouldn't get TemplateWizard, it'd just get the standard VisualEditor template dialog. That'll happen whenever progress gets made on T388605+T385851.

The simplest general way to do this would be to return to our old behavior of not selecting anything when you click a suggestion in the sidebar, I think. That lets us dodge all sorts of state questions.

Adding a <poem> tag does fix this already, and doesn't seem like a particularly unreasonable way to set this up.

(I edited that to actually have a delete, rather than just notifying.)

Okay, given T422431's resolution, the following TextMatch rule works:

Do we store all suggestions for a page-revision as a single artifact, or is each artifact a list of suggestion types for a page?

(Unfortunately, based on my browsing experience with suggestion mode turned on, the ones that extensionless and API-less VE can get are also really uncommon.)

Hm! "as a thing in the data model", you mean VE's data model? Cite tells VE what a reference is? I know of work outside of VE for finding references in HTML that works outside of MW.

I'm curious, can you give an example of what knowledge from MW is needed to generate edit suggestions? I understand complexities of TextMatch so let's exclude that one.

@dchan Not sure that we care if it's identical, but if the count-of-edits differs between platforms at all regularly that's going to be problematic for us. The situation we really want to avoid is telling someone there's a suggestion available and then not having one to show them when they start editing, after all.

Note that the exact text searched for is very specific to the VE model, because it won't search within non-text things inside VE, and what HTML has become non-text is something we'd have to work out. (See also the whole unicode object replacement character being used to replace things inside the search, etc.)

In T403894 we made it so that you can create a redirect with an identical workflow to in source: type #redirect into a blank document. (Well, technically at the start of a paragraph.)

@Sdkb: the patch is a behavior-change, not a straight-up fix, so it's waiting on deciding whether the change is desired.

Per T430064, apparently the fix here doesn't work specifically for Firefox.

Seen events in the form: seen-id-{uuid}

I looked at the suggestions.csv in that directory, and the replacements seem to be correctly functioning. E.g.

I discovered this while backporting a change to a EditCheck that had to access an API hosted on api.wikimedia.org, which seems to be fundamentally untestable on the testservers as a result of this behavior.

Note that similar comments apply here to those I made on the promote-on-Minerva patch -- namely that this likely makes sense on talk pages, but that shouldn't be conflated with "pages on which the subscribe action is available".

Implies that the Cite extension isn’t being loaded, when the VE tests somewhat expect it to be available. (I’m surprised that this is the only test that failed, because other editcheck tests use mwReference as well….)

That one also covers the bookmark button, and I don't know whether the fixes that have been applied here affect it or not, so... sort of?

Context from T429633: this was rebroken by the ellipsis patch, and will be fixed by this follow-up which @Jdlrobson is reviewing today.

@Etonkovidova okay, should be fixed. Would you like to verify that it looks okay to you, or are the screenshots sufficient?

@AnneT this specific issue has both times been because Firefox and other browsers are treating the vertical positioning of the codex buttons in the toolbar 1px differently, so working out the root cause would definitely be a good idea.

This was rebroken by T429258.

T429258's changing of tools to an ellipsis icon has brought along making its hover state jut out from the bar's borders:

Okay, dug up a patchdemo from just after we started flagging all the model-generated ones this way:

Potentially fallout from T399175 adjusting all the icons. (Though I cannot completely remember it being tested with the old icon on mobile, so there's a chance it was always this way.)

This reference is: <ref>UNECE. (1996, December 31). Recommendation 9: Alphabetical code for the representation of currencies. (ECE/TRADE/203). United Nations. https://unece.org/trade/documents/alphabetical-code-representation-currencies</ref>. The test for whether the bare reference contained only a URL had a loophole -- because the URL wasn't linked, it was letting it through.

It's all embedded within BaseEditCheck's static doesConfigMatch at the moment. We *could* extract it, or at least split out the account-level bits into some top-level module with no dependencies.

We might need to coordinate with the model team to see how that "----" approach would work. It could impact the analysis, since they won't have trained on any content like that.