Add a drop-down list for the tags in Special:Newpages
Open, NormalPublic

Description

After an idea of [[:fr:User:Padawane]]¹ it would be great to add a drop-down list for the tags in Special:Recentchanges and Special:Newpages instead of an edit box. This would help users who don't know what are exactly the tags and users who use intensively the tags.

[[:fr:User:Dr Brains]] proposes to add two system messages to give the ability to the sysops of customizing the tags useful for Newpages and Recentchanges, possibly like the one in Special:Block.

¹ http://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Demande_d%27intervention_sur_un_message_syst%C3%A8me&oldid=59019598#Sp.C3.A9cial:Nouvelles_pages

The RecentChanges part of this is done in T161650: Replace "Tag filter" input with a dropdown+lookup widget in RCFilters.


See Also:
T23383: Suggest tags for tag filter at Special:Contributions, Special:NewPages, Special:RecentChanges, and Special:Log

Details

Reference
bz25909

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Oh, it doesn't actually query it (prolly not indexed)..

sumanah wrote:

Changing "reviewed" to "need-review" because MrBlueSky's new patch awaits review. Thanks for the patch!

In order to properly review this, I need to find out how to add tags before this change is made. Clues? point me to some docs?

(In reply to comment #12)

In order to properly review this, I need to find out how to add tags before
this change is made. Clues? point me to some docs?

Honestly, direct db manipulation is easiest way ;) . If you don't want to do that you need to install abuse filter, and make some filters that tag stuff (You should be able to steal filters from wikimedia wikis. MW.org has a filter that tags any edit adding ?> for example)

See also [[mw:Manual:Tags]] which isn't exactly high on details

btw, another possible way of doing this that comes to mind, is re-use the search drop-down suggestion code, and make suggestions while users type.

brion added a comment.Dec 16 2011, 9:31 PM

I'm a bit befuddled by this comment:

+ * @param $msgkey String: message key for the message which contains a (newline delimited)
+ * list of tags to put in the dropdown list. If the message contains no valid tags
+ * or doesn't exist the dropdown list is omitted and only a text field is created.

however in the function body, it also checks self::listDefinedTags() and if there aren't any in there, the list ends up empty.

Should it be combining these two lists, or filtering one by the other, or something else? It kinda looks like you have to hardcode the set of things that you can select in messages, of which there's at least two to maintain. What's the intention behind this?

Created attachment 9727
Tag against trunk

Oh, i'm sorry: that's an old comment which I should have changed.

If $wgUseTagFilter is false or there are no defined tags, no filter form is returned. Otherwise a textfield is created, and when the specified message contains text, a dropdown is created too.

There are indeed 2 messages for specifying the selectable tags, one for newpages and one for RC, history and contribs. This way admins can choose usefull tags (or to not have a dropdown menu at all). Another possibility would of course be to always put all defined tags in the dropdown but on some wikis (wp-en) this would result in a lot of clutter.

Attached:

Applied patch in r108850. Thanks for the patch!

Reverted as trunk is in code freeze for 1.19 release. Congrats on commit access MrBlueSky. Please review comments for r108850.

sumanah wrote:

MrBlueSky: Thanks again for the patch. Are you interested in updating it and using developer access to directly suggest it into our Git source control system?

https://www.mediawiki.org/wiki/Developer_access

https://www.mediawiki.org/wiki/Git/Workflow#How_to_submit_a_patch

  • Bug 25876 has been marked as a duplicate of this bug. ***

I have submitted a change (and abandoned) in Gerrit: [[gerrit change 4363]].

The problem with that implementation is that configuration has to be done using system messages, which is neither userfriendly nor flexible. It should have a nice GUI instead. But actually I think its better to create this functionally as a Javascript gadget, so the people who create and maintain the gadgets at a project can create something which fits the project. For example: on wp-nl, where I enabled such a gadget [1] we have only 7 labels (which almost never change), so a textfield isn't useful and a simple dropdown suffices.

[1] http://nl.wikipedia.org/wiki/MediaWiki:Gadget-labelfilter.js

