Hey all,

I know everyone is starting to riot over the string of disambiguations getting rejected, and that's totally fair.

The short of it is that they are just more work than we can sustain as the site continues to grow and we continue to add more. Disambiguations didn't turn out to be the silver bullet we had hoped for. We are going to be more selective in which tags truly need disambiguations, and which ones can be aliased to the more common term and accept a low number of mistags for the less common term. Users will also have a better idea of what happened if their search yields an obvious alternate definition of the term, rather than just no results at all (as is the case if the disambiguation is cleared out).

Cleanup is needed either way, but this will hopefully give the best searchability for the most users. We have reached the point where our tags need to be easier to use for average users, even if that means they are not technically correct all the time.

Here's how it's going to work going forward, as it pertains to disambiguations in particular.

Disambiguations are going to be used on tags that are frequently intermixed with each other. If one tag is nearly solely used over the others, then it will receive an alias instead. If it's obvious that one meaning is what people have come here for, then it will also likely receive an alias or manual cleanup. The big point is that disambiguating a tag will mean a lot of ongoing work for that tag with poor searchability, and should be a last resort if no other solution will work. Character names will likely stay the exception to this, as names are not something that have different meanings for the same word.

Before a disambiguation is accepted, wikis need to be filled out for each page. Aliasing it to a disambiguation, only for a user to click on it and be drop kicked to an empty page isn't going to work. You don't need to fill out the wikis before suggesting the disambiguation! Suggest it, get a thumbs up, make wikis, it gets approved.

I know this is far from ideal, but the current method isn't working. The current amount of disambiguations isn't manageable. Most of them have no wikis at all. The first dozen or so have hundreds of posts still under them and detailed wikis. This means that despite the clear instructions they are still not being used by casuals. Power users and staff just can't keep up with them. There are still a bunch of pending ones too, like gum, Eiffel tower, fern, and grotesque. It's obvious users are trying to find candy, French monuments, plants with too many chromosomes, and well, grotesque scenes and themes.

We are always open to suggestions and feedback. If you can think of something that's sustainable as we become a larger site and aids searchability, let us know. I give serious consideration to everything people send my way.

Please (respectfully) post all questions, comments, bitches, gripes, and complaints below.

rainbow_dash said:
Prime example: someone searches for foxes in pools. They type in fox pool and are met with a few mistagged posts. The user is unsure what went wrong and assumes that either this is all our site had, or that they messed up the search and don't know how to fix it. A smart user will click the question mark next to pool and find that it's been disambiguated, then eventually track down swimming_pool and fix their search. Most users never make it that far. They obviously meant swimming pool but didn't think it needed to be that specific, or what exactly to type in. This is an example that someone brought me earlier this week and I had to walk them through how to check for these. This is far from the first time.

It's a shame that you took the exact wrong lesson from the example you were presented with.

The fault here is not with the tag pool for being ambiguous, but the fact that this is not being clearly communicated to the user.

You mentioned in the scenario the requirement for an unfamiliar user to click on a tiny little question mark in a non-obvious place in order to find out what they did wrong. You didn't mention that the question mark, or any other link to the wiki page, will not exist at all if the results have been fully cleaned, or that the posts page provides no visual indication other than an unexplained colour difference that a tag was invalid.

It's no wonder a user has no idea what's going on if the site doesn't tell them!

Why is the search string itself the only reference provided for which tags were searched for? Why do we put no effort into explaining the alias system at the precise point where its effects are most visible? Remember when femdom was temporarily between aliases and the forums suddenly got flooded with angry casuals convinced we were censoring the site? Why, in this scenario, is the hapless user not informed at any point what exactly it is they did wrong, and preferably how to correct it?

You nearly get to the root of the problem by accident in this paragraph:

rainbow_dash said:
I know this is far from ideal, but the current method isn't working. The current amount of disambiguations isn't manageable. Most of them have no wikis at all. The first dozen or so have hundreds of posts still under them and detailed wikis. This means that despite the clear instructions they are still not being used by casuals.

I've long felt that the visibility of the wiki ought to be increased in general, because the tiny little question marks which are nearly physically impossible to click on some devices are clearly not cutting it. We repeat the mantra of "read the wiki if you need help" to misbehaving taggers all the time, but where's the onboarding process for that? How many casual users, even those who have made tag edits, even know we have a wiki?

We don't even do the bare minimum to prevent invalid tags from being used, like, say, actually preventing them from being used. This would be trivial to implement on the uploading and editing pages and solve the problem literally overnight. We might as well not have a concept of invalid tags at all for all the deterrent they've been.

For an example of your new philosophy in practice, consider my most recent disambiguation request. The alias to tit_(bird) was created in topic #10081 using pretty much the exact logic you describe:

user_59725 said:
It's not commonly tagged anyways, and the mistags are easy enough to spot.

And here we are, 7 years later, with a huge backlog of mistags exacerbated by the fact that the incorrect tag now comes with multiple equally incorrect implications which you have to remember to remove as well.

