My first reaction: this is a great, elegant idea, and I want to try to implement it.

The Mediawiki-Containers project is defunct.

If T15631: Wikimedia should become an OpenID provider is declined, there is no reason to develop the OpenID extension to support it. The extension also hasn't seen any real development in 9 years.

In T15631#6178955, @Tgr wrote:

OpenID has little support today. To some extent it has been replaced by OpenID Connect (not as a federated identity system, but at least as a standard method of proving your identity at a specific website). IMO we can decline this in favor of T254063: OAuth extension should support OpenID Connect.

@Mooeypoo gave some additional details on the team's decline of this wish on Meta:

Hello all. I'm the Technical Lead for the Community Tech team, and I thought I'd pitch in with an explanation that may answer some of the concerns raised in this conversation, in hopes to at least clarify the process that the team went through in making the decision.

I speak for myself and the team when I say that we share your disappointment about not being able to make PageTriage wiki-agnostic. While we had initial misgivings, due to the historical difficulties of this request, we went into the code with the genuine hope that we could prove this exercise doable. This type of work is part of the mission that drives the movement, the Foundation, and the team in specific, so we all wanted to see if we could make it happen. Unfortunately, we discovered very quickly that this is not the case.

PageTriage was written over six years ago with the goal of working with all wikis. However, due to time and resource limitations, the extension ended up being completed with only support for English Wikipedia's processes around the curation/review of articles and edits. This means two important results. First, the technology is old and difficult to work with, and some of it is no longer supported outside of our technical stack. Second, the entire architecture was written specifically to address the unique workflow of English Wikipedia's processes (from Article for Deletion, to how to notify users about reviews and potential problems).

The code was architected in such a way that these processes are built-in, inherently, into the deep operation of the system. We cannot easily untangle these operations while keeping the extension working. Every step of the process invokes actions that are English-wiki-process specific, and getting those out or allowing to disable them in other wikis (what we call "refactoring") ends up meaning rewriting the majority of the software. Further complexity is added in when we consider that the current technical implementation uses technology that is old and unsupported, which means it is almost impossible to add and edit features, as the code is written right now.

Unfortunately, we are not the first to discover this problem. The technical ticket is full of discussions about how this attempt could be done, along with several attempts made and abandoned by both staff and volunteer developers, due to these considerations.

We take great pride in producing the best solutions that help you, as the drivers of this extremely important process, to do this work with greater ease and support.

When we experience technical constraints, we try to propose a feasible alternative (like the current page views alternative). However, in the case of this request, we found ourselves continuously fighting against the stream. PageTriage is not an easy environment to add features to, and we have to balance the powerful results we want to give you with the technical feasibility of our efforts.

I hope this explanation sheds some light on this decision. Please feel free to examine the technical ticket, as it is the best place to discuss technical concerns and implications with the other technical experts in the movement and continue to strive and solve these issues.

I've tried to replicate this in Firefox (70.0b10) and Chrome (77.0.3865.90) on macOS (10.14.6).

This might be worth doing as part of the on-wiki communication improvements.

I can reproduce this on Firefox 70.0b5 on macOS 10.14.6 (but not on Chrome 77.0.3865.75). I imagine the priority is pretty low, though 🙂

I can't reproduce in Safari 12.1.12 on macOS 10.14.6; however, the description mentions Safari 7 on Mac.

In T168221#4311057, @Pginer-WMF wrote:

Content Translation version 2 already integrates Visual Editor editing surface. Although there are still tools to support and aspects to polish captured by other tickets, the main integration is working well. Thanks to everyone involved!

I can't reproduce this on Firefox 70.0b5 on Mac 10.14.6.

I just tested and was able to add a category on the Spanish Wikipedia using VisualEditor.

Actually, from T145710, it seems like this task was filed with the current interface in mind.

Although the button is still just labeled "delete", it is in the "table" context item and appears whenever any part of the table is selected, so hopefully it's now clearer that it applies to the whole table.

It seems like there's no interest in this specific feature any time soon.

In T232502#5480875, @matmarex wrote:

Thanks for the recording. The page looks weirdly narrow – do you have some browser extension or user script that does this? Maybe that is interfering with VE somehow?

In T121059#1876126, @Quiddity wrote:

I cannot reproduce in firefox 42 ubuntu, at my enwiki user sandbox, no matter what i try. I tried a few variations, as well as the exact sequence described, and either the browser-warning or VE discard edit warning will always appear, or just the character/element before the cursor is deleted. :-/

On second thought, the bug described here has been fixed.

Also, no template needs to be involved for this to happen.

Copying a single list item no longer "selects the bullet", so it simply pastes as normal text. This results in more intuitive behavior; for example, copying a list item and then pasting it into an empty list item just results in duplicating the same list item.

@matmarex thank you for checking. Maybe it's macOS specific?

I can't reproduce this on Firefox 70.0b5 or Chrome 76.0.3809.132 on macOS 10.14.6.

This seems like fairly bad breakage, so I'm proposing it as current work.

This task doesn't describe any specific problem, so it's not actionable, and we have MediaWiki-Page-deletion and MediaWiki-Revision-deletion for tracking deletion-related issues.

In T152442#2848384, @EBernhardson wrote:

it looks like this is getting a great score for full text matching, but is being discounted by 80% due to being in namespace 104. The configuration right now is that even though namespaces 0, 100 and 104 are content namespaces, 100 and 104 get an 80% discount to their score. This feature makes sense for pushing talk pages and such down, but not sure it's the right thing to do here. Will need to ponder.

In T987#2182906, @gabriel-wmde wrote:

Current status:

• The extension is in a repository at https://gerrit.wikimedia.org/r/mediawiki/extensions/Cognate

I've attempted to reproduce the two test cases in a sandbox on the Italian Wikipedia. In both cases (full and reduced), adding the section heading and references list worked correctly.

I checked all the affected articles listed by @Whatamidoing-WMF, and the templates in question can now be properly dragged.