Talk:Community Wishlist/Focus areas/Template recall and discovery

Notifying focus area contributors

Hello @TheDJ, @Elilopes, @Steven Sun, @Omar.idma, @Adam Cuerden, earlier this year we notified you that the wishes you submitted to the Wishlist would be bundled into project called the Template Picker Improvements project as an example of a focus area for the Wishlist that would be launched.

The project has now been posted on the new Community Wishlist as Template recall and discovery focus area. Please visit the focus area page for the latest information.

Thank you –– STei (WMF) (talk) 12:16, 10 September 2024 (UTC)

Replacement for User Message gadget

The design mockups look like this would not only be nice for the article namespace but could also be a good replacement for the commons:Help:Gadget-UserMessages for putting templates on user talk pages. The UI of this gadget is outdated and favorites would be a very nice feature. GPSLeo (talk) 18:32, 13 September 2024 (UTC)

Thanks @GPSLeo - for now, we are focused on the core experience of templates in the dialog. We could share some patterns with the developers interested in updating commons:Help:Gadget-UserMessages. JWheeler-WMF (talk) 19:55, 13 September 2024 (UTC)

With core experience you mean article namespace on Wikipedia? I think the main difference is the list of templates they are suggested. And differentiation of the templates is needed anyways as you do not want the message templates suggested in article namespace. GPSLeo (talk) 04:53, 14 September 2024 (UTC)

Our scope is limited to updating the dialog to help people find and insert templates. If there's appetite to leverage the UI for the UserMessages gadget, it'd be up to the team/individuals responsible, or I'd suggest writing a new wish! JWheeler-WMF (talk) 21:21, 16 September 2024 (UTC)

Types of templates

It seems that the template model being demonstrated here is a big and flashy thing like an infobox. I'm not sure that that's the thing people are most interested in adding (that is, with highest frequency, for new editors and/or those using the VE). Although it is a template with a lot of variations, and subtemplates with inheritance, having a menu selection for any type of editor would help its usability immensely -- and there are a couple other templates that are like that as well (mostly I can think of text formatting variants used in talk and documentation pages like ((tl))+x).

But for what I'd want to see new editors use, and what I have to look up most frequently (syntax especially), are inline markup templates such as ((ill)), ((units)), ((lang)), ((daterange)), etc.. When not templated, this stuff can also be the most difficult to patrol for automatically or even with a quick eye scan. You all have done a great job I think of getting new editors to use citation templates, so these other inline templates I think are also very valuable to encourage and would be a good design goal. (Hopefully there's also a complementary essay on the common necessary templates and how to use them, and if not we should mock one up.) SamuelRiv (talk) 18:38, 13 September 2024 (UTC)

Thank you for sharing this @SamuelRiv. Could you share a bit more about your workflows as you're patrolling in this context? My hunch is that you should consider writing a wish to help patrollers coach editors to use inline markup templates. JWheeler-WMF (talk) 19:56, 13 September 2024 (UTC)

