General opinion from the Editing team:

1. If the pagination navigates among both suggestions and checks, then the previous format "x of y" made more sense, aligning it to the right (near the arrows) since the label is shorter.
2. Now, when navigating to next suggestion the highlighted text is so too high up, being too separate from the bottom sheet. It would be ideal if highlighted text could be more of less in the center of the screen, or near the bottom sheet without being part of the highlighted text behind.
3. When dismissing a suggestion right after using the pagination to navigate that suggestion, the scroll position still moves, losing the reference of that suggestion you were resolving.

1. hmmm, can you clarify: you'd like it to have both formats, depending on what's present (only suggestions vs both suggestions and checks)? or you want to go back to the previous format entirely...?

Ok, makes sense! I've updated the patch demo. All those are addressed except #4, which has been fixed in T432156.

Thank you, @bmartinezcalvo , I'll look at these.

George, thank you for the thorough testing!

@bmartinezcalvo , do you think you could review the patch demo when you get a chance?

Hey there, thanks! You can turn the beta feature on in Preferences > Beta Features > Suggestion Mode.

(My vote would be no, as advancing for some and not for others could be confusing to the user.)

Thank you!

No, because ignoreQuotedContent is the type of config that is meant to live on the broader check/suggestion level. It's just that for TextMatch we make them available on a matchRule level (because a matchRule essentially becomes a "check" of its own). These types of configs should live inside the config object of their respective check, so we keep it inside the config object of the matchRule for consistency.

Some questions as I implement this:

1. on mobile, when a user clicks edit on just a section, should the pagination be only throughout the suggestions in that section, or should it be throughout all suggestions in the article (and therefore open up full page editing if they navigate to a suggestion in another section)?
2. to confirm, there are no changes required on desktop?

@Wellverywell, @matej_suchanek - again, thanks for all the feedback!! It's really helping us make the documentation clear at the very least.

Of course! I've added a section to Edit Check/TextMatch just for regex specifics. I've included this and some of the other intricacies we've discussed on other tickets.

Thank you for the feedback and I'm sorry for the delay in my response!

Sure thing, sent.

Currently there's a 25 character limit for replacement previews, but I've got a patch to increase it to 100. The UI should be able to handle that fine.

Hi, I'm back, here's my public key:

Yes, that's the one, @Sfaci ! I've updated the description to reflect the correct original start date.

If there is at least one suggestion in the current section, and the user acts on all of them, should the 'View suggestions' button appear (assuming there are suggestions outside the section)?

In T407664#11905384, @Wellverywell wrote:

@medelius I tested RegExps for a bit. They are amazing! But I still found a few bugs, not sure whether in my edit checks or in the code.

1. \w doesn't capture Cyrillic letters. I think this is a JavaScript limitation, but still -- what should we do for this? Would \p{Script=Cyrillic} work (I don't know if EditCheck's RegExps use u flag) or should we use [а-яё] as right now? Both are significantly more verbose than just \w.

In T407664#11910430, @Wellverywell wrote:

My first feedback is that, I think, preserveCase should be true by default for replace rules.

@medelius Right now I also thought that it should be false for case-sensitive rules -- not sure if anything could break if not, but I think there are almost no cases where PC could be useful for case-sensitive patterns.

I've updated those examples. Thanks for pointing this out!

Sure thing! It's been added.

We've implemented regex support! I've updated the TextMatch documentation, but below is the most relevant information you'd need to start using the regex configs. Any feedback on this is appreciated.

Mikhail did a code review pass, so I think we could say that?

In T422931#11867284, @bmartinezcalvo wrote:

I've reviewed the implemented survey and these are some design details to fix:

1. Title text should use the heading style (18px size)
2. Use @background-color-base in the bottom sheet
3. The X button is not well aligned on top with the bottom sheet's title
4. Bottom sheet's paddings (right, left, top, bottom) should be 16px (now it's 12px)
5. The "Submit feedback" button is not visible

Implementation	Design (expected behavior)

Peter, it looks like it didn't ride the train last Monday. Not sure if there's a reason I'm missing there? There was no train last week, so you wouldn't see it on enwiki until Thursday, if that's where you're trying.

Sorry Peter, that still had dummy data on it. We're getting the data we expect now (2), and the graphs are updated and filters are at the top (1).