Talk:Community Wishlist/W334

This page is for discussions related to the Community Wishlist/W334 page.   Please remember to: Sign posts using the four tildes (~~~~) Remain civil and polite during discussions. Place new text under old text (start a new post).

Selecting content

Hello. With respect to issues-based discussions for articles, it would be convenient to be able to detect and to visualize which selections of articles' content, if any, were mentioned in their open issues.

With such features, one could:

1. warn editors when a planned edit was about to modify content inside of a selection relevant to one or more open issues.
2. alert those subscribing to an open issue that its article had been modified in a way that was relevant to the issue.

One or more new templates could be used to provide these features. A template for including a selection of an article, {{Selection}}, could be used to render and visualize specified selections of content, perhaps in a manner such that selected text was surrounded by proximate text. As considered, occurrences of these templates could be readily detected in issues' wikitext.

When designing such templates, one could explore text selection models including from Web Annotations and Text Fragments.

Reasons for choosing the Text Fragments text selection model include that it readily maps to Text Fragment URLs to utilize in generated hyperlinks to articles such that selections of content are highlighted upon navigation.

If the Text Fragments model were chosen, named parameters for a {{Selection}} template would include text, textStart, textEnd and also prefix and suffix. Such a template could also have an (optional) named parameter, article, for specifying which article to make a selection from. An article parameter could be optional for templates occurring in issues as its default value could be inferred: that article which the issue was an issue for.

Such a template could, then, for example, resemble: {{Selection|textStart=...|textEnd=...}}.

As considered, such templates could render to markup involving a hyperlink containing a blockquote containing some article text around a highlighted selection of text content. That is, to something resembling:

<a href="..."><blockquote cite="..." class="outer">... lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. <span class="inner">Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</span> Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum ...</blockquote></a>

Thank you. Any thoughts on these ideas? AdamSobieski (talk) 08:15, 6 December 2024 (UTC)

Thinking about it further, a {{Selection}} template could be designed for its users to be able to also manually define the outer selection of any surrounding content, in addition to being able to define the inner selection (this inner selection mapping to the Text Fragments URI of the hyperlink blockquote).

{{Selection|textStart=...|textEnd=...|outerTextStart=...|outerTextEnd...}}

If a template user did not manually specify the outer selection, the template could algorithmically select the surrounding text.

There might be yet other named parameters to enhance the {{Selection}} template. For instance, to toggle off entirely the selection of any surrounding content or to efficiently indicate for it to select any surrounding content at paragraph boundaries, at the starts and the ends of those paragraphs containing the specified selection. AdamSobieski (talk) 03:30, 7 December 2024 (UTC)

@AdamSobieski thanks for sharing this wish. A couple clarifying questions.

1. Is your definition of "issue" a selection of text in an article that could be deemed problematic, inaccurate, or biased?
2. Could you show a couple concrete examples of the problem you're trying to solve? I think it could help illustrate the problem for others.

The solution is interesting, however I think there are a number of ways to solve for 1) surfacing articles with potential issues and 2) triaging the most important issues within an article. First, I'd like to align on which problem(s) this wish tries to solve. JWheeler-WMF (talk) 21:41, 16 December 2024 (UTC)

I'm hoping that the capability to create and share selections of content would convenience issues and issue-tracking systems for wiki articles.

Presently, talk pages are utilized for collaborative tasks about articles including those in issue-based discussion threads. Also, article message boxes, or "amboxes", are presently rendered on the tops of articles to call attention to them, signaling issues with articles.

While concrete example uses for issues about articles are difficult to list exhaustively, as considered, these would include those scenarios for which "amboxes" are used: calling attention to content about an article with respect to: speedy deletion, deletion, content (neutrality, promotional), style (cleanup, need more links), notice (current event), move, and combinations of these uses, per stacking "amboxes".

As considered, content selections, including those which can provide containing contextual content, would be entirely optional for issues and could serve as clarifying examples pertinent to an issue or as evidence supporting claims made about an article, e.g., pertaining to its content or style.

Also, in theory, it might be possible to simplify UX for coordinating content selections between dynamic article content and their issues by putting the quotes in the articles instead of the issues. The quotes wouldn't render in the articles but could be uniquely identified for rendering in one or more of an articles' issue.

...lorem ipsum dolor {{selection|id=abc}}sit amet{{endselection|id=abc}} consectetur adipiscing...