As an example article I'm reading like w:Asteroid, you can see several of the major templates I listed above (plus ((convert)) and ((as of)) and also maintenance tags beyond citation needed)).) (Stuff like nbsp and nowrap may be a bit too esoteric, and are hid anyway with the VE.) Untemplated units and dates conversion can be detected on AWB fairly easily; untemplated foreign pronunciations are possible but more cumbersome, especially names -- people aren't running these scripts now, but we can do it. But placing the ((asof))/((when)) family and the inline ((citation needed))/((fv))/((bsn)) family of tags is not possible with current automated tools. I find the former improve maintenance; not sure if the latter tagging actually improves reader or editor outcomes (I can't find WMF or outside research on that, only the research on readers following citations in general).

For my workflow as an editor, I use exclusively the source editor. Nonetheless I find essential something like ProveIt to plug in a doi or url to populate fields in that editor. I've also liked the template editing features so far of the VE -- I always find myself having to look up documentation of template parameters each time, but the VE interface makes the process a lot more sane. SamuelRiv (talk) 07:25, 15 September 2024 (UTC)

Thanks @SamuelRiv - for this MVP, we're focused on the users who primarily use the VE template dialog, where we see 5,000 users engage daily, compared to 800 on source editor. This is especially interesting given that source editor is responsible for 2x more edits than VE. While it'd be helpful for admins if more VE editors to use inline citations, our stated goal is to increase adoption and usage of templates, primarily for editorial /content purposes.

Additionally, we are not trying to improve documentation of template parameters; instead, we're trying to help editors find templates. JWheeler-WMF (talk) 21:18, 16 September 2024 (UTC)

This is exactly what I said, though. I want VE editors and new editors to find and use templates easily and smoothly (but specifically not just infobox-type templates, as I gave examples). I'd also like that experienced editors to be able to use dropdowns or other UI similar to VE to be able to find templates and their parameters quickly and easily (we can currently do this in ProveIt for citation templates only). SamuelRiv (talk) 18:27, 17 September 2024 (UTC)

Community-defined templates

Hey folks - I wanted to further explain why we're shying away from community-defined templates for the initial feature set of this template discovery work, as @Escargot bleu suggested.

1. Breadth of templates. There are over 30k template categories and 680k templates used at least 5 times on en.wiki. There are also many different user personas for Templates. For example, content reviewers look for Citation Needed, editors may seek Infoboxes or Navboxes, and admins might seek maintenance tags to prevent abuse. If we allowed communities to define 15-20 useful templates, there's a good chance that the suggested templates may not align to a user persona's goal. Additional tooling may be necessary to customize based on # of edits, user rights, etc.
2. Scale across wikis. While this feature may work for one wiki, it'd require each wiki to adopt and customize their list of suggested templates. This adds additional burden on admins to mantain yet another list. Moreover, it would require WMF to build the infrastructure to store template settings and allow for each wiki to further customize a list.

While a community configuration or community-defined templates may be a long-term goal, we plan to start with lower-effort features that help individual users find templates based on their personal search history, popularity or some form of recommendation engine. From there, we can continue to explore a community-defined list of templates. JWheeler-WMF (talk) 21:14, 16 September 2024 (UTC)

I'm sure you've seen the most transcluded en.wp templates and modules list. It can be somewhat deceptive because of the way some templates use inheritance or base modules, while some very popular classes of simple templates (very few nowadays) will have no such structure that is visible in this list. So from there you only need to consider what functionality you want for the major top-level helper templates+modules (to be eventually used in article markup): ((fix)), ((CS1)), ((infobox)), ((navbox)), ((date)), ((lang)), and even visible banners like ((asbox)). I'm sure nobody really would mind, in the near term, that the vast majority of templates not on this list aren't considered or even supported in dropdowns, if are you able to add significant functionality to finding those in the classes of just a handful of the major modules. SamuelRiv (talk) 18:53, 17 September 2024 (UTC)

Inline template autocompletion/search

The design explorations look good. It would also be amazing to have access to template autocompletion or search inline. After typing {{ (including in the visual editor), a pop-up could open under your cursor and help you find the template as you type its name, or part of its name or alias, or select a recently used or favourited template. In a non-intrusive way for editors who know what they are inserting, but in a helpful way for everyone to quickly retrieve the right template without clicking on buttons or opening a big overlay. Nclm (talk) 09:48, 17 September 2024 (UTC)

One challenge I see with this is that many folks still configure templates via the existing modals in VE and Source Editor. A shortcut to pick a template inline could be a nice affordance, however first we want to explore how we might signal more accurate or relevant templates. From there, we might explore more in-line capabilities. JWheeler-WMF (talk) 14:32, 17 September 2024 (UTC)

templatedataHint

Not focussing on searching, but adding TemplateData descriptions might improve search result feelings.

Please see w:en:User:PerfektesChaos/js/templatedataHint.

Greetings -- PerfektesChaos (talk) 14:48, 17 September 2024 (UTC)

Smart searching

German Wikipedia has some support to find the appropriate template:

• Non-existing template yields empowered search form.
  • Try w:de:Template:Encyclopædia-Britannica (but make sure that German is user language for testing).
  • No match, but a search form with a list of separated keywords derived from guessed template name.
  • Clicking the button delivers three possible templates, but no noise.
• Specific search form is adding some features:
  • Suppress /doc subpages.
  • Prefer templates with TemplateData.
    • All templates with some 50–70 direct transclusions in articles are equipped with TemplateData.
    • That is the community preference to suggest most likely searched templates for all needs.
  • Prefer templates with separate /doc subpage if not TemplateData.
    • All really important and frequently used templates do have a separate /doc subpage.
    • Almost all reasonable templates with parameters have a separate /doc subpage.
  • In third place, show all other ones.
    • Navboxes with no parameters and a dozen transclusions have no /doc subpage. These are 50,000 templates, and nobody can predict which one is searched next. Their name is self-explaining.
• All categories are offering that special search form.
  • E.g. w:de:Category:Vorlage:Zitation/Enzyklopädie prefers sub-categories of that category (none in this case), if no matches then fallback to global template search.
  • Starting at root w:de:Category:Vorlage: everybody might follow the branches if there is a certain idea where located.

Enjoy -- PerfektesChaos (talk) 19:13, 17 September 2024 (UTC)

I think these are all very good suggestions, I hope this project takes notice. Thank you for linking to that non-existing template UX. —TheDJ (talk • contribs) 07:45, 18 October 2024 (UTC)

Bugs in the VisualEditor

Before implementing these solutions that will allow more users to use templates, check the VE and TemplateWizard for normal operation with template data please. It may be necessary to replace the internal VE solution (https://phabricator.wikimedia.org/tag/visualeditor-mediawiki-templates/) with an TemplateWizard extension.
https://phabricator.wikimedia.org/T54582
https://phabricator.wikimedia.org/T55613
https://phabricator.wikimedia.org/T335986
https://phabricator.wikimedia.org/T54582 Iniquity (talk) 19:04, 25 September 2024 (UTC)

@Iniquity Can you please state the problem, before bringing a solution ? I'm completely unclear what you are trying to point out, even with the linked tickets. —TheDJ (talk • contribs) 14:36, 17 October 2024 (UTC)

@TheDJ Templates in the visual editor are one of the WMF's abandoned projects. Popularizing work with templates when half of the TD is processed incorrectly or when there are about 100 unsorted tasks on the board is a bad decision. Iniquity (talk) 18:24, 17 October 2024 (UTC)

I think that is like saying you shouldn't build a new building in a neighbourhood where the grass isn't being cut. If anything taking on a project like this can be a catalyst to deal with some of those issues. —TheDJ (talk • contribs) 07:43, 18 October 2024 (UTC)

I prefer the analogy that you shouldn't move people into houses where the plumbing leaks, the meters malfunction, and some doors won't open. Iniquity (talk) 08:43, 19 October 2024 (UTC)

Is there an universal solution? Private names for templates

Could there be a pattern that helps for many points given? Assume a page user:name/templatelist exists and is shown as a menu to select templates from. At the same time it is a list of favourite templates which would make them priority in searches. Then there could be a prefix user:name/templates/ where a user can store redirects to "misnamed" templates. Of course the user can use the redirects in its templatelist. All these user-private names are not stored in the article, they are translated at storage to the public names. That is part of the editor. If it is possible, the editor can also translate back. 176.0.157.173 19:35, 10 October 2024 (UTC)

Inline tags

I'd like to mention a related 2020 bug, task T209797, which is about the interfaces of semi-automated tools for reviewing recent edits. It links to previous community discussion and discusses UI ideas in detail. HLHJ (talk) 01:02, 27 November 2024 (UTC)

Further input about potential features to be included

Hello @TheDJ, @Elilopes, @Steven Sun, @Omar.idma, @Adam Cuerden, @GPSLeo, @SamuelRiv, @Nclm, @PerfektesChaos, @HLHJ, we are approaching the pilot phase for this wish, but we need further input from you about potential features to be included in the following iteration of the project.

More specifically, we need to know which of the following features is for you a must have, which one a nice to have and which one is residually important:

• Use a results page rather than a dropdown menu for template search, i.e. opening a tab with potentially interesting templates, instead of displaying the search results in a dropdown menu
• Search template by categories, i.e. update the interface to allow the user to search within a particular category of template, rather than just "all templates"
• Browse by category, i.e. browsing templates in a separate tab by category level and by level of nesting
• Recently searched by the user, i.e. the interface will remind the user of templates they have recently searched
• Preview templates, i.e. give a small preview in the search results of the selected template, that would help the user decide for a template
• Special page where users can remove all favourites, i.e. introducing a button or a function to clear/remove favourite templates, since there could be only a limited number of them

Please let us know what do you think of these functions, as we're going to focus on the most appreciated ones for our next line of work. Thank you in advance! Sannita (WMF) (talk) 13:43, 22 May 2025 (UTC)

• PerfektesChaos (talk) 16:15, 22 May 2025 (UTC)

  Use a results page rather than a dropdown menu

  must have results page

  If available, list description@TemplateData for each entry.

  Prefer TemplateData against non-TemplateData items. They are better maintained and usually more important than an unused wreck.

  A dropdown menu would list cryptic names, QPXC or very long names; Navigationsleiste Autobahnkreuze und Autobahndreiecke der Bundesautobahn 26 and much longer. The “26” is the distinguishing information and must not be clipped.

  Search template by categories

  must have

  In any depth, which might bring deepcat search to break limitations. A structured organisation could exceed 10 or 15 levels.

  “Search” does mean: keyword search, narrowed by category. To select the narrowing high-level category I do need some kind of browsing, always starting from namespace root category.

  Browse by category

  Neither understood nor necessary.

  A category tree for 500.000 or even 100.000 templates needs would need very exhaustive knowledge of branches and principles.

  Article authors are not supposed to know the branches to choose in browsing towards any particular subtree. They know the article categories.

  The template namespace management team might have an idea where a particular template could have been categorized, but they are not the ones to write that article.

  Keyword search is the approach for using, sometimes narrowed by high level categories.

  Sole category browsing until I found the final category where a particular template is residing is terrible. I am categorizing templates for a dozen years now, but I am not able to find 1 % by the category I assigned myself.

  I can use the regular namespace root and could browse to any page as usual. I do not need an additional tool for that.

  Recently searched by the user

  pretty fine

  Collect in browser storage (indexedDB) a unique list of 100 last found templates. Most recent on top.

  The self-learning memory could use a kind of scoring: Every time I have selected a particular template the usage counter is increased +1, and the list is ordered by most recent ones (e.g. first ten), and by simple scoring formula preferring items selected very often, from 11 to 100.

  The [select] click for an item must be caught and added to the most recent list.

  Preview templates

  rather pointless

  I think a wide majority have

  • no visible output at all (format as, specify human language for)
  • a huge appearance, e.g. an infobox with doubled height as browser window for one single template
  • no visual difference; German Wikipedia has > 50.000 navigation bars which might be pretty huge if expanded, and all looking similar at first glance, differing by headline, and by convention headline text shall be the significant template name. I have linked one above for “26” and you might check the previews of all all siblings found by your keyword search.

  I would expect <0,1 % of all templates could show a meaningful preview.

  Special page where users can remove all favourites

  Not really understood.

  Depending on concept this might be meaningful or waste of developing resources and hard to use for regular authors.

  I could imagine to be combined with Recently searched by the user in browser storage:

  • The growing list of interesting templates could offer a button (open star) [add as favourite] turning into closed star [discard as favourite].
  • The favourites (and only those) are collected on wiki server profile of registered users rather than browser storage for everybody.
  • On wiki server profile a unique list of most recent requested favourites is maintained, the freshest one first.
  • When displaying Recently searched by the user the favourites are shown on top, the most recent requested favourites first.

  Other approach: Give templates on my general watchlist a higher scoring in both “recent” and “results”, add regular watch/unwatch stars to result list. No special implementation needed.

  • On my general watchlist I get a list of my interesting templates, and I will be informed if implementation changes.

Per-namespace favorites

Any plans to have the favorites be different per namespace? The templates I'd frequently use on articles are quite different from those I'd use on talk pages, or on user talk pages, or on projectspace pages. -- Ahecht (TALK
PAGE) 17:13, 17 June 2025 (UTC)

Updates regarding this focus area + survey about the feature

Hi all, I wanted to share some updates about the current work on this focus area. First of all, we realised a functional prototype to select templates by categories, thanks to Sam Wilson, during our last Wishathon sprint (see more about it in our last community update). See also the relevant Phabricator ticket.

Secondly, we are running a survey on MediaWiki.org to gather feedback around category-based search for templates. You're invited to take part to it, and share your workflows and opinions about it! (courtesy ping to @TheDJ, @Elilopes, @Steven Sun, @Omar.idma, @Adam Cuerden, @GPSLeo, @SamuelRiv, @Nclm, @PerfektesChaos, @HLHJ as users who intervened in past discussions) Sannita (WMF) (talk) 14:04, 18 June 2025 (UTC)

As long as “category-based search” will include not one particular category to be matched precisely, but any depth level of sub-categorise, this would be fine with me.

If you need the exact identifier of one particular category, such feature would be pointless. You will memorize better the exact name of the template you need frequently, rather than learning in addition precise names of hundreds of categories for templates.

A few category names on top level might be used to narrow a search result, but a search for keywords as first clue and additionally matching a category tree would be helpful.

Just browsing a category tree to find a page could have been done 25 years ago, and would provide all the category descriptions. A new “tool” for the same task will be entirely superfluous and confusing.

Greetings --PerfektesChaos (talk) 14:33, 24 June 2025 (UTC)

Terminology

If this new feature is being advertised as "Favourite templates", can that language please be used on this page explaining the feature? The term "Favourite templates" currently appears only once, as an image caption. When the team uses "Favourite templates", are they referring to a tool that meets all four of the "Wishes in this focus area", or only "Quickly add favorite and related templates"? CMD (talk) 07:49, 28 June 2025 (UTC)

Hi @Chipmunkdavis, sorry for taking this long to answer you. In fact, we also apologise for the confusion around the name of the focus area.

"Favourite templates" is one of the features we've been working on, and relates only to the possibility of inserting a specific template in a "favourite" list. The focus area "Template Recall and Discovery" covers also the other features related not just to favouriting templates, but to browsing and discovering in an easier way the existing templates on a wiki. Some of these new features will be deployed in the next weeks (see also my message below).

I hope this clarifies the confusion! Sannita (WMF) (talk) 14:47, 3 July 2025 (UTC)

New features will be deployed starting from next week

Hi all, two new features related to this focus area will be deployed on all Wikimedia projects, starting from next week.

The first one that will be deployed is the template category browser, which will allow a user to browse a list of templates which have been organised into a given category tree. This will assist editors in finding the correct templates to favourite. The feature will be rolled out next week.

The second one that will be deployed is featured templates, which will allow projects to collectively define a collection of templates which are likely to be useful to its editors. These templates will be displayed in a list, similar to the list of favourites, under the "featured" tab of the template discovery interface. This feature will be rolled out the week after the template category browser feature.

All features are fully documented on MediaWiki.org. Please help us in translating the documentation into your language!

We're happy to hear your feedback about it or to clarify things if needed. Sannita (WMF) (talk) 14:47, 3 July 2025 (UTC)

Show template usage in search

I tried the new favourite feature (which looks neat by the way 👍) and it popped into my head that having an indication of how widely used a template is could be useful. E.g. if you search for "note" because you want to add a generic note there may be multiple templates. Seeing how many times each template is used could help you choose. Of course popularity doesn't mean quality, but it can be an indication. Sebastian Berlin (WMSE) (talk) 10:32, 7 July 2025 (UTC)

@Sebastian Berlin (WMSE) Thanks for your message. I will pass it on to the devs, to see if we can work on adding this info when showing a template. Much appreciated! Sannita (WMF) (talk) 10:36, 7 July 2025 (UTC)

Keyboard support and context-sensitivity

Hiya! Favourite Templates works fine, some small feature requests to make life easier:

• Can we please add the hotkeys to the appropriate tooltips. What is the hotkey to bring up the dialog? Escape closes it, but the tooltip doesn't tell you.

• Can we please press Enter to submit? So let's say for example that I have favourited the Talkback template, it would be nice if I could click it, fill in the username and then press Enter to submit the dialog. I know Ctrl-Enter works, but that is not in the tooltip so people are unlikely to discover that.

• If you search for a template that doesn't have TemplateData it does not allow you to close the dialog with Enter or Ctrl-Enter for some reason. You can try 'talkpagecool'.

It would be nice to be able to do the entire flow without using the mouse. So a hotkey for bringing up the dialog, selecting a template with the arrow keys, pressing Enter to confirm. Otherwise you keep having to move from keyboard to mouse and back.

The suggested templates are currently not context-sensitive, but that would be a nice feature. If I am editing an article it is unlikely that I'll need a user warning template.

Polygnotus (talk) 02:33, 10 July 2025 (UTC)

Hi @Polygnotus, thank you for your feedback! I will report the suggestions to the devs, and see if we can act on them. I hope to let you know more soon. Thanks again! Sannita (WMF) (talk) 16:41, 10 July 2025 (UTC)

Hi @Polygnotus, can I ask you please to write up a Phabricator ticket about your feature requests? It would be useful for us to have one for our work. If you need help with it, let me know! Sannita (WMF) (talk) 10:16, 11 July 2025 (UTC)

@Sannita (WMF) See task T399290 and task T399293 and task T399295. Polygnotus (talk) 11:15, 11 July 2025 (UTC)

@Polygnotus Fantastic, thank you very much! Sannita (WMF) (talk) 13:09, 11 July 2025 (UTC)