Feature suggestions and discussion [READ THE FIRST POST]

@kerinova  
[Tangent: The numbers displayed on tags should be considered best effort and probably do not have a future on the site.]

@byte[]  
…as in they’re scheduled for removal? I find them useful (even as simple estimates) to avoid following tags that will flood my watching list.

@Damaged  
Maybe have a way to allow description editing, along with history of edits like tags/source right now, but that might get badly abused.
 
 
@byte[]  
I hope that doesn’t get completely removed, since they were convenient to get a (very) rough estimate on how many pics exist with the tagged content.

@byte[]  
Can we at least keep ballpark figures? ie “around 50,000” or “over 1,000.”

@byte[]  
Wait, what the hell?! Don’t you dare to remove those numbers. Even if they’re slightly inaccurate sometimes.
 
Those numbers do have actual purposes, for example, when trying to determine which of the multiple possible tags is the correct one and which of the little-used tags should be removed/merged.

@byte[]  
*Gleefully getting ready to add a bunch of useless one-off tags, now that one one will be wiser*

@JP  

@The Smiling Pony  

Funny you said that just before torch-bearing crowds chanting for blood arrived, albeit for different reason.
 
@byte[]  
Can you elaborate how numbers on tags and number in the bottom are related to the actual number of matching images and what’s the problem of displaying the same number. I believe number on tags should be significantly faster to get, because there could be hundreds of tags on page. By why the error is getting so big, don’t you synchronize them from time to time? With total of ~414300 tags I guess it’s a lot of work to sync all of them often though.

@JP  
@cheezedoodle  

@JP  
@cheezedoodle  
@evan555alpha  

 
If you’re going to do it in some form, at least make it a toggle-able setting on the user-end. But don’t remove it as a whole.

@Brokedownandmadeone  

Yeah, I know they can be messy sometimes, even negative and stuff. But knowing the (sometimes rough) amount of images having a specific tag is nice, especially without needing a search query.  
I know your struggles with making them work as they should, but it is far better than nothing.

@kerinova  
My suspicion is that some of the problems stem from the counts displayed under the image are raw counts, while the actual number of results filters out deleted, merged, and tag-blocked images.

@Background Pony #99DE  
I’ve been thinking on this some more, and what if there was a 4th line in the tag drop-downs that have start|back|next|last buttons on it? Maybe even a random button in the middle?
 
Something like this:
 
It would of course just move forward or backward through the DB by ID number.

@Damaged  
Nice thing is that doesn’t even need anything more than a userscript to prototype, since it’s just URLs.

@Wellwater  
Right now this thing does something like this, but in more sophisticated way (initially designed to fix issues with navigation and, sadly, it’s still the main purpose for this thing to exist).

Removing the numbers on tags is daft, but adding a feature to them would be good. Namely, distinction between a tag that is at 0 images because it’s actually on 0 images and a tag at zero because it is aliased into something else. I.e. show (aliased) instead of (0) on alias’s secondary tags.

Can there please be a way to display the file dimensions of the fetched image? Sometimes, I grab the url of the smaller pics by accident, and only noticed it after upload. Something like  

@PUBLIQclopAccountant  

 
Deleted/Merged images aren’t counted among the tag count.  
The results from a search can vary from the listed tag count for a few reasons:  
Filters/search terms as you mentioned.  
The tag count being thrown off.  
The tag count being off happens a few different ways. One of which is if, say, two people were editing tags on an image at the same time. And both removed the same tag. Since the site counts that removal both times, it lowers the tag count by 2. Even though only 1 image had it removed.  
It also used to be that staff changing tags on deleted images would throw off the counts. But that has since been fixed.
 
We can re-set the number to match the given images. The only problem is that doesn’t work on the tags that are, say 15,000+.  
Though I hear that there’s a background fix in the works for that.
 
Anywho, I also agree that tag counts should remain displayed.

So, in the bug thread, I’ve just been taught that wildcard searches will include tag aliases in the pool of information from which to find results. Sayeth byte[]: “If any searches include aliases, all searches must include aliases.”
 
OK, just to get it out of the way, the obvious suggestion then is an option or “field selector” to search only images’ literal tags (or if the back end works the opposite way: search only unaliased tags).
 

 
But, what caused my original confusion is a relative lack of clarity. This leads me to several feature suggestions:
 
For example, when you search for a specific tag which is aliased to another, it says so and shows what it is on the search page. How about, an expandable section (like is already used for “Implied by”) which gives a list of all tags matched by a nonliteral search (eg. wildcard or fuzzy)? For bonus points, it could incorporate small explanations like “X because it is aliased from Y (which matches)” or “Y which aliases to X”.
 
Furthermore, on the image page itself, nothing indicates why it was a search result. Admittedly, it’s pretty self-evident for non-aliased tag matches and most if not all field searches, but still, a feature which highlights which tag(s) and/or field(s) matched the search would be cool. In particular, if an aliased tag is part of the match, it ought to be represented in the image’s list of tags (perhaps in the same way mentioned above, “X because it is aliased from Y [which matches]).  
This might be unfeasible since I know you can view an image and simultaneously have an irrelevant search parameter specified in the URL, ie. the search and the display of an image are not presently tied together on Derpibooru.
 
Finding what aliases direct to a tag is a little awkward, especially when starting from an image. I can click each tag on an image, and see what aliases for it are listed - which sounds like I’m just being lazy, and maybe so. 20 tags later and I’ve already somehow overlooked which one had the alias in my search, though… So, feature: you know the drop-down that has “Watch” and “Filter”? What about a sub-menu that has “Aliases”? And while I’m dreaming, how about “Implied by (on this image)”?
 
Even the Tags page makes things a bit obtuse. Like it says, “A wildcard is added at the beginning and the end” - so if I tried to use that page to accomplish suggestion #1, there are lots of cases where it will throw in unrelated tags since its search works differently. I understand why that was intended, and I’m not confident what to suggest otherwise: Omit the starting and ending wildcards if any wildcards are present in the search term? (That’s unintuitive.) Add a checkbox for “strict search”? (Interface clutter, although, not much.)
 
And to top it all off, the Aliases list is not itself actually searchable, or even alphabetically indexed. How about it?
 
OK, I’m done. tl;dr more upfront discoverability of information about aliases.
 

 
P.S. +1 for please to keep tag counts.

Perhaps open graph data could be added to the /tags/* endpoint?
 
Right now all image pages generate open graph data for easy embedding, but the only info tags give is the theme-color and a general site description.
 
Consider the safe tag for example. You could add an og:description for the short description of the tag, link the spoiler image as og:image, and use the tag’s name as the og:title.

Is there a find a mod/site overseer sort of feature? Because there’s one guy right now spam posting and I’m trying to get a mod or whatever they’re called and have run out of report tags and this guy is really out there

@Background Pony #81AE  
If you have issues with reports you can always contact mods by visiting the discord channel or the irc, we have channel specifically for helping users.

Why were the tag and source edits separated? I remember somemod gritting their teeth that it had taken so long to be implemented, so I assume it makes an image page better/faster/less bork-prone somehow, but… how, exactly?

@TexasUberAlles  
I think it was something to do with back-end streamlining and the very uncommon practice of the source ever being touched.