...lorem ipsum dolor {{selection|id=abc|issues=123}}sit amet{{endselection|id=abc}} consectetur adipiscing...

Then, in an article's issue, e.g., issue 123, one could use a template to render a selection simply by providing its id:

...elit sed do eiusmod tempor {{showselection|id=abc}} incididunt ut labore et dolore...

With something like this, articles' editors could see where content selections were presently in use in that article's issues. AdamSobieski (talk) 21:10, 17 December 2024 (UTC)

Categorizing issues

In this proposed approach, articles' issues would each be URL-addressable and might each have their own wikitext resources. If so, in theory, articles' issues could each be folksonomically categorized, both manually and automatically placed into one or more categories utilizing [[Category:Name]] wikitext. Any thoughts on uses for this feature with respect to articles' issues? AdamSobieski (talk) 02:58, 7 December 2024 (UTC)

Related similar wishes

See Automatically showcase talk page open issues on their respective main pages and Do not fully archive unsolved issues on Talk pages.

Many or most talk page posts are issues. I think it may be better to incorporate that into the talk page but maybe doing something about the talk page such as showing a tooltip on the link to go to it saying for example "Reported issues with the article and discussion about it".

 Oppose this part In these regards, each individual issue could provide buttons for contributors to like or upvote it and to share it on social media. Wikipedia isn't some social media site and this is just canvassing for some social media hivemind irrational decision-making instead of rational constructive discussion. Things shouldn't be change this or that way because people upvote it, see WP:NOTDEMOCRACY. Forgot to mention this at our discussion at Future Audiences. Prototyperspective (talk) 12:30, 6 December 2024 (UTC)

Thank you for the hyperlink to WP:NOTDEMOCRACY. Separate from any social media integration topics, there is using input buttons (e.g., "like" or "upvote") to help people to prioritize open issues. Perhaps, instead, a drop-down menu could allow contributors to express "importance" rather than "popularity". A drop-down menu could provide contributors with a list of values (e.g., "very low", "low", "normal", "high", "very high") and these, mapped to numbers, could be statistically aggregated from across populations of contributors choosing to use the menu. With some solution, in these regards, contributors viewing lists of issues could additionally sort them with respect to "priority". Also, maybe, via a new special page, contributors searching for tasks could algorithmically sort issues from collections of articles using multiple indices. What do you think? AdamSobieski (talk) 17:54, 6 December 2024 (UTC)

I support the general broad idea of having issues for articles but think people should comment not vote or select priorities. Prioritization and stance can both be explained in a comment. Prototyperspective (talk) 17:59, 6 December 2024 (UTC)

Ok. I removed that sentence from this item. AdamSobieski (talk) 04:03, 7 December 2024 (UTC)

Great, thank you! Supporting this wish and it could substantially increase participation and quality of articles. Lots of flaws in articles are already pointed out on Talk pages but don't get looked at or fixed where having them be issues would help a lot and it would also make it easier to start contributing where you propose changes for a while and let more experienced users decide about and eventually integrate it by which one can learn more about Wikipedia editing to eventually edit articles more directly. Prototyperspective (talk) 10:58, 7 December 2024 (UTC)

@AdamSobieski: As your wish is now declined and voting now open, you may be interested in checking out these two wishes linked above

I think together when combined with the WhyNotResolve gadget (which can be used to mark threads as solved) they could add some issue tracker functionality.

I think this is an important topic, just the wish here is not feasible. Maybe you have some feedback like further ideas on these wishes. Another note to make is that we already have way too few users going to talk pages, if it's even split up into 2 pages, it would be even fewer participants for each. Btw, the unsolved issues per article usually is too large to show it on the article page I think.

There already are hatnotes about various types of issues on the talk page like proposed article renames. One idea I'm having writing this is maybe having hatnote that displays titles of the talk page (one at a time) – maybe just during some campaign like a 2-week-long "Talk page participation campaign". Prototyperspective (talk) 00:42, 19 December 2025 (UTC)

@Prototyperspective, thank you for indicating those related open wishes.

This one started with considering issue-tracking systems on other popular platforms, e.g., GitHub, and then built upon those concepts, envisioning that issues could contain content selections from pertinent articles.

