Today

• No visible events.

Tomorrow

• No visible events.

Tuesday

• No visible events.

User Since

Oct 27 2014, 6:03 PM (596 w, 5 d)

Availability

Available

IRC Nick

edsanders

LDAP User

Esanders

MediaWiki User

ESanders (WMF) [ Global Accounts ]

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 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. -> 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.

Yeah - we then use the comment permalink which should track a comment even if it gets moved.

This could probably be done in TextMatchEditCheck with some improvements:

• Adding a regex mode (has been discussed in the past)
• Allowing more complex replacements, e.g. supporting a replacement map

In T418470#11709569, @bmartinezcalvo wrote:

We could use the question above the buttons (the one we use in Paste Check) to show the suggested word and ask the user to replace it.

👁 image.png (504×714 px, 122 KB)

Fixing T361737 would solve this, but we may want to come up with our own solution as you can't just scroll past the problem with checks.

I've added the remaining issues (button colour, button size) to T386388, and updated the demo.

If the user links to two usernames in their signature there is no way for us to tell which is the one they expect thanks to go to. DT does not use page history to determine comment authorship (that would not work on archived or moved discussions, for example).

This is a duplicate of T276510: Enable people to choose asterisk or colon for indentation on a per-comment basis and T263902: Enable Reply Tool to use context-specific indentation syntax

This is a limitation of Vector 2022 - there isn't a neat way to handle over-sized content. The same table overlaps the sidebar in read mode:

We do this in DiscussionTools where we set a body class - we just use the viewport height with a node that orientation changes might not work.

We need to create a generic way for VE to notify components when keyboard visibility changes.

@Esanders is the footer issue affecting both button position when it appears on top and at the bottom on desktop? If yes, we will need to solve this issue anyway for when the button would appear at the bottom (suggestions below)

I intentionally designed the button to remain in a fixed position,
...
The button should always appear within the container where suggestions appear,

This should be resolved once the caches clear - please re-open if that doesn't happen.

Ignored sections are configured here: https://nl.wikipedia.org/wiki/MediaWiki:Editcheck-config.json

This is the DT component, which is a slightly modified ButtonGroupWidget (just increased border radius):

In T414518#11745634, @DLynch wrote:

It also seems unnecessary, if the user has no interest in suggestions they can close the whole sidebar, otherwise the button can just be ignored as it takes up no additional space.

Agreed about desktop, but it does take up non-sidebar space on mobile. There it'll be hovering over content. And we're currently not giving a toggle for suggestions on mobile because of how otherwise unobtrusive the gutter is...

In implementing I'm comparing this to the "Reply to reply" feature in DiscussionTools and there are some technical reasons for the implementation details used there:

Verified on production.

I said the same thing when it was introduced. There was concern that people would be overwhelmed by notifications and not know how to turn them off.

You'd need to look at HTMLSelectField.php and how that builds the OOUI widget, but your patch seems reasonable...

To date:
Tone suggestions shown: 1.27k (compare to 24k for duplicateLink, 6k for missing image caption, 0.7k for broken heading levels)
Tone suggestions actons: 74 dismiss, 67 recheck, 63 edit (~5%)

The left alignment of display=block math is a local CSS rule to enwiki. This task, and the check would only apply to enwiki, or any wiki that adopts that convention.

I'm not sure the lightbulb rays are going to be worth the effort. In the real toolbar they make the icon look unbalanced in the space (shifted upwards).

The indentation is added to block math tags automatically using CSS. As mentioned above, this is now the recommended syntax for enwiki, per https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Mathematics#Using_LaTeX_markup

about introducing added steps to the publishing flow

This could be implemented as an EditCheck