Is this the future for other tags?

TLDR: Problem: Users use the site incorrectly. Correct solution: Teach users how to use the site correctly. Incorrect solution: Make the site work incorrectly.

wat8548 said:
The fault here is not with the tag pool for being ambiguous, but the fact that this is not being clearly communicated to the user.

Wait, if there's a disambiguation tag why doesn't pool alias there?

I'm back from my shower and I remembered some old feature requests of mine that would go a long way to fixing this while I was in there.

topic #31443: Probably the most important suggestion on this list, and practically a requirement if you ever want those disambiguation wiki pages to actually be written. Searching up the original justification for something like saurian_(disambiguation) is pain.

topic #34341: Can't stop people adding invalid tags if the tags aren't bloody invalid.

topic #34241: The last time I begged for an automated tag verification feature, which would include "no invalid tags" as its most obvious test.

Also, if character tags are indeed going to continue to be an exception, why is Soren an exception to the exception?

rainbow_dash said:
Prime example: someone searches for foxes in pools. They type in fox pool and are met with a few mistagged posts. The user is unsure what went wrong and assumes that either this is all our site had, or that they messed up the search and don't know how to fix it. A smart user will click the question mark next to pool and find that it's been disambiguated, then eventually track down swimming_pool and fix their search. Most users never make it that far. They obviously meant swimming pool but didn't think it needed to be that specific, or what exactly to type in. This is an example that someone brought me earlier this week and I had to walk them through how to check for these. This is far from the first time.

I feel like the solution to this would be to create the tag pool_(swimming) and have that aliased to swimming_pool so that the correct tag would show up at/near the top of the autocomplete when typing "pool" into the search/tag edit, not throw away the idea of disambiguation.

magnuseffect said:
Wait, if there's a disambiguation tag why doesn't pool alias there?

Because it was deleted, apparently. Anyone know when or why?

wat8548 said:
Because it was deleted, apparently. Anyone know when or why?

The when is probably 4 days ago, when just pool started being added to posts again after 7 years of non-use: https://e621.net/post_versions?commit=Search&search%5Bexclude_uploads%5D=0&search%5Btags_added%5D=pool

rainbow_dash said:
Hey all,

I know everyone is starting to riot over the string of disambiguations getting rejected, and that's totally fair.

The short of it is that they are just more work than we can sustain as the site continues to grow and we continue to add more. Disambiguations didn't turn out to be the silver bullet we had hoped for. We are going to be more selective in which tags truly need disambiguations, and which ones can be aliased to the more common term and accept a low number of mistags for the less common term. Users will also have a better idea of what happened if their search yields an obvious alternate definition of the term, rather than just no results at all (as is the case if the disambiguation is cleared out).

Cleanup is needed either way, but this will hopefully give the best searchability for the most users. We have reached the point where our tags need to be easier to use for average users, even if that means they are not technically correct all the time.

The long version

As you no doubt have also seen we are attempting to clear out the current tag queue that is about 6 years behind. As much as we'd like to give each request its due process, we really need to catch it up so that current ones aren't being neglected for months or years, and so we can give them due process. We can't just mass approve them, and we decided against mass rejecting them, so that leaves us with going through and being a lot more rejection heavy until the queue is under control. If the request is not rock solid then there's a high chance it'll be rejected instead of workshopped via lengthy discussion. This is by no means the ideal scenario, but currently requests are not being fulfilled at all!

Our site was much smaller and easier to maintain when we came up with this idea. It was a half decent idea, but it just didn't scale to where we are now. The number of disambiguations has exploded in recent years. Currently we have thousands of these tags and only so many power users and staff that can and will clean them out. It is actually starting to hinder users' ability to search and blacklist.

Prime example: someone searches for foxes in pools. They type in fox pool and are met with a few mistagged posts. The user is unsure what went wrong and assumes that either this is all our site had, or that they messed up the search and don't know how to fix it. A smart user will click the question mark next to pool and find that it's been disambiguated, then eventually track down swimming_pool and fix their search. Most users never make it that far. They obviously meant swimming pool but didn't think it needed to be that specific, or what exactly to type in. This is an example that someone brought me earlier this week and I had to walk them through how to check for these. This is far from the first time.

Now say a user wanted to find images of foxes playing pool. Most would probably type in fox pool_table and get half decent results. Pool table has been aliased to billiards table (no big deal) and all of these results are also tagged with billiards. In this case they found what they were looking for. If they tried fox pool they would be greeted with results of foxes in swimming pools. It would be obvious what the problem was; wrong type of pool. They may try a few different terms to fix the search and may or may not find it, but at least they would know what part of the search didn't work rather than no results (if cleaned) or 2-3 results (if not cleaned).

Fluid pools, puddles, and seascapes have other terms that users are more likely to start with. Those that are very familiar with our nuanced tagging of urine puddles don't need the extra help.

All situations need tagging work. Without the disambiguation though the greatest number of users have the best chances at finding what they need. It's not the path with no damage, it's the path with the least.