gerrit change 4363

sumanah wrote:

The patchset was for "Dropdown for tags in rc, contribs, history and newpages".

Bartosz, would you be interested in taking this issue on?

I am currently waiting for somebody to review one of my own patches in gerrit, and nobody seems interested. I'm not sure if I will be able to without overburdening myself.

Anyway, what's the issue about now? Integrating the gadget into core? That seems like a bad idea, as it wouldn't be configurable, and retrieving the tags from the API on each call would be quite inefficient, if it's even possible. Or reviving MrBlueSky's changeset? I'm not the best person to do this, PHP is not my forte.

MrBlueSky / Seb35 / Krinkle:

(In reply to comment #24 by Matma.Rex)

Anyway, what's the issue about now? Integrating the gadget into core? That
seems like a bad idea, as it wouldn't be configurable, and retrieving the
tags from the API on each call would be quite inefficient, if it's even
possible. Or reviving MrBlueSky's changeset? I'm not the best person to do
this, PHP is not my forte.

This is a little more important now that VE is in beta – I think people often filter RC by the 'visualeditor' tag to look for breakage. The dropdown list should just use the same data that [[Special:Tags]] uses.

CC'ing James Forrester.

Sounds like a nice improvement.

Change 80781 had a related patch set uploaded by Matmarex:
Add a dropdown list for the tag selector

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

I don't know enough about this feature to weigh in intelligently, If the tag list is short a popup might be a reasonable option, however if it is long enough to require scrolling another solution might need to be arrived at.

The list includes all tags "maintained" by extensions (VisualEditor, MobileFrontend and GettingStarted use these, VE 2, the rest 1 each), as well as all active AbuseFilter tags (hopefully not more than a dozen or so, depending on the wiki). Should be acceptable for a dropdown list.

Will this dropdown menu be cluttered by inactive tags and tags from deleted filters (bug 18908)? E.g. the "link vandalism" from English Wikipedia, which is not used anymore:
https://en.wikipedia.org/wiki/Special:Tags

Helder, no, assuming I understand how this works. Special:Tags and this would use different methods - the special page shows all tags that were ever used, while the dropdown would only use the ones explicitly defined using the ListDefinedTags hook.

I asked Reedy to check this on en.wp and the total there is 40 active tags - a little long-ish for a dropdown, but manageable. It's surely shorter on saner wikis.

(For reference, en.wp's Special:Tags shows 90 tags right now.)

90 tags seems like too much for a popup. What about a form field or a combo box with type ahead.

It's 40 for the "popup" (actually a dropdown), 90 only on the special page.

HTML form dropdowns (<select>s) also support search-by-typing in all browsers I'm aware of.

40 or 90 feels overwhelming in a popup on some browsers that is going to take up the full height of the screen. Scrolling in popup can be very difficult for some users.

I think bug 48243 is almost a duplicate of this bug. A drop-down menu for tags seems silly. I'd suggest autocomplete (suggestions).

(In reply to comment #37)

I think bug 48243 is almost a duplicate of this bug. A drop-down menu for
tags seems silly. I'd suggest autocomplete (suggestions).

I disagree - autocomplete is great where the search-space is huge and rapidly-changing, but in a restricted (and externally-set, relatively-static) context, it's better to provide some form of latent discoverability than expect users to know what it might be called (or start with).

Created attachment 13275
jquery.chosen() applied to the tag selector dropdown

Maybe we could use jquery.chosen to get the best of both worlds (screenshot attached). The implementation would be trivial (on top of what I proposed it amounts to adding the jquery.chosen ResourceLoader module and calling $('.mw-tagfilter-input').chosen()).

I don't think this is used in core already, but it is definitely included and supported (some of the Labs management extensions use it, I believe, and support is integrated in HTMLForm as well).

(I'm leaning towards a simple select box myself, but this could be a compromise.)

Attached:

(The particular graphical elements it adds are almost all configurable, see the gallery at http://harvesthq.github.io/chosen/ .)

(In reply to comment #38)

I disagree - autocomplete is great where the search-space is huge and
rapidly-changing, but in a restricted (and externally-set, relatively-static)
context, it's better to provide some form of latent discoverability than
expect users to know what it might be called (or start with).

A full index (e.g., [[Special:Tags]]) allows users to browse through all tags (in the same way that [[Special:AllPages]] allows users to browse through all page titles). The solutions being proposed here seem short-sighted. While there may "only" be about 90 tags today (which is an overwhelming number in a drop-down menu), does anyone expect this number to stay relatively low or decrease in the future?

The reason autocomplete (or suggestions) are already used within MediaWiki for page titles apply to this input field as well. We should also note that Bugzilla itself uses an autocomplete/suggestions system for its keywords field. A drop-down menu seems like a non-starter to me.

To continue with the best of both worlds idea, why not supply the list of tags for the dropdown if the number of tags is lower than X, otherwise use only auto-completion API?

(In reply to comment #42)

To continue with the best of both worlds idea, why not supply the list of
tags
for the dropdown if the number of tags is lower than X, otherwise use only
auto-completion API?

Yes, we only need something to implement it. MatmaRex is right that we already use it successfully elsewhere: Rillke added it to Translate, for instance.

Change 80781 abandoned by Bartosz Dziewoński:
Add a dropdown list for the tag selector

Reason:
Needs to be done differently.

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

More reasons to first use autocompletion where possible: bug 64829 comment 8 on bug 21383.

TTO added a subscriber: TTO.Feb 4 2015, 12:19 PM

This should happen.

The issues I see are:

  • Performance. I have a suspicion the reason werdna used a free text field to begin with was because of the performance issues (there is no neat way of listing the tags without hitting the DB and running a bunch of hooks). I think this can be overcome by using memcached with a long expiry time (what's considered long? 1 hour? 1 day?).
  • Which tags to show. With the work on T20670 this is less of an issue - we can simply show all tags considered "active".
  • UI issues:
    • Personally I think a <select> dropdown with 80 or so items is fine, so long as they are sorted. However, emitting a HTML <select> and then applying jQuery Chosen to it is a good compromise. Hopefully it doesn't give rise to client-side JS performance issues.
    • We probably want to show the tags' friendly names (not code/internal names, which is what has to be used at the moment). But the friendly names are wikitext, so we would have to strip out links and such for display in a <select>. Not sure what exists in MediaWiki for doing that type of thing.

I was going to claim this task, but that last issue is kind of a blocker for me.

FYI, auto-suggestion/completion was requested in T23383.

(In reply to comment #37)

I think bug 48243 is almost a duplicate of this bug. A drop-down menu for
tags seems silly. I'd suggest autocomplete (suggestions).

I disagree - autocomplete is great where the search-space is huge and rapidly-changing, but in a restricted (and externally-set, relatively-static) context, it's better to provide some form of latent discoverability than expect users to know what it might be called (or start with).

If a user selects the tag input, couldn't we start displaying autosuggestions below with the first tags from Special:Tags ? At the end of the listing we could provide a link to Special:Tags, displayed as 'more tags'. Having to navigate a very long drop down menu isn't user friendly, smartphone contact lists use autosuggest to narrow down the displayed list for example.

In T27909#1014161, @TTO wrote:

The issues I see are:

  • Performance. I have a suspicion the reason werdna used a free text field to begin with was because of the performance issues (there is no neat way of listing the tags without hitting the DB and running a bunch of hooks). I think this can be overcome by using memcached with a long expiry time (what's considered long? 1 hour? 1 day?).

A few hours would probably do. But we can have a longer cache if it is cleared when performing management operations on tags. We may even have an action that purges this cache available for tag managers (since extensions might not clear the cache).

  • Which tags to show. With the work on T20670 this is less of an issue - we can simply show all tags considered "active".

Active tags may be too restrictive, since we may want to filter contribs, page histories or logs with no-longer-active tags. I'm slightly in favor of autosuggestion, listing all of the tags from Special:Tags, sorted by tag usage statistics (as cached).

  • UI issues:
    • Personally I think a <select> dropdown with 80 or so items is fine, so long as they are sorted. However, emitting a HTML <select> and then applying jQuery Chosen to it is a good compromise. Hopefully it doesn't give rise to client-side JS performance issues.

I would still favor autocompletion sorted by tag usage statistics.

  • We probably want to show the tags' friendly names (not code/internal names, which is what has to be used at the moment). But the friendly names are wikitext, so we would have to strip out links and such for display in a <select>. Not sure what exists in MediaWiki for doing that type of thing.

The solution is to make user friendly the tags' name themselves. They also appear at Special:Tags, having a different one for filtering would create more issues IMO. And this would also require changing the way the filtering occurs in many contexts (when appending &tagfliter=) to be compatible.

This seems like a perfect use for capsule input (you can see this currently in use with Hotcat, and in the category interface in VE)

Deskana removed a subscriber: Deskana.Mar 3 2015, 11:51 PM

This would require a distinct cache for tags that have been applied at least once. There should be a separate cache for tags that have never been applied, so that we don't have to hit the valid_tag table and the hooks just to get tags used at least once.

I also think that we should have a cache for each tag hitcount instead of one for all of them. This way, we just increment the hitcount cache for added tags (the incr function is built in memcache and very fast), instead of purging the whole thing.

We could have a cache of 24 hours. Operations on the valid_tag table would purge the cache. AbuseFilter should also purge the cache when a filter including a tag action is updated, and other extensions that cannot wait 24 hours to see it defined at Special:Tags.

Does that sound good ? I could rewrite the tag usage statistics function for this. Capsule input sounds good, but it looks like it uses javascript, I don't know enough about that to implement it.

I've uploaded a patch set for T91535.
This creates in particular a list of tags applied at least once, cached for 24 hours, that can be further filtered by 'active' or 'problem' status.
I'd suggest no extra filtering for logs and histories, 'active' filtering for Special:RecentChanges, and 'problem' filtering for Special:ProblemChanges.

Change 211497 had a related patch set uploaded (by Cenarium):
Drop down menu for selecting tags

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

Does this task cover everything in T23383? Maybe it can be closed as duplicate.

matej_suchanek set Security to None.

Does this task cover everything in T23383? Maybe it can be closed as duplicate.

In https://gerrit.wikimedia.org/r/#/c/211497/, I've implemented a basic html drop down. I think people were concerned with the high number of tags on some wikis.
The possibility to exclude tags from the drop down (by entering an empty appearance) mitigates this concern greatly (tags with few hits or very old but non-deletable could be hidden).

We might leave T23383 open for a while in case people aren't satisfied with a drop down and still want a suggest form or some fancy javascript. If a simple drop down turns out to be enough, then we'll close it.

Restricted Application added subscribers: TerraCodes, Luke081515. · View Herald TranscriptApr 30 2016, 10:16 AM

Change 211497 had a related patch set uploaded (by Cenarium):
Drop down menu for selecting tags

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

How will this work in combination with T105189?

https://gerrit.wikimedia.org/r/#/c/218265 ensures that the issues of T105189 will not occur by providing a new cache.
Besides that, I don't think that there is interaction between RTRC and the drop down menus added here.

matej_suchanek removed a subscriber: wikibugs-l-list.
Krinkle removed a subscriber: Krinkle.Jul 15 2017, 4:05 AM
Restricted Application added a project: Growth-Team. · View Herald TranscriptAug 14 2018, 7:09 PM
Catrope moved this task from Inbox to To Triage on the Growth-Team board.Aug 20 2018, 10:56 PM
kostajh added a subscriber: kostajh.

Growth team discussed this today in our triage meeting. The Special:RecentChanges page has this feature now, although Special:Newpages does not. Our team won't have the capacity to work on a patch for Special:Newpages but volunteer contributions would be very welcome.

kostajh renamed this task from Add a drop-down list for the tags in Recentchanges and Newpages to Add a drop-down list for the tags in Special:Newpages.Tue, Sep 18, 7:49 PM