Any change like this should be checked from accessibility standpoint. Easier solution would be to just revert the change in T301063: The "tag name" on the change line should link directly to "tagged changes" entirely.

In T326399#8504347, @stjn wrote:

Easier solution would be to just revert the change in T301063: The "tag name" on the change line should link directly to "tagged changes" entirely.

I agree! No thought has been put into

• (length of) tags in other languages
• look on mobile devices
• cluttered interface for RC patrollers

If not an outright reversal, it should be reduced to one letter (e.g. "→" or "+" in <sup>) and take advantage of <abbr> like the bot/minor/etc markers already do. The smaller font size just made matters worse, and the link having the boilerplate tooltip "Special:RecentChanges" also does not help.

Also note the original proposal in the wishlist survey was to link the labels themselves to recent changes and append "(help)" link if specified.

I was about to file another bug report, but here should be fine. On mobile, the tag markers apparently get a nowrap, which means that now some tags can cause overflow on small screens. I constantly see that now with tags like Bearbeitung von einer mobilen Anwendung (weitere Bearbeitungen) on dewiki. Maybe @Jdlrobson has an idea on how to better deal with these long tags on mobile.

Oh, and another problem: this leads to parentheses in parentheses, which according to German spelling rules cannot be of the same type. So the inner parentheses would have to be [ ]. Not sure how to change that on our side, I guess a different approach needs to be found.

I'm also not a fan of the links, but I don't want to suggest just removing them, since they were added in a response to a Community Wishlist request.

How about if we solved the problem by moving the links to a popup? It could also contain a short excerpt of the information shown on Special:Tags. Mockup for https://en.wikipedia.org/w/index.php?title=Talk:San_Francisco&action=history:

I could write a patch implementing this, if it seems like a good idea to anyone else.

Moving something to popups could be a solution. But please note that power users are prone to use Navigation Popups already, so the two should not interfere.

I feel like we're doing things here just because we can: adding more complexity where there are already decent solutons. Somewhere near the top of your screenshot, @matmarex, there's "Filter revisions" drop-down menu that does all this and more, without adding same, rarely used links to hundreds of listed changes.
As for the wishlist, I believe there are more people who oppose this change than there were supporters of it here.
This could be a javascript gadget for those few who really need it (right?), not something imposed on everyone by mw core.

I do like the idea of the popups, as the discussion on dewiki made clear to me that the entire display of tags (with or without the extra link) is seen as rather distracting. What about the mobile version though, would it be a mobile-friendly popup?

In T326399#8506766, @Ponor wrote:

I feel like we're doing things here just because we can: adding more complexity where there are already decent solutons. Somewhere near the top of your screenshot, @matmarex, there's "Filter revisions" drop-down menu that does all this and more, without adding same, rarely used links to hundreds of listed changes.
As for the wishlist, I believe there are more people who oppose this change than there were supporters of it here.
This could be a javascript gadget for those few who really need it (right?), not something imposed on everyone by mw core.

Completely agree. It also doesn't make sense and is of little use that the link takes you to recent changes, rather than filter the list you're currently looking at by the tag. No one asked for it in the form it was implemented in, so the next step should be to simply revert the change. Add it again only if someone comes up with a neat way that many can agree is an improvement. It wasn't a particularly popular wish (159th) anyway.

Yeah, ‘it was a CWS wish’ is not a good rationale because a lot of things are CWS wishes, it does not mean that they should be implemented. The proposer never explained where to put preexisting links to help pages, so the end-result had to adjust for what was technically unfeasible.

In T326399#8506570, @XanonymusX wrote:

Oh, and another problem: this leads to parentheses in parentheses, which according to German spelling rules cannot be of the same type. So the inner parentheses would have to be [ ]. Not sure how to change that on our side, I guess a different approach needs to be found.

Perhaps this could follow the styling on Minerva and have these tags as "pills" on a new line?

@Jdlrobson, please have mercy on patrollers, remove all this clutter and add nothing more. Imagine someone added those "pills" or any repetitive content after EVERY line of the code you write.

def lovely_function(page):
#Tags: Mobile edit (other edits) Mobile app edit (other edits) iOS app edit (other edits) canned edit summary (other edits)
   if page.isRedirectPage():
#Tags:Visual edit (other edits) Newcomer task (other edits) Newcomer task: copyedit (other edits)
            rdr = page.getRedirectTarget()
#Tags: Mobile edit (other edits) Mobile app edit (other edits) Android app edit (other edits)
            if rdr.isRedirectPage():
#Tags: Reply (other edits) Source (other edits)
                rdr = rdr.getRedirectTarget() #double redirects