Here's how it's going to work going forward, as it pertains to disambiguations in particular.

Disambiguations are going to be used on tags that are frequently intermixed with each other. If one tag is nearly solely used over the others, then it will receive an alias instead. If it's obvious that one meaning is what people have come here for, then it will also likely receive an alias or manual cleanup. The big point is that disambiguating a tag will mean a lot of ongoing work for that tag with poor searchability, and should be a last resort if no other solution will work. Character names will likely stay the exception to this, as names are not something that have different meanings for the same word.

Before a disambiguation is accepted, wikis need to be filled out for each page. Aliasing it to a disambiguation, only for a user to click on it and be drop kicked to an empty page isn't going to work. You don't need to fill out the wikis before suggesting the disambiguation! Suggest it, get a thumbs up, make wikis, it gets approved.

I know this is far from ideal, but the current method isn't working. The current amount of disambiguations isn't manageable. Most of them have no wikis at all. The first dozen or so have hundreds of posts still under them and detailed wikis. This means that despite the clear instructions they are still not being used by casuals. Power users and staff just can't keep up with them. There are still a bunch of pending ones too, like gum, Eiffel tower, fern, and grotesque. It's obvious users are trying to find candy, French monuments, plants with too many chromosomes, and well, grotesque scenes and themes.

We are always open to suggestions and feedback. If you can think of something that's sustainable as we become a larger site and aids searchability, let us know. I give serious consideration to everything people send my way.

Please (respectfully) post all questions, comments, bitches, gripes, and complaints below.

what exactly does this solve?

furrypickle said:
The when is probably 4 days ago, when just pool started being added to posts again after 7 years of non-use: https://e621.net/post_versions?commit=Search&search%5Bexclude_uploads%5D=0&search%5Btags_added%5D=pool

Oops, I accidentally disambiguated all of them. Guess the hypothetical noob is shit outta luck now :3

There could be a big link to the wiki on the top of the search page, if someone tried searching for a tag with the _(disambiguation) suffix.
This would at least help to find the wiki.

You tried searching for "pool_(disambiguation)", have a look at the wiki.

I know there's problems here, especially with the user searchability side of this, but I really feel like this is a half-measure that's not actually going to fix the issue and introduce other ones instead.

rainbow_dash said:
I know this is far from ideal, but the current method isn't working. The current amount of disambiguations isn't manageable. Most of them have no wikis at all. The first dozen or so have hundreds of posts still under them and detailed wikis. This means that despite the clear instructions they are still not being used by casuals. Power users and staff just can't keep up with them. There are still a bunch of pending ones too, like gum, Eiffel tower, fern, and grotesque. It's obvious users are trying to find candy, French monuments, plants with too many chromosomes, and well, grotesque scenes and themes.

I don't believe that nobody can keep up with them - I just think that nobody is keeping up with them. The backlog is only at about 6000-something posts, and I've removed hundreds of disambiguation tags in a day before. It takes about 1-2 weeks on average for 100 posts to be uploaded, meaning it's probably about an hour of work to undo a few weeks of mistagging. Tags having a few hundred posts? Not a big deal at all. Are we forgetting tags like bow_(disambiguation) and others once had more posts needing disambiguation than the entire remaining disambiguation queue at the moment? I was planning on halving the entire queue today to prove a point but ended up busy, maybe still going to make an attempt at doing something today though.

wat8548 said:
Oops, I accidentally disambiguated all of them. Guess the hypothetical noob is shit outta luck now :3

So... we've now got a pool tag... which isn't swimming_pool or billiards... so it's just a disambiguation tag without the (disambiguation) suffix. Glad we could fix the disambiguation problem here.

wat8548 said:
...
The fault here is not with the tag pool for being ambiguous, but the fact that this is not being clearly communicated to the user.

You mentioned in the scenario the requirement for an unfamiliar user to click on a tiny little question mark in a non-obvious place in order to find out what they did wrong. You didn't mention that the question mark, or any other link to the wiki page, will not exist at all if the results have been fully cleaned, or that the posts page provides no visual indication other than an unexplained colour difference that a tag was invalid.

It's no wonder a user has no idea what's going on if the site doesn't tell them!
...

dubsthefox said:
There could be a big link to the wiki on the top of the search page, if someone tried searching for a tag with the _(disambiguation) suffix.
This would at least help to find the wiki.

You tried searching for "pool_(disambiguation)", have a look at the wiki.

This is really the best solution - no matter what route we take for disambiguation tags. I asked for this a long time ago (with the old site code I think, back when Parasprite was the lead developer) and I was told it was impossible to add. I really don't see why not. It's probably overkill for the system and too difficult to implement but something like the way Wolfram|Alpha handles it would probably be the ideal solution.

This certainly comes across as sweeping the problem under the rug, it won't fix anything and will in fact make the problem worse. Disambiguation tags are there for a reason, because there are some words/tags that are ambiguous and people searching it for one thing will find a bunch of other things they don't want (and be missing many posts since most of them will hopefully be correctly tagged and not use the ambiguous tag). The disambiguation tag conveys "hey, this isn't right, try something better". If people can't realize something's wrong when the tags they search for end up as _(disambiguation), then either the site needs to better communicate the issue, or we need to realize some people will be confused no matter what we do. But removing the disambiguation isn't going to fix the problem, such a tag will still be a jumbled mess of different meanings that still needs to be cleaned up into better separate tags. Further, those of us that actually do pay attention will have less information to do a better job. When I post an image with a pool, for example, I'll think to tag pool. I'll then see that's aliased to pool_(disambiguation) and know to use a better tag. Now, however, I'll see that pool is a "valid" tag and not realize it's more ambiguous than I thought. Additionally, someone looking at the image will see it's tagged pool and not realize there's an issue that could be fixed.

So not only does this not fix anything, leaving ambiguous tags just as ambiguous and incomplete, which makes it useless for searching, it's making it worse since those of us who try to tag better and try to fix tagging issues will be less able to, and conveys less information to a user about a problem when they try to use it. The problem currently facing dock and pool and the like is just going to spread, not get better.

I agree that the problem isn't the existence of *_(disambiguation) tags, but that the people don't know that it exists, or that it is a problem to use them. Or we handle like we do it with the stripes and spots tags which can be used on fur, furniture, clothes, etc.

dubsthefox said:
There could be a big link to the wiki on the top of the search page, if someone tried searching for a tag with the _(disambiguation) suffix.
This would at least help to find the wiki.

You tried searching for "pool_(disambiguation)", have a look at the wiki.

More generally, since _(disambiguation) tags are supposed to be in the Invalid category, we could make it so searching for any Invalid tag will pop up such a warning (it may also help deter people from using an invalid tag as though it were valid despite it being in the invalid category).

Although it deviates a little from the main point of this topic, the person who first tagged (contributor) dislikes aliases (for example, drake → dragon) and intentionally adds _(disambiguation),also, predictive conversion doesn't hit until you simply enter everything, so you may be using it to hit relatively quickly.

So this is why stuff like 'bat' is only showing as its scientific name, now? I sorta feel like outside extremely widely-known ones like canine and feline that shouldn't be done, but if you insist, I guess it wouldn't hurt us to increase our knowledge bases a little.

hip-porcupine said:
So this is why stuff like 'bat' is only showing as its scientific name, now? I sorta feel like outside extremely widely-known ones like canine and feline that shouldn't be done, but if you insist, I guess it wouldn't hurt us to increase our knowledge bases a little.

Actually, the bat –> chiropteran has been been there for a few years, ever since ImpidiDinkaDoo redid the species tags into a more organized bunch of tags.

dubsthefox said:
There could be a big link to the wiki on the top of the search page, if someone tried searching for a tag with the _(disambiguation) suffix.

faucet said:
something like the way Wolfram|Alpha handles it would probably be the ideal solution.

I like what Wikpedia does. If a term is highly ambiguous then it returns a disambiguation page: https://en.wikipedia.org/wiki/Pool
If a term is slightly ambiguous (most users expect it to mean a certain thing) then it returns the expected page plus a link to the disambiguation page: https://en.wikipedia.org/wiki/Dash
If a term is synonymous with another term then it redirects to the preferred term and says so: https://en.wikipedia.org/wiki/Gryphon

Implementing this practice would require adding a (collapsable) text box to the top of every results page. Is that doable?

rainbow_dash said:
A smart user will click the question mark next to pool

wat8548 said:
the tiny little question marks which are nearly physically impossible to click on some devices are clearly not cutting it

Radical proposal: Get rid of the question marks! The tag itself should link to its wiki page (instead of a search for that tag). To allow a search for a tag, add a magnifying glass icon next to it, that's self explanatory. This would dramatically increase use of the wiki.

Another way to increase traffic to the wiki would be to clean up the top bar. It's too crowded, and that's valuable real estate from a UI perspective. Why is there a link to the home page? The top bar should consist of Posts, Tags, Wiki, Forum, Account and More. (Comments, Pools and Sets belong in the Posts submenu. Artists belong in the Tags submenu. Blips and Discord can go under Forum. And Help can go under More.) This would make the wiki a much more tempting foray for the novice user as 1 option among 6, not 1 among 14.

These changes would go a long way towards fixing the search issue, which would in time help with the tagging issue (most users learn to search before they start tagging).

leomole said:
To allow a search for a tag, add a magnifying glass icon next to it, that's self explanatory.

Adding a magnifying glass next to each tag may create a bit too much visual clutter. It can also cause confusion as meaning clicking the tag will cause the search since it's right next to the magnifying glass (like how the magnifying glass is next to the search field, indicating it'll search for what's in the search box).

leomole said:
Radical proposal: Get rid of the question marks! The tag itself should link to its wiki page (instead of a search for that tag). To allow a search for a tag, add a magnifying glass icon next to it, that's self explanatory. This would dramatically increase use of the wiki.

