Page MenuHomePhabricator

87: Show tags info
Closed, ResolvedPublic

Description

Follow up to T238300: 78: Show more info for edits

Parsed tags is declined, so I can either

  • Manually query to get the parsed versions of the tags
  • Show just the names

Related Objects

Event Timeline

Restricted Application added a project: User-DannyS712. · View Herald Transcript
DannyS712 renamed this task from 87: Show parsed tags info to 87: Show tags info.Dec 2 2019, 5:09 PM
DannyS712 changed the task status from Open to Stalled.
DannyS712 updated the task description. (Show Details)
DannyS712 added a subscriber: Masumrezarock100.

@Masumrezarock100 thoughts? Would parsing be helpful (at the cost of adding more api calls and slowing things down)?

How are you getting a tag info of a specific revision? I mean what is the API call url? I'd like to see how it's formatted.

How are you getting a tag info of a specific revision? I mean what is the API call url? I'd like to see how it's formatted.

It comes with the watchlist api - it would just be huggle instead of linking, etc

As shown in https://commons.wikimedia.org/wiki/Special:Tags, OAuth CID: 67 tag appears as OAuth Uploader (with the hyperlink intact). So which one would be shown in the global watchlist? the tag name or how it currently appears in RC/Watchlist?

As shown in https://commons.wikimedia.org/wiki/Special:Tags, OAuth CID: 67 tag appears as OAuth Uploader (with the hyperlink intact). So which one would be shown in the watchlist? the tag name or how it currently appears in RC/Watchlist?

The tag name, thats it

The tag name, thats it

I don't think that would be helpful. For example, Cat-a-lot tag for Cat-a-lot would be fine and users would understand it since the "tag name" is identical to how it appears in the watchlist/RC feed. But users likely would not understand that OAuth CID: 67 stands for OAuth Uploader (unless they read Special:Tags).

The tag name, thats it

I don't think that would be helpful. For example, Cat-a-lot tag for Cat-a-lot would be fine and users would understand it since the "tag name" is identical to how it appears in the watchlist/RC feed. But users likely would not understand that OAuth CID: 67 stands for OAuth Uploader (unless they read Special:Tags).

Maybe hard-code the OAuth CID tags? At least at first, to make it easier

The tag name, thats it

I don't think that would be helpful. For example, Cat-a-lot tag for Cat-a-lot would be fine and users would understand it since the "tag name" is identical to how it appears in the watchlist/RC feed. But users likely would not understand that OAuth CID: 67 stands for OAuth Uploader (unless they read Special:Tags).

Maybe hard-code the OAuth CID tags? At least at first, to make it easier

You mean showing OAuth Uploader instead of OAuth CID: 67? If so, would you keep the hyperlink?

The tag name, thats it

I don't think that would be helpful. For example, Cat-a-lot tag for Cat-a-lot would be fine and users would understand it since the "tag name" is identical to how it appears in the watchlist/RC feed. But users likely would not understand that OAuth CID: 67 stands for OAuth Uploader (unless they read Special:Tags).

Maybe hard-code the OAuth CID tags? At least at first, to make it easier

You mean showing OAuth Uploader instead of OAuth CID: 67? If so, would you keep the hyperlink?

I mean like the script remembering that
OAuth CID:67 = OAuth Uploader
OAuth CID:Foo = Bar
rather than checking each time. No links would be included

I mean like the script remembering that
OAuth CID:67 = OAuth Uploader
OAuth CID:Foo = Bar
rather than checking each time. No links would be included

I see. But what do you mean by "script remembers"? Where you would store it? In the script, or in a browser cookie?

If you are going to hard-code them in the script, it would take up some space and you'll have to update it everytime when someone adds a new OAuth application (kinda like the "adding new wikis to validation" situation).

If you are going to hard-code them in the script, it would take up some space and you'll have to update it everytime when someone adds a new OAuth application.

True... nevermind.

So now you have two options. Fetch the versions of tags how it appears in RC/Watchlist feed, then

  • Either strip off the all other things and extract the name (for tags that renders as links)
  • or simply convert it to html and serve it.

So now you have two options. Fetch the versions of tags how it appears in RC/Watchlist feed, then

  • Either strip off the all other things and extract the name (for tags that renders as links)
  • or simply convert it to html and serve it.

The watchlist API already returns the tag name - I'm not sure I understand what the first option is?

So now you have two options. Fetch the versions of tags how it appears in RC/Watchlist feed, then

  • Either strip off the all other things and extract the name (for tags that renders as links)
  • or simply convert it to html and serve it.

The watchlist API already returns the tag name - I'm not sure I understand what the first option is?

OAuth CID: 67 tag renders as [[Special:MyLanguage/Commons:OAuth_Uploader|OAuth Uploader]] (with the hyperlink intact) in the WL/RC feed page. By stripping off things, I mean remove the link and serve it as just OAuth Uploader.

So now you have two options. Fetch the versions of tags how it appears in RC/Watchlist feed, then

  • Either strip off the all other things and extract the name (for tags that renders as links)
  • or simply convert it to html and serve it.

The watchlist API already returns the tag name - I'm not sure I understand what the first option is?

OAuth CID: 67 tag renders as [[Special:MyLanguage/Commons:OAuth_Uploader|OAuth Uploader]] (with the hyperlink intact) in the WL/RC feed page. By stripping off things, I mean remove the link and serve it as only OAuth Uploader.

Oh - querying to see what the tag actually means returns the html (see https://commons.wikimedia.org/w/api.php?action=query&list=tags&tgprop=displayname&tglimit=max) - no need to convert anything

Cool. Then problem solved!

Okay. I started working on this. At first it'll just be the tag name (i.e. OAuth CID: 67) and then I'll add the parsed result when I get a chance

DannyS712 changed the task status from Stalled to Open.Dec 5 2019, 2:28 AM

Easier than I thought for parsed; done

How about linking to Special:Tags of that wiki, a user is currently viewing?

How about linking to Special:Tags of that wiki, a user is currently viewing?

Not sure thats needed, and there is already a lot going on...