I think step 0 here is to verify if we get reasonable accuracy for what Google would consider "smaller" text inputs, i.e. one sentence or paragraph.

I merged the patch as I can see a case where stop might be destructive (e.g. in a progress bar), but some concerns were raised on the task:

For the paragraph dropdown width, see T411252 which will make it fixed width.

https://gerrit.wikimedia.org/r/c/oojs/ui/+/1225557 accounts for viewport spacing, but this has never been implemented for the Vetor 2022 sticky header - it was only ever implmented for the MW debug bar.

Noting some slight deviations from the design comps:

We found many year links of the style "1997 in politics" or "2003 in sport". Without an understanding of linguistics, these are indistinguishable from "GeForce 5090" which could create an issue if linked like [[GeForce 5000 series|GeForce 5090]].

Likely caused T423437: Headings in mobile VE are missing padding

Is this a regression from T414882?

Related: T315658

As a performance note, this requires computing all suggestions (including expensive ones such as ToneCheck) for users who have turned suggestions off (and may have no intention of ever turning it on again).

We could either

1. Have an option we pass to mw.notify that says where we want the toast to render
2. Try to detect if the keyboard is up on mobile and reposition the toast accordingly.

1. Replace the edit handle with the corresponding mode icon (eye for VisualEditor, wikitext icon for Source) to better reflect the selected mode

I think in most cases users know which mode their in, in which case the primary function of the tool is to let users know there is a button for switching modes. There may be a better option than the pencil for this but I don't think the eye is an improvement.

I would prefer a floating redo button to having the toolbar re-arrange itself. As the user will have just pressed undo it means we are moving/resizing buttons underneath their finger. It would be possible for a user who is trying to click undo twice (or more) to accidentally press undo then redo even if they are tapping in the same place.

Questions:

• Do we want to show this to every user in the target group, or just a sample (e.g. 1 in 16)?
• Do we want to potentially show this to the same user twice?

Mobile toast appears at the bottom of the page. We can file a separate task to look into moving it up to avoid keyboard clash.

A couple of thoughts:

• The "Paragraph" tool is variable width, and so can be quite long, for example "Sub-heading 1" in Catalan is "Encapçalament de nivell 1", and we can't just truncate because the important information (the heading level) is often at the end.
• It may not be obvious that the menu is horiztonally scrollable, epsecially if it is truncated at the end of an icon (for example in the screenshot in the task).

In T420386#11789858, @bmartinezcalvo wrote:

but if the expected range is relatively low (e.g. ~20–30), using the 99+ would preserve the actual count without introducing confusion.

I think the only problem is accidentally showing it to users.

Deployed via path #2. The patch was merged but was not on this week's train.

• https://fr.wikipedia.org/w/index.php?title=MediaWiki%3AEditcheck-config.json&diff=234729919&oldid=234418337
• https://pt.wikipedia.org/w/index.php?title=MediaWiki:Editcheck-config.json&diff=72014850
• https://ja.wikipedia.org/w/index.php?title=MediaWiki%3AEditcheck-config.json&diff=109003822&oldid=96865575

Proceed with enabling Tone Check within Suggestion Mode by default

In T268935#11779280, @Physikerwelt wrote:

It could do eventually but for now we're keeping all the checks inside /editchecks as it's still in early development.

Ok. I would only think that making VE dependent on Math would not be good, as Math depends on VE already.

In T418470#11765882, @bmartinezcalvo wrote:

What about just Replace to match the question above?

The reason I haven't implemented frameless buttons is because in OOUI frameless buttons already have reduce horizontal padding, so it is not obvious how to adjust those (especially for small buttons).

In T268935#11777354, @Physikerwelt wrote:

@Christian1985 send an email to math user group https://lists.wikimedia.org/hyperkitty/list/math@lists.wikimedia.org/thread/LIDZOZIMMA6OXXXRH2UPZEKP2UJYELT6/

@Esanders I think the code looks good, but maybe it needs to go to the math extension?

Complex searches may also lead to the need for complex replacements, e.g. (cat)s? -> dog/dogs - or replacing a list of characters as in T412445

I've created two separate tasks and removed this parent task from the workboard.

Note there are lots of button variants to support too (icons, indicators, labels can all be turned on and off):

We can take a look, but in such a large library everything is more complex than in first seems. For example, buttons are not just used in ButtonWidgets, they are mixed into ButtonGroupWidget, ButtonInputWidget, ButtonSelectWidget, they are also used and modified in other widgets/layouts, e.g. ActionLayout (a text input with a button widget connected to it).

As we have given ourselves enough room for 2 characters ("9+") we could show counts 2 digit counts if we wanted. In cases of having to show "99+" the badge wouldn't look great, but that would be a rare edge case...

English will us "9+" instead of "+9" (Echo and Discussions tool have similar counters which use "99+"), but this be in the localised string so can change if necessary in other languages.

In T420268#11759862, @ppelberg wrote:

Drive-by comment to +1 the points @bmartinezcalvo thoughtfully laid out in T420268#11738854.

@Esanders: did you end up implementing the "rays of light" (that's fun to type out!) in this iteration? If not, can you please file a follow-on ticket for doing so?

1. Fixed
2. Surely close is not a progressive action? (Everywhere else we have a close button it is unflagged). I see it is next another button which is progressive but it would still feel odd to have it be progressive?
3. This looks like an issue with the "duplicate link" check and our scroll-into-view functionality (it is scrolling the actionable link which is the second link, but the card aligns with the first link) - we should fix this separately.
4. Due to the way things are currently wired up, it's quite difficult to re-order the scroll and reveal. We should file a follow-up task to cleanup the animation order.

No problem - I merged into T263902 as you were mostly talking about contextual indentation.