As considered, editors would be able to receive warning popups when their tentative edits involved content that other end-users were in the midst of discussing in one or more of the article's open issues. As envisioned, editors would be able to override, or click to bypass, such warnings, in which case those subscribed to the one or more pertinent open issues would be able to receive alerts.

Another idea: end-users could add comments or annotations for selections of articles, from the article pages, and these could be processed (spam-filtered), and then stored, somehow, in the talk pages – perhaps in a generic catch-all section titled "Comments"?

Instead of end-users having to gesture (mouse, multitouch, etc) to select arbitrary spans of hypertext (which can be challenging on some devices), perhaps end-users could simply gesture or click to comment upon individual sections or paragraphs of content.

While articles' sections already have [edit] hyperlinks, perhaps they could have [comment] hyperlinks?

Also, there might be types of comments, e.g., factuality-related, grammar-related, spelling-related, and so forth. Some comment types might not require end-users to type a message. End-users could quickly gesture on a section or paragraph, select a comment type from a drop-down menu, and then click a button to post their comment.

After making a comment, perhaps end-users could be navigated to articles' talk pages to view their new comment at the top of the "Comments" section of the article's talk page.

I wasn't aware that talk-page usage was decreasing. While talk pages have come a long way over the years, it may be the case that there are yet more user-friendly and approachable user experiences to consider. Perhaps such user experiences might resemble those that new end-users are already familiar with, e.g., from social media, forums, or bulletin-boards systems?

I like the idea of exploring "carousel hatnotes" for articles. AdamSobieski (talk) 04:12, 19 December 2025 (UTC)

I wasn't saying talk page usage is decreasing, just that participation there usually is very low. Making it easier for more people to add more comments isn't helping that – quite the opposite, it would result in more content on the talk pages to sift through etc. People can comment on the talk page about specific parts by linking to sections and/or quoting parts (maybe using {{Tq}}). Especially spelling and grammar issues should just be corrected; see en:WP:SOFIXIT. Commenting without visiting the talk page first to e.g. find a thread already about what you're asking/posting about wouldn't be a good thing. Regarding the carousel hatnotes idea, I don't know where to best propose it – maybe not the wishlist since it's not largely a technical wish but a wish for a campaign. Some technical development would be needed to fetch the section headers from the talk page and display them in the hatnote. Probably there would be some opposition to that idea claiming it would be distracting or something. Also one would need to filter away threads that have been solved or aren't valid matters that relate to the article content etc such as the bot notifications about changed external links. Prototyperspective (talk) 20:05, 19 December 2025 (UTC)

Ok, I understand now; talk-page usage is not decreasing but is low. I was thinking that commentability could drive interaction and traffic to talk pages, but I see your points. Maybe if comments could be algorithmically grouped together or aggregated, with comments automatically upvoting or adding signatures to already existing ones that were very similar or identical.

In addition to searching through and automatically sorting talk-page sections (e.g., post volume/popularity, recency/freshness of posts, hotness/rising popularity, etc.), including for carousel hatnote purposes, perhaps end-users could enter some text command, or use some template, to get a section of a talk page temporarily promoted in terms of its relevance to a search or sorting algorithm – some sort of interplay between a template and an aforementioned algorithm – a kind of exclamation mark. AdamSobieski (talk) 02:32, 20 December 2025 (UTC)

This is a community policy issue not a technical matter

Nothing today is stopping a community that wants to try this from creating a "Issues:" namespace and setting it up. Since it's not clear what technical development is requested here, this never really belonged on the wishlist at all. * Pppery * _{it has begun} 16:01, 10 October 2025 (UTC)

I think it's also a technical issue and in any case within scope of the Wishlist. The idea is to separate out issues from general discussion. However, I think talk pages are already mostly used for that and the reasonable approach would be to have various issue-specific things like marking threads as solved or unsolvable etc or the open unsolved threads counter to talk pages. I think it would be reasonable to archive/decline this rather due to that imho. For example, I don't think Wikipedias can easily add a third article tab for issues next to the Talk page, it would have to be enabled via technical development as the way to submit issues and probably also migration of Talk page threads into issues. Prototyperspective (talk) 16:14, 10 October 2025 (UTC)

Response to the wish

@AdamSobieski Thank you for your wish! The team responsible for this is focused on other priorities and they don't see this as fulfillable based on the direction of the team. To read about what the team is focused on, see the Product & Technology OKRs. Sannita (WMF) (talk) 15:28, 27 November 2025 (UTC)