Verified

In T333709#9267084, @ppelberg wrote:

Started a conversation on mw:Talk:Edit check: https://www.mediawiki.org/wiki/Talk:Edit_check#How_should_we_evaluate_this_project?

It might be useful for people to get a sense for the activity of a page if we also showed at least the "X people are commenting"

I've applied my own fix with @disksance 's blessing and things appear to be working now.

This still sets an href, it just sets the href to the current page. Now click on OOUI tools reload the page. The fix to the library (https://github.com/wikimedia-gadgets/VariantAlly/pull/5) should cause it to skip over non-href <a> tags.

Appears to the VariantAlly script: https://github.com/wikimedia-gadgets/VariantAlly/issues/4

We generally don't enable VE on talk namespaces, as it doesn't support indented discussion threads well. One can still add ?veaction=edit to the URL to force the visual editor to load.

I've moved 11 of the remaining 37 pages, but the other 26 will require someone with more rights across all wikis.

May have been fixed since T312558. Is this still broken @Ponor ?

That is T52881. While that would make fragment linking easier, this task argues that a specific tool for quickly linking to sections of the page you are talking about would be helpful tool.

I looked into this a bit, and the problem isn't the year is 0 (both our PHP and JS timestamp libraries support the non-existent year 0).

so that comment with invalid timestamps can be replied to

^ core patch has broken DT headings:

In T338534#9227853, @Tacsipacsi wrote:

I don’t agree. What users can and cannot thank should be a product/design decision informed by technical possibilities, not a purely technical decision.

You will also need to inherit wikimedia/jsdoc instead of wikimedia/jsduck in eslintrc.

Thanks, done.

Clarifying what this patch does:

• Applies to anyone who has visual enhancements enabled (either via the beta feature (which exposes the new preference as enabled by default), the A/B test on certain wikis, or by being on mobile where enhancements are always enabled)
• Enables visual enhancements whenver the __NEWSECTIONLINK__ marker is present (as opposed to only in talk namespaces)
• However this does not apply in the article namespace, unless the article namespace is in wgExtraSignatureNamespaces (such as on mediawiki.org)
  • This prevents our styling ever applying to Wikipedia articles, even if a user accidentally adds the marker to that page.

You can override the gutter with this user CSS:

.client-js .mw-editform #wpTextbox1 {
  margin-left: 0;
  width: 100%;
}

In T351487#9342421, @Nardog wrote:

Who benefits from this?

Anyone switching between highlighting and not highlighting. It also removes the jitter while CodeMirror is loading, which was the original reason for the change. Any fix would add even more complexity for little benefit.

Presumably just limiting the patch to fixed width Vector 2022, and leaving as-is in other situations, would be fine (an improvement on the status quo)?

3 & 4 are fixed. 1 is more complicated as it requires more interaction between VE and this core component (VE needs to override the list of available sections, rather than use an API call). I think that should probably be fixed later.

Thanks for the feedback.
1 sounds useful and should be fixable.
I think points 2-3 can be addressed later in follow ups.
4 should be fixed, we should replace underscores when normalising.
5: if you start typing # immediately you get no page name. Removing the page name could arguably be a Parsoid job, or something we should leave in if the user types it explicitly, but we could remove it locally.

I would call this a feature. When toggling between plain and code height the content will not jump and reflow, and you won't lose your place.

DT mobile is deployed everywhere.

Note that we disable clipping in CSS in this widget:

.ve-ui-completionWidget .oo-ui-popupWidget-body {
	/* The contained MenuSelectWidget is already clipped (T330401) */
	/* TODO: This could be done in JS if OO.ui.ClippableElement provided a way to disable clipping */
	overflow: hidden !important; /* stylelint-disable-line declaration-no-important */
}

Looks like this is caused by scrollbar-gutter: stable.

I assumed this was related to https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/966217 but that hasn't been merged yet...

Testing with diff_match_patch.prototype.diff_cleanupSemanticLossless = function() {} in the console, output looks reasonable again:

Caused by teleport changes?

Thanks for bringing it to our attention.

After:

Fixed by https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/969952/2

We could also consider IndexedDB which has a much larger quota.

Could be a duplicate of T350032

IIRC we make sure only one notification is sent in this situation. I don't think we need to complicate the interface with this logic when the extra mention is harmless. Arguably it keeps the user in the good habit of mentioning people they want to ensure get notified.

Wiktionary don't use mw-collapsible for their boxes, but a custom gadget https://en.wiktionary.org/wiki/MediaWiki:Gadget-defaultVisibilityToggles.js. This task is about fixing an on-wiki gadget to use the correct hooks.

Example output:

This would be fixed by T331635

I wrote a script to search the current codebase for existing messages, either in the code or documentation:

T324354 may be related

Looks like the differ is detecting a DefinitionList changing to a List (numbered or bullet), but our description code can't handle that. Not sure if we should consider definition lists as comparable to bullet/numbered lists or not...

The heading is labelled with "Moved down" when it was actually moved up

Could be T202719

See also T242999

snap

Regression caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/857542 (cc @matmarex)

This is clearly not happening regularly, and I can't reproduce it, but it seems likely related to wrapper paragraph logic. We did change this recently to fix a similar bug (T348467), but there is an instance form 2022 that pre-dates this.

From T349871:

In T349653#9285683, @Jack_who_built_the_house wrote:

(Currently a fragment with random characters gives a notification "This comment could not be found. It might have been deleted or moved." – is that expected? Also maybe unsuccessful lookup should be reflected in the notification text as well.)

CC @SD0001 & @Jack_who_built_the_house

Demo: https://patchdemo.wmflabs.org/wikis/fd311f2936/wiki/Talk:DiscussionTools#Where_to_post_SQL_requests

However, it might be worth seeing if there's anything out there that this might cause issues for first...