Do the following
- In test, go to the event Kickstarter Art+Feminism 2018
- Filter by the category: African-American Artists
- Notice that the menu also offers the category African-American artists (lower case)
- Try filtering by the two categories, in sequence
- **Expected results: **The results should be the same
It turns out that there are a lot of categories for which users have made bogus upper-case versions to serve as a kind of category redirect. - **Actual results: **no en.wiki results are found for the upper-case version.
It turns out the upper-case version is a redirect.E.g., IdeallyLiving people/Living People or African-American artists/African-American Artists (in both cases, we would sort this out somehowthe lower-case name is the real one). This problem seems to be pretty commonIf users make the wrong choice during event setup, since of the four categories I tested with it was an issue with two (Living People/Living people)they may have a hard time figuring out why they aren't getting the metrics they expected.
IdeallyUnfortunately, we'd figure this out and give the intended resultsthere is no technical way to pre-identify and exclude bogus categories. Failing thatSo instead, we should find some way to tell people that they've selected a redirect instead of a real categorypropose to give users a clue as to which are the real categories by providing a count of the number of pages each category contains.
|**Lower case a (actual category)**|**Upper-case A (redirect)**|==Notation
|{F26616101}|{F26616100}|
In discussion, the team talked about either a) just putting the page count in parentheses after the category name, or 2) putting the count into an interface "pill" after the name. Either would be fine. In either case, the notation should look something like this:
Living people (885,494 pgs.)
Living People (2 pgs.)
Living people on EN wiki who are dead on other wikis from November 2016 (47 pgs.)
Living people on EN wiki who are dead on other wikis from February 2018 (36 pgs)
etc.
==Presentation
As you can see in the screenshot below, there is also something of a display issue that happens when category names are long—as seems to be fairly common.
At a minimum, we could simply widen the field a bit. It looks like the field is coded in a responsive way, to fill a certain % of the screen until the screen is very narrow, at which point the field fills 100% of its own line. So how much wider the field could get I don't know. But @Prtksxna can give a figure—or he might have a better idea for how to handle this issue. Prateek?
{F27320210}