Sep 11 2020
Nov 11 2019
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.
Sep 29 2019
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.
Sep 12 2019
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.
Sep 10 2019
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.
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.
Dec 13 2017
Dec 5 2016
Dec 1 2016
Nov 30 2016
Sep 3 2016
May 14 2016
Apr 21 2016
Oct 27 2015
Oct 7 2015
Sep 10 2015
Aug 26 2015
Aug 18 2015
May 11 2015
Feb 4 2015
Feb 3 2015
I checked all the affected articles listed by @Whatamidoing-WMF, and the templates in question can now be properly dragged.