Community Wishlist Survey 2023/Search and Categories

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2023
Search and Categories
8 proposals, 129 contributors, 183 support votes
The survey has closed. Thanks for your participation :)



Improve tracking of categorization changes

  • Problem: For several years now, categorization changes have had dedicated entries in recent changes and watchlist. This is useful for watchlist – when you watch a category and have categorization changes enabled, you can see recent additions and removals to the category. For recent changes, this isn't that useful as it lists changes to any category. On Special:RecentChangesLinked ("related changes"), it only shows additions to the category (and also categorization changes for other categories). It happens because when you remove a page from the category, it is no longer "linked" and thus it cannot be listed in the related changes anymore. Consequently, there is no native way to see all category additions and/or removals, and only them, from a single place. Additionally, there has been some technical debt around displaying the categorization changes. For example, sometimes it's unnecessarily difficult to access the diff.
  • Proposed solution: (one of these)
    1. Improve Special:RecentChangesLinked to implicitly show additions and removals of the category (when you have categorization changes enabled)
    2. Create a dedicated "mode" for categories in Special:RecentChangesLinked (i.e., make #1 explicit)
    3. Create a new special page dedicated to category changes (similarly, there is Special:NewPages for pages creations)
  • Who would benefit: Wiki gnomes checking for mistakes, patrollers checking for vandalism, wikis with complex categorizations
  • More comments: None of the above should require any major changes to the storage, it's just a matter of displaying better what is already being saved. Since this all is backed by the recent changes, the changes are only traceable for the last 30 days. There is also a proposal (phab:T6366) that a complete history of all category members (and time of their addition/removal) is stored, but that would probably be an epic task.
  • Phabricator tickets: phab:T89582, phab:T130134 (general problem); phab:T126851, phab:T148533, phab:T270662, phab:T270774 (display issues)
  • Proposer: Matěj Suchánek (talk) 09:54, 24 January 2023 (UTC)[reply]

Discussion

Repurposed from the 2021 and 2022 editions. --Matěj Suchánek (talk) 09:54, 24 January 2023 (UTC)[reply]

  • Question Question: This seems like it could quickly get out of hand, for example @Matěj Suchánek: if someone adds or removes a new category to a template such as w:cs:Šablona:Infobox - osoba or w:en:Template:Infoxbox person that cascades to other pages (possibly millions of pages) - what would you expect to populate in this proposed log? — xaosflux Talk 15:25, 25 January 2023 (UTC)[reply]
    I'm not suggesting any change to how the log is populated. My point is just a more logical view of the changes. --Matěj Suchánek (talk) 17:02, 25 January 2023 (UTC)[reply]
    1. The idea is to show currently available categorisation information in a more systematic way on a dedicated page, not just limited to the last 30 days.
    2. Ideally, every incoming/outgoing member should've been logged with the timestamp of when the software caught on with the categorisation of a ceratain page, but that might be too much of a task, so that isn't asked for at this moment of time.
    —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 22:06, 17 February 2023 (UTC)[reply]
  • Though it's beyond the scope of this wish, I'd like to mention there are use cases for extending inbound-link change tracking to namespaces other than categories. E.g. when someone creates a WikiStory for an article, a discussion is mentioned on another talk or project page, or an article watcher wants to learn when an article on a related topic has been created. I can't imagine the performance hit of doing that for all article→article links, however. Pelagic (talk) 17:05, 13 February 2023 (UTC)[reply]

Voting

Date filter in deleted contributions

  • Problem: We can filter by date within a user's contributions, but there is no date selection feature when admins look at deleted contributions.
  • Proposed solution: Add date filter in deleted contributions.
  • Who would benefit: Admins tracing past contributions, e.g. when looking to see whether a now-empty category was originally populated by the same editor who created it.
  • More comments: Note: only admins may view deleted contributions.
  • Phabricator tickets: phab:T36524
  • Proposer: – Fayenatic London 10:07, 4 February 2023 (UTC)[reply]

Discussion

Voting

Add "Sorting order by alphabet" in Special:Search

  • Problem: If you use Advanced search (example) you can choose between the three following sorting orders:
    1. "Relevance"
    2. "Edit date - current on top"
    3. "Creation date - current on top"
Or if you are skilled enough you can use some more, but no "Sorting order by alphabet"
  • Proposed solution: Add "by alphabet" (and also maybe some others) as a possible selection for sorting order under Advanced search.
  • Who would benefit: probably all editors and readers
  • More comments: Thank you!
  • Phabricator tickets: T40403
  • Proposer: W like wiki (talk) 04:44, 5 February 2023 (UTC)[reply]

Discussion

  • by alphabet of which word / which part of the search result (snippet, title, section headers, categories the page is in, pdf contents... all those can be partially matched search results) —TheDJ (talk • contribs) 10:56, 5 February 2023 (UTC)[reply]
Hello @TheDJ:, ok, thanks to your question I realised that I made a mistake in the search link above: it should be searching in title! (and not searching in fulltext). So simply I meant sorting by title. Regards --W like wiki (talk) 01:29, 7 February 2023 (UTC)[reply]
  • This was discussed nearly a decade ago and it was decided that for performance reasons alphabetic results were not possible. I don't know if that's still the case (I presume it's still not easy; there are more sort orders documented than are available in the UI, but still none for alphabetical). I'm thinking this should be closed as not possible, but will see if we can get clarification first. I'm not sure if it helps, but the list of categories for the example above (starting with "Categories by") can be done on Quarry. —SWilson (WMF) (talk) 09:27, 6 February 2023 (UTC)[reply]
Hello @SWilson (WMF): Thank you for the 100% links!
  • So I checked the phab discussion, here an update: The discussion was paused in 2014 with doubts about the performance, as you mentioned. In 2017 it was restarted. At least a posted quote from the IFLA Statement of Principles (International Federation of Library Associations and Institutions) 7.2 state:
"When searching retrieves a large number of [results], results should be displayed in some logical order convenient to the [search] user [...]. The user should be able to choose among different criteria: date of publication, alphabetical order, relevance ranking, etc."
made it clear that it is maybe worth to try it. The discussion is still in progress.
  • The Quarry Link is great, it offers what I was looking for (sorting by title) and even more. It is maybe a bit of what TheDJ was asking: different sorting possibilities. But one big disadvantage: Quarry is an extern link! So first you have to leave wikipedia/commons and go to Quarry. Than people have to understand how Quarry works (for me I dont know yet). But even when they are able to use Quarry, than the search results are still not linked! So for each search result you are interessted to open, you have to do manuelly copy paste to commons/wikipedia, hmm... --W like wiki (talk) 01:29, 7 February 2023 (UTC)[reply]
@W like wiki: Oh, absolutely. I wouldn't recommend Quarry as an end-user sort of tool! It's mainly good for queries that are not possible in any other way, generally things that are of too limited scope to be worth building into the software proper. Note that it is an external tool, but it's still within Wikimedia (i.e. it's hosted by Wikimedia Cloud Services). For more info about Quarry, see Research:Quarry. SWilson (WMF) (talk) 01:41, 7 February 2023 (UTC)[reply]

Voting

Limit which namespaces are allowed in a category on the category page itself

  • Problem: In order to avoid unwanted pages from polluting categories intended for certain namespaces, we waste our time and effort manually removing or commenting out [[Category:...]] and coding templates to prevent unwanted pages from being added to categories.
  • Proposed solution: A magic word or extension tag to be used inside category page wikitext that determines which namespaces are allowed (or not allowed) in the category.
  • Who would benefit: Readers and editors
  • More comments: Got 41 votes last year.
  • Phabricator tickets:
  • Proposer: Nardog (talk) 18:20, 23 January 2023 (UTC)[reply]

Discussion

  • Do we have a good system for letting editors know how to select categories? At present, editors just search for category names they think may fit, but there isn't any information about how each category is intended to be used. For instance, many universities have a "University of X alumni" category. However, some categories are "Alumni of University of X". Sometimes, there's just a "University of X" category without alumni. The category keepers may intend the latter to not include alumni, but editors add alumni because there's not an alumni category. As such, it may be helpful to include a short description (much like for Wikilinks) for each category to let the editor know how the category is being used. (This is also not to mention how obnoxious finding correct categories can be). Significa liberdade (talk) 22:12, 10 February 2023 (UTC)[reply]

Voting

linksfrom: filter

  • Problem: It can be difficult to find articles linked from a page which satisfy other criteria.
  • Proposed solution: Give search a linksfrom: filter, like linksto: but checking the other end of the wikilink. Following redirects would probably be helpful.
  • Who would benefit: Readers using, and editors maintaining, list articles, navboxes, etc.
  • More comments: incategory: and PetScan work for some cases but it can be hard to combine link checking with other filters efficiently.
  • Phabricator tickets: task T253642; possibly task rTSVN5206
  • Proposer: Qwerfjkl (talk) 18:24, 30 January 2023 (UTC), from Certes (talk) 16:06, 19 November 2020 (UTC)[reply]

Discussion

Voting

Some transcluded templates include the page in unnecessary categories

  • Problem: Let's say that template Foo is transcluded in the page Lorem Ipsum. The template Foo automatically includes the page Lorem Ipsum into the category Examples, but the page Lorem Ipsum should not be placed in the Examples category.
  • Proposed solution: There should be a way to prevent some pages from being placed in certain categories. In the above example, something like adding {{#EXCLUDECAT:Examples}} or <excludecat>[[Category:Examples]]</excludecat> at the bottom of the page Lorem Ipsum would be some of the possible solutions.
  • Who would benefit: The users who work with categories and the readers who use them.
  • More comments:
  • Phabricator tickets:
  • Proposer: --NGC 54 (talk｜contribs) 20:05, 5 February 2023 (UTC)[reply]

Discussion

Voting

Sort pages with Chinese Japanese or Korean titles in a more useful order

  • Problem: In category pages, pages with titles that begin with a kanji are currently sorted in Unicode order and grouped by the first character in the title. This is not a traditional way to sort and group things in CJK languages, and it’s not very helpful because Unicode order is opaque and does not correspond to anything in any CJK language.
  • Proposed solution: Titles that begin with a kanji should be grouped the traditional way, by stroke count (e.g., the kTotalStrokes field in Unihan_IRGSources.txt if using Unicode 14), then within any stroke count grouping, sorted by Kangxi radical order (e.g., the integer part of the kRSKangXi field in Unihan_RadicalStrokeCounts.txt), any ambiguities that remain can be kept in Unicode order.
  • Who would benefit: native CJK readers who use category pages
  • More comments: I read a proposal to sort these by pronunciation, but that would not work because every kanji is pronounced differently in different languages (and there can be more than one pronunciation even within a single language), so any pronunciation chosen would privilege one language over all others.
  • Phabricator tickets:
  • Proposer: Al12si (talk) 21:24, 5 February 2023 (UTC)[reply]

Discussion

see also: phab:T47443 and Manual:$wgCategoryCollation.

Any collation that is defined by UCA/UCI as a variant, and that is installed on the servers, and for which a wiki community can show a consensus for, can already be switched to. Im not sure if the kanji scripts are significantly different in that (they might be). —TheDJ (talk • contribs) 12:37, 18 February 2023 (UTC)[reply]

Even if the sorting part can already be addressed the grouping still wouldn’t be ideal. Grouping by stroke count will reduce the number of groupings needed (perhaps significantly in some cases), reducing clutter. Al12si (talk) 06:54, 21 February 2023 (UTC)[reply]

Voting

Disadvantages of '公共轉換組' in Wikipedia (Chinese Version)

  • Problem: '公共轉換組' in Wikipedia allows people to transfer Chinese to fit different places' registers. But the page for 'Traditional Chinese' only shows wordings of Traditional Chinese in Taiwan, which does not consider the difference in wordings. And through search engines, this affects the search results that all are presented in the form of Taiwan register, leading to misleading problems.:
  • Proposed solution: Using the format of 'Chinese (Taiwan) / Chinese (Hong Kong)' to present the content in the page of Traditional Chinese:
  • Who would benefit: Users of Traditional Chinese:
  • More comments: Having such formatting would be able to reduce misleading problems and help Chinese users to correctly know the difference in the use of wordings in different places. Moreover, there are cases like Doraemon's Chinese Name in Taiwan and Hong Kong being mixed up by journalists and some people commented that might be the problems caused by the search result of Wikipedia being shown only in Chinese wordings used in Chinese, which are not able to consider other places' reader (Related feedback: https://chinesedora.com/news/46661.htm). Although '公共轉換組' is a good function inside Wikipedia, the editorial policy only uses Taiwanese Chinese to present Traditional Chinese content shows great negative impact to web users, which through search engines to reach Wikipedia.:
  • Phabricator tickets:
  • Proposer: 梁粉噹 (talk) 18:31, 4 February 2023 (UTC)[reply]

Discussion

The example shown above is because the current Chinese name of Doraemon used in Taiwan and Hong Kong is only one word different, so It would easily cause misleading problems if users are using search engines (e.g. Google) to reach Wikipedia since the search result shown is without using the transfer function on Wikipedia, and the content are only presented in Traditional Chinese but in form of Taiwna registry.— The preceding unsigned comment was added by 梁粉噹 (talk) 18:35, 4 February 2023 (UTC)[reply]

以下為翻譯(The following is the translated content of the about paragprahs) 問題: 維基百科中文頁面的公共轉換組支援切換各個中文使用地的語境版本。而當中的繁體中文頁面向來只使用台灣中文的內容，欠缺地域性文字使用差異的考慮。而且通過網絡搜尋器，出來的結果全為台灣語境用詞，造成誤導. 解決方法: 在繁體中文頁面以並列中文標題的格式 (例如: 台灣中文 / 香港中文) 受惠人士: 繁體中文使用者 採用並列不同名稱的格式有助減少誤解。此外，Doraemon在台灣(哆啦A夢)和香港(多啦A夢)因為名字只有一個字的差異，而令身為大眾傳媒的新聞從業者時常出錯。有批評指維基百科的繁體中文頁面紙採用台灣繁體中文的字眼，造成地域性用詞的壟斷。而且從谷歌等搜尋器顯示出來的搜尋結果都是繁體中文頁面，未能照顧地域性用詞差異。儘管公共轉換組在維基百科內是好的功能，但由於繁體中文頁面已採用台灣中文作為編輯方針忽略考慮其他中文使用地的用字習慣，對採用搜尋器去接觸維基百科的網絡使用者帶來不少負面影響。— The preceding unsigned comment was added by 梁粉噹 (talk) 18:47, 4 February 2023 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Search_and_Categories&oldid=25728178"