#Tags: Mobile edit (other edits) Mobile web edit (other edits) Advanced mobile edit (other edits)
            to_that = rdr.title()
        else:
# Tags: Twinkle (other edits) Undo (other edits)
            to_that = "nothing"
            return to_that
#Tags: Mobile edit (other edits) Mobile app edit (other edits) iOS app edit (other edits) canned edit summary (other edits)

This is what we have to work with, hundreds of lines a day!

In the discussion in https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#%22Other_edits%22 it has been suggested to use "+" or "⇒" or many other unicode characters, it can be also simply be "more". I'd say let's talk to a designer about this. Would that address the concerns raised?

Imo, all of this has highlighted underlying problems with the display of tags in the watchlist. I’ll try to summarise them.

• In the discussion on dewiki, the usefulness of seeing the tags there at all has been questioned, as the tags tend to make single entries on the list unnecessarily long without much added value (except for filtering). For relatively trivial ones like mobile edit, I do understand the concern. This could be addressed with a preference (maybe a tickbox?) to make tags invisible in the watchlist. Otherwise, the proposed solution with mouseover could also be helpful here.
• On mobile, the “pills” look nice (imo), but they currently have a nowrap. Since the tags can get really long (especially now with the added link), this needs to change, otherwise you get overflow on small screens (my watchlist is broken since this change happened).
• On desktop, the tags are now put between brackets, which causes the above-mentioned problem with brackets within brackets. Using the same design as on mobile can be a solution, as long as the nowrap problem is addressed.

I'm bringing this up internally to find a better solution both for tags display and links.

I'm leaning towards reverting. While I think the idea of the popup makes sense, Commuity Tech does not the design/technical bandwidth to give this the holistic user-research and technical-research fix it deserves and mitigate the risk of clutter that any alternative non linked solution could introduce.

Given that this wish was 159 and it caused more friction than anticipated, and the wish was granted as part of a wishathon along with with many others, I think all we will be able to do is revert.

I do think that this conversation raised very valid and thoughtful approaches to how we handle tags and their UI and perhaps can form a strong proposal with more details, so if folks are interested, please do propose a new wish. The new CWS opens January 23, a mere week and a half away.

I sedond your suggestion. I just would like to add that if you should opt for a popup solution in the end could you please make it opt-in only? All such major changes to the user interface should be active opt-in, i.e. they should be switched off by default.

Change 879126 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view"

https://gerrit.wikimedia.org/r/879126

I'm going to revert the introduction of the links. I'll backport this to Wikimedia wikis later today.

The consensus in the discussion here and discussions elsewhere seems clear: when many tags are used, such as on Wikimedia wikis, these links take up more space than acceptable.

Perhaps the feature can be brought back in the future with a different design.

Change 879126 merged by jenkins-bot:

[mediawiki/core@master] Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view"

https://gerrit.wikimedia.org/r/879126

Change 879098 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@wmf/1.40.0-wmf.17] Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view"

https://gerrit.wikimedia.org/r/879098

Change 879099 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@wmf/1.40.0-wmf.18] Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view"

https://gerrit.wikimedia.org/r/879099

Change 879098 merged by jenkins-bot:

[mediawiki/core@wmf/1.40.0-wmf.17] Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view"

https://gerrit.wikimedia.org/r/879098

Change 879099 merged by jenkins-bot:

[mediawiki/core@wmf/1.40.0-wmf.18] Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view"

https://gerrit.wikimedia.org/r/879099

Mentioned in SAL (#wikimedia-operations) [2023-01-11T21:58:01Z] <kindrobot@deploy1002> Started scap: Backport for [[gerrit:878154|Fix exception in <gallery mode="slideshow"> with missing images]], [[gerrit:879100|Fix phan error when Excimer is enabled]], [[gerrit:879098|Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view" (T301063 T326399)]], [[gerrit:879099|Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view" (T301063

Mentioned in SAL (#wikimedia-operations) [2023-01-11T22:21:37Z] <kindrobot@deploy1002> kindrobot and matmarex: Backport for [[gerrit:878154|Fix exception in <gallery mode="slideshow"> with missing images]], [[gerrit:879100|Fix phan error when Excimer is enabled]], [[gerrit:879098|Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view" (T301063 T326399)]], [[gerrit:879099|Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view

Mentioned in SAL (#wikimedia-operations) [2023-01-11T22:38:06Z] <kindrobot@deploy1002> Finished scap: Backport for [[gerrit:878154|Fix exception in <gallery mode="slideshow"> with missing images]], [[gerrit:879100|Fix phan error when Excimer is enabled]], [[gerrit:879098|Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view" (T301063 T326399)]], [[gerrit:879099|Revert "ChangeTags: When showing a tag, also link to a filtered RecentChanges view" (T30106