radical and also not very good, the wiki of a tag is something a user only needs to look at once or, at most, very rarely, changing the largest click region of a tag to be arguably the least useful part for any user is really terrible design.

kora_viridian said:
Even if "100" was supposed to be "1000", I think that's still a low estimate for the post rate here. Going strictly by post IDs, e621 is currently getting over 1800 posts per day, or about 75 posts an hour, on average. Not all of those posts get approved, of course, but that's the raw intake.

I think faucet meant "number of posts uploaded with invalid tags", not "number of posts in total".

leomole said:
Radical proposal: Get rid of the question marks! The tag itself should link to its wiki page (instead of a search for that tag). To allow a search for a tag, add a magnifying glass icon next to it, that's self explanatory. This would dramatically increase use of the wiki.

I agree with this. It's a comparatively minor inconvenience for seasoned users since the search results are only one easy click away from the wiki page, whereas there's weirdly no guarantee that the results will contain a link to the wiki at all (in the fringe case where there are more than 25 wholly overlapping tags).

There's no point fretting over what people who already know the site inside out will find "confusing", since we're the <1% who successfully figured out all the site's systems despite all the ways it failed to explain them to us, so clearly we can adapt to anything. Creating a smoother process for bringing more people up to our intellectual level is in all of our best interests. OP goes on at length about how the number of "power users" is insufficient for the site's workload (dodgy numerical claims notwithstanding), but point-blank refuses to consider the obvious solution of increasing our numbers.

(Also, check out this nonsense in the alias bump thread. Still think we don't need an education campaign?)

Link in first post is bad?

faucet said:
I know there's problems here, especially with the user searchability side of this, but I really feel like this is a half-measure that's not actually going to fix the issue and introduce other ones instead.

I don't believe that nobody can keep up with them - I just think that nobody is keeping up with them. The backlog is only at about 6000-something posts, and I've removed hundreds of disambiguation tags in a day before. It takes about 1-2 weeks on average for 100 posts to be uploaded, meaning it's probably about an hour of work to undo a few weeks of mistagging. Tags having a few hundred posts? Not a big deal at all. Are we forgetting tags like bow_(disambiguation) and others once had more posts needing disambiguation than the entire remaining disambiguation queue at the moment? I was planning on halving the entire queue today to prove a point but ended up busy, maybe still going to make an attempt at doing something today though.

LOL, doing my part? https://e621.net/post_versions?commit=Search&search%5Bexclude_uploads%5D=0&search%5Btags_removed%5D=bow_%28disambiguation%29&search%5Bupdater_id%5D=27213 Meh, only 4 of them.
I saw an odd one: Blizzard Entertainment on ones that did NOT have actual snowstorm blizzards, but sure as the world, still had blizzard_(disambiguation) on them. I have NO IDEA how that happened. I could find no other ambiguous definition of a 'blizzard' that would fit. :shrugs:
I don't actually think they look that bad to keep up with, but maybe a great big "You used an ambiguous tag - click here for definitions/examples of correct tags." link would help matters, greatly. Not a bad idea to make it more up in your face that you need to fix it, as a tagger!
As far as on a search... definitely make disambiguation and other invalid tags red red red? Not sure how to add that "LOL, nope, read Wiki" feature to search, as I have not touched Booru code.

wat8548 said:
Oops, I accidentally disambiguated all of them. Guess the hypothetical noob is shit outta luck now :3

LOL, killed a few really really old ones with like 1-4 examples that way, too. Sigh... If there were ones like Blizzard, or pool, or bow, then yeah, definitely should have created a Wiki entry to show the right ones, but these were not the kind to get abused to that level in the first place - Stuff like name of character that didn't have the series/artist/creator/owner listed. TBF, not likely to get a lot of people searching for them, either, hey, at least it reduced the list a little.

Let me catch up with other posts... Hmm, yeah, bat is another one like that. Two very common definitions that don't match. I bet there's words that also a character name, in addition to an object and a species.

:edit:

wat8548 said:
I think faucet meant "number of posts uploaded with invalid tags", not "number of posts in total".

I agree with this. It's a comparatively minor inconvenience for seasoned users since the search results are only one easy click away from the wiki page, whereas there's weirdly no guarantee that the results will contain a link to the wiki at all (in the fringe case where there are more than 25 wholly overlapping tags).

There's no point fretting over what people who already know the site inside out will find "confusing", since we're the <1% who successfully figured out all the site's systems despite all the ways it failed to explain them to us, so clearly we can adapt to anything. Creating a smoother process for bringing more people up to our intellectual level is in all of our best interests. OP goes on at length about how the number of "power users" is insufficient for the site's workload (dodgy numerical claims notwithstanding), but point-blank refuses to consider the obvious solution of increasing our numbers.

(Also, check out this nonsense in the alias bump thread. Still think we don't need an education campaign?)

I disagree on adding friction for literally one the most common things people want to do when trying to click on tag names. It's been that way on most sites because most people aren't intending to look up the definition. It's also how a hypertag usually works. It links to other similar documents, not a glossary. XD

Argh, just realized that when people said 'search', they meant the automatic suggestions when you partially type a tag when editing. Not the search bar at the upper left-hand side of the page. Sorry, I think that partially invalidates what I just said. :(

rainbow_dash said:
A smart user will click the question mark next to pool

Never assume users are smart. Treat them as if they're smart, because they are, but assume they're dumb as bricks. This isn't because they're stupid, but because you can't assume everyone is working off the same pool of information or have the same ability to figure one function out compared to another. Even the smartest person will appear stupid when they don't know how to do something, especially when the system isn't well-designed to help them learn it.

I'm hardly stupid, but it took me years to figure out those ? were supposed to be clicked on and were how to get to a tag's wiki. Others likely have twigged faster than I did, but how many potential power users haven't figured it out yet?

leomole said:
Radical proposal: Get rid of the question marks! The tag itself should link to its wiki page (instead of a search for that tag). To allow a search for a tag, add a magnifying glass icon next to it, that's self explanatory. This would dramatically increase use of the wiki.

Perhaps combine a regular full search with the wiki entry. If you hit the tag, it'll take you to the wiki page and the entire expected full first page of the search right under it rather than just the current last four posts uploaded under the (view all) link. Obviously, this won't work for searches using multiple tags and perhaps should only happen when one clicks on a tag rather than when they use the search box. If the wiki entry is smack dab in one's face when they search a tag, they'll be more likely to fill out empty ones that need to be filled out (like disambiguation tags). They'll also be more likely to read it. If there's a concern about having to scroll down too far to get to the images because of big wiki entries, make the wikis expandable/collapsible with an obvious "Expand Wiki"/"Collapse Wiki" button or a "Jump to Search" button right under the tag's name. The wiki would only need be visible on the first page.

If we're talking ambiguous tag definitions and inexperienced users not understanding them, is this another place to bring up the massive rise in humanoid mistagging? By my best interpretation, something as seemingly inert as placing humanoid on the upload form without explanation causes harm, and it cannot be assumed that a user knows the site definitions of even tags we consider fundamental.

Borrowing from scaliepe's search example there is a huge uptick in this search's volume^{keeping in mind it includes results such as single-character transformation sequences} when the new site went live:
humanoid anthro solo date:<2020-03-01 26 default pages spanning 13 years (1 page per 6 months)
humanoid anthro solo date:>2020-02-29 132 default pages spanning 30 months (4.4 pages per month)

I can only assume^{as humanoid featured in no other changes I'm aware of} it comes from the new upload page having a big 'ol button for humanoid form, combined with the offsite expectations of humanoid meaning more generally anything that's human framed rather than just in terms of facial features. For further example that it was an immediate shift and not merely a gradual change^{which has snowballed since} in tagging attitude and cleanup activity:

January 2018: 28 posts (less than 1 page)
January 2019: 32 posts (less than 1 page)
...
December 2019: 45 posts (less than 1 page)
January 2020: 60 posts (less than 1 page)
February 2020: 52 posts (less than 1 page) (The month before the site upgrade)
March 2020: 125 posts (nearly 2 pages) (The month of the site upgrade)
April 2020: 175 posts (2 and a bit pages) (The month after the site upgrade)
May 2020: 143 posts (nearly 2 pages)
June 2020: 146 posts (nearly 2 pages)
...
January 2021: 239 posts (3 and a bit pages)
January 2022: 482 posts (6 and nearly a half pages)

magnuseffect said:
*snip*

I wonder if this is a problem related to lack of cleaning or a problem with more users adding the tags in the first place. I could imagine users typing in cat or something into the tagbox and seeing cat_humanoid showing up on the autocomplete dropdown and adding without thinking.

from what I remember, there was a time after 2.0 where the upload form was mostly the same as it was prior to the update, and the new upload form was something added later, but I might be misremembering because I don't ever upload stuff.

darryus said:
from what I remember, there was a time after 2.0 where the upload form was mostly the same as it was prior to the update, and the new upload form was something added later, but I might be misremembering because I don't ever upload stuff.

The new upload form was introduced and made default on day 1. I used it for a few uploads before getting sick of it and re-enabling the standard one.

The humanoid issue seems like it could only be reliably fixed with an illustrated guide right there on the page, probably similar if not identical to the "Furry Scale". No way is any solution requiring users to do more reading going to get off the ground.

Another case of a misused tag that's apparently a bit too ambiguous for people to use correctly: dialogue_box. It's supposed to be for text boxes (like those seen in video game UIs) with dialog in them, like in post #3577716. But the vast majority of uses seem to mistake it for speech bubble or thought bubble, which is supposed to be distinct and separate. So posts with speech bubbles are split between speech_bubble and dialogue_box, and anyone looking for dialog boxes has to dig through all the speech bubbles.

So here's something hilarious I just discovered.

Why yes, that is one of our esteemed admins adding disambiguation tags en masse.

At first I couldn't work out what was going on. None of the images contained either laboratories or labradors, and at first glance seemed to have nothing in common at all.

But then I remembered this intra-admin civil war from a few months ago.

It turns out, lav is aliased to looking_at_viewer at the sole behest of the very same admin, against the wishes of at least two other admins and (judging by the votes on the rejected BUR) the wider userbase. In fact, said admin was so attached to this shortcut that she not only remade the controversial alias, she continued using the now-invalid tag throughout the short period it was unaliased, apparently as some kind of protest.

And what key is just to the right of V on a QWERTY keyboard?

Anyway, long story short, there are 26 fewer posts tagged lab_(disambiguation) now.

If you want to lower disambiguation tag counts, then you probably want to just prevent those tags from being added at all. But because that alone is a bad solution, also catch the mistakes as they happen and educate users. For example, when a user tries to submit an invalid tag in an edit, throw up an error dialogue informing the user that the invalid tag will not be added and present them with valid alternatives.

Warning! bow is not a valid tag and will NOT be added to this post. Perhaps you meant one of these tags instead?

• bow_(feature)
• bow_(anatomy)
• bow_tie
• hair_bow
• tail_bow
• bow_(stringed_instrument) - Such as with a violin.
• bow_(weapon) or crossbow
• bowing - Bending at the waist in a polite sort of way.
• ribbons

[maybe add some boilerplate stuff to the bottom of all invalid tag warning-suggestion boxes like...]
If the concept you wish to tag is not listed above, consider creating a new descriptive tag for it [link to tag creation best practices wiki that probably still doesn't exist :) ] and adding that tag to this disambiguation dialogue [direct link to disambiguation wiki edit page].

Ideally, for UI:

• those tags could be clickable buttons that add them to the tag edit box
• all the suggested tags would have short descriptions (100 char max may be too much) ending with a (read more) link to their wikis
• and perhaps the possibility for an example thumb # or two

Really, this whole thing would be a module duplicated from the respective disambiguation wiki, meaning that disambiguation wikis require specialized, table-like forms be filled out. Three columns: tag_name, description, example post ID(s).

rainbow_dash said:
We are always open to suggestions and feedback. If you can think of something that's sustainable as we become a larger site and aids searchability, let us know. I give serious consideration to everything people send my way.

This is beginning to sound like, "We have listened to your concerns."

Who else is on pool patrol? Today I edited 20 posts.

wat8548 said:
This is beginning to sound like, "We have listened to your concerns."

Who else is on pool patrol? Today I edited 20 posts.

I do also think it should have the _(disambiguation) suffix again. And I am pretty sure removing it without the suffix is tag vandalism, since it is a valid tag again.

dubsthefox said:
And I am pretty sure removing it without the suffix is tag vandalism, since it is a valid tag again.

I'd have thought "removing" in this case involves replacing it with whichever specific tag it was meant to be, which isn't vandalism.
I'm also not sure if it's really a valid tag? The OP implies that what's intended to be happening is it being "aliased to the more common term and accept a low number of mistags for the less common term," and I'd have to assume that just hasn't happened yet for whatever reason. I'm not sure why it would have its disambiguation alias pulled if it wasn't going to immediately be aliased to something else, though. As noted, at least having the _(disambiguation) suffix should tell someone something's wrong better than just letting them have the depopulated tag.

Making it easier for users to learn about the wiki is a good idea, but I think it'd be better to make that clear and accessible on the upload and edit pages than in a normal search. That wouldn't just be better for new users, being able to go straight to a wiki page instead of having to open a new tab and search for it would be super convenient. At the very least how to use the wiki should be mentioned in the how to tag guide. As it is, the only way to learn about the wiki is to click on the question mark, or go to the forum. Not many people try pressing buttons they don't understand, and even less use the forums.

Is this intended to impact unique character and species tags suffixed with their respective origins when clashes are unlikely? Do we really need tags like james_sunderland_(silent_hill) just so no one confuses it with the conservative British politician or is the intention to alias james_sunderland to it like what is done with teemo and teemo_(lol)? I don't think it's necessary, but I've been wrong before.

Trying to read this from start, but: Isn't it impossible to tag *_disambiguation? Maybe make it so attempts to do it bring up a prominent link to the Wiki. Also, yeah, seems that not having an actual disambiguation but aliasing to invalid tag is counterproductive. XD

A real annoyance with invalid tag in backlogs is that you have no idea which tag you screwed up on. It just says "invalid tag". XD This is frustrating for new users, especially, I bet!

alphamule said:
Trying to read this from start, but: Isn't it impossible to tag *_disambiguation? Maybe make it so attempts to do it bring up a prominent link to the Wiki. Also, yeah, seems that not having an actual disambiguation but aliasing to invalid tag is counterproductive. XD

A real annoyance with invalid tag in backlogs is that you have no idea which tag you screwed up on. It just says "invalid tag". XD This is frustrating for new users, especially, I bet!

Yeah, having it be aliased to invalid tag helps nobody, uploader might not remember all the tags they used and anyone coming to fix it has no idea what it originally was meant to be.

snpthecat said:
Yeah, having it be aliased to invalid tag helps nobody, uploader might not remember all the tags they used and anyone coming to fix it has no idea what it originally was meant to be.

At the same time, if there's a tag that shouldn't be used, allowing people to still tag and search it defeats the purpose of invalidation. Some invalid tags need fixing with better tags (and you don't want people blindly deleting these), while others should just be deleted as there's nothing to replace them with (and you don't want people wasting time figuring out if these should be replaced or not). Aliasing the latter set to invalid_tag is a good compromise to distinguish those cases.

Also, the Invalid category was a relatively recent addition (with the site upgrade a couple years ago). Before that, the only way to invalidate tags was to alias to invalid_tag. Some tags that have been aliased to invalid_tag in the past would be better changed to a disambiguation in the Invalid category now, but to do that someone's gotta make BURs to remove the current alias and then disambiguate the appropriate tags (which need to be done separately, a single BUR can't remove and change an alias, and BURs/requests take time to get accepted). And not all invalid_tags should be unaliased and disambiguated, so there needs to be discussions on which can be changed and which should be left as-is. Which all that takes time.

watsit said:
At the same time, if there's a tag that shouldn't be used, allowing people to still tag and search it defeats the purpose of invalidation. Some invalid tags need fixing with better tags (and you don't want people blindly deleting these), while others should just be deleted as there's nothing to replace them with (and you don't want people wasting time figuring out if these should be replaced or not). Aliasing the latter set to invalid_tag is a good compromise to distinguish those cases.

Also, the Invalid category was a relatively recent addition (with the site upgrade a couple years ago). Before that, the only way to invalidate tags was to alias to invalid_tag. Some tags that have been aliased to invalid_tag in the past would be better changed to a disambiguation in the Invalid category now, but to do that someone's gotta make BURs to remove the current alias and then disambiguate the appropriate tags (which need to be done separately, a single BUR can't remove and change an alias, and BURs/requests take time to get accepted). And not all invalid_tags should be unaliased and disambiguated, so there needs to be discussions on which can be changed and which should be left as-is. Which all that takes time.

Ah, I had wondered if aliasing to invalid tag meant the original was unsalvageable, and had no better alternatives. So does that mean invalid_tag should be blindly deleted whenever seen?

Idea

Ambiguity feature:

This proposed feature aims to allow disambiguation tags to be more accessible, while also making sure adding an ambiguous tag to a post impossible. If a user tries to add an ambiguous tag, their edit is halted until they specify which tag(s) they meant to add.

Editing an existing post that has a hanging ambiguity would require the editor to resolve the ambiguity before they can submit their edit.

Searching with an ambiguous tag would show results with all of the ambiguities, and the user would be shown the ambiguities and could select one to refine their search.

How it works

It would work similar to an implication, can be added to BURs like this:

ambiguate pool -> billiard_table
ambiguate pool -> swimming_pool

When tagging

When an ambiguous tag is attempted to be added to a post/detected on an existing post, the edit is halted, and the following message would appear:

You attempted to add the tag pool, but that tag is ambiguous. Please specify from the following:

☐ - 8k swimming_pool - [wiki]
☐ - 485 billiard_table - [wiki]

[Confirm] [Remove "pool" tag]

The boxes to the left are checkboxes used to select the applicable tags. When the user hits confirm, the pool tag is removed and the selected tags are added to the list instead.
This has the benefit of never allowing hanging disambiguations being tagged onto new posts, and if any current post has a disambiguation tag, if it is edited, the editor is forced to resolve the ambiguity.

When Searching

If a user searches pool, they would see something like the following:

(make the background here yellow or something so it's more obvious)
You searched pool, but that tag is ambiguous. Did you mean:

1. swimming_pool
2. billiards_table
(if the list is long, put the list in a spoiler that shows the first few items)

Posts:

post #4159471 post #4012280 post #3947318 post #4147117

The user would see search results from swimming_pool, billiard_table, and any post with a hanging ambiguity of pool.
If they clicked on a tag in the tag list, the pool tag in the search bar would be replaced with the tag they clicked, allowing the user to refine their search.

Using the proposed feature to resolve existing hanging ambiguities

I would recommend adding a new metatag for searching: hanging_disambiguation:true.

A lot of posts would have hanging ambiguities if this were to be implemented on all disambiguations all at once. As such, this should be implemented in phases of three or four large tags first.

Then people on the tagging project can search pool hanging_disambiguation:true to find posts with hanging disambiguations and then fix them. Once all of the hanging disambigs are resolved, move onto the next set of tags.

Once all of the large tags are done, ambiguations can be added to smaller tags, and people on the tagging project can just search hanging_disambiguation:true to find hanging disambiguations to fix.

Better idea, if possible to add it to the upload form, if the user uses dismabiguated tag, force them to replace it with a final tag from an option list (did you mean x?) Before they can complete upload