Talk:WMDE Technical Wishes/Templates

If you have any thoughts about this topic, please add them here.

1. Prototype: Featured Templates and Search Filters

We are looking forward to any kind of feedback. Do you think these two suggestions are suitable to simplify the process of finding the right template and would this make your work easier? Should we follow up on these suggestions? If possible, please tell us if you consider yourself more of a template user or template creator and more of a newcomer or a power user.

• Please leave the Feedback here.
• Background: I am a long-time English Wikipedia editor and a regular user and creator of templates there. I also have some UX design experience outside of Wikimedia.

Comment: The search filter prototype is nominally focused on templates in general, but it is strongly oriented towards the use case of an editor trying to add an Infobox to an article on a subject which they do not commonly edit. That is a very common and viable use case. However, it is somewhat an exceptional one compared to the majority of template usages. Infoboxes are generalised and may be used on almost any article. For non-infobox templates, organising templates by subject matter may lead editors to add templates inappropriately, where previously they never would consider doing so. It seems likely that the identified user issue of "template findability" does not apply to templates in general, but rather a specific sub-set of them.

Navigation templates have a greater scope for misapplication. For example, a user searching for volcano templates for a volcanologist biography may add a footer template on a set of unrelated volcanos (e.g. Template:Volcanoes of Oregon) or on science in general, or perhaps add an Olympics footer on a non-Olympic sports biography. Both those scenarios generate low-relevance links. Editors using series-oriented templates are typically already aware of the article set and do not need assistance to locate them. Most often, a template creator will apply the template on a series of pre-existing articles at the point of template creation, or a user will be pushed to write an article based on a redlink on that template. In my experience, it is uncommon for editors outside their regular topic area to serendipitously write an article which is a gap in a navigation template (which is perhaps the only scenario where a search filter would encourage good navigation template usage). I currently use the "What Links Here" page to identify this scenario. It would be useful for the tool to highlight templates that link to the article currently being edited.

For templates that standardised table or data formatting (e.g. Template:Football squad start), one must take the time to learn how to use them properly, therefore encouraging the user to navigate away from an article to a template documentation page (or reviewing existing usage on a similar article) is desirable behaviour, not a user issue. User design should not push users away from such learning experiences.

Many other of the most common templates (such as disambiguation, hatnotes, Commons, Project and Portal navigation templates, IPA pronunciation templates, and meta templates like authority control) do not fit well into a search use case, as one has to be aware of such templates' existence and purpose already in order to think of using them. Consideration should also be given to the risk of including article clean-up templates in a search filter as there is already concern of Tag bombing and further elevation of clean-up templates would exacerbate that problem in the community.

In light of the above, I would encourage considering limiting this prototype to infobox searching only, plus a general "utility template" grouping for common in-line formatting templates like Convert, Citation, Coordinates, No Wrap, Age, In Language, etc. Possibly a separate stub templates grouping would also be useful (though should be listed separately from content-type templates to encourage good usage). If that model is followed, then a featured template aspect is not required, as the search can push the user to the most relevant infoboxes by subject and an order ranking infoboxes by usage. Otherwise, a featured template aspect would only encourage misapplication of non-relevant navigation templates. Sillyfolkboy (talk) 01:21, 27 March 2020 (UTC)

It's a cool idea in general, but once the infrastructure for this is done, the frontend would have to be reimplemented for each and every wiki, introducing inefficient code forking along the way. And smaller wikis in which there are no people who can implement this won't enjoy this feature at all. It's a huge waste. Templates should be made global first. --Amir E. Aharoni (talk) 12:53, 28 March 2020 (UTC)

@Amire80: I also support this view. Delivery of this prototype before globalisation of templates (which is clearly desirable) would limit it to usage on the small number of wikis that have the ability to localise it. If template globalisation occurs first, the scope, benefit and implementation/maintenance cost of this prototype would be hugely improved. This also completely changes template use cases, as work completed by a user in an article or template in one language could be suggested for use to an editor in another language. Sillyfolkboy (talk) 14:21, 28 March 2020 (UTC)

+1 for template globalization as the priority. -- Dave Braunschweig (talk) 19:56, 30 March 2020 (UTC)

• I'm a longtime editor and have done plenty of template work and Lua scripting. I see the problem here as poorly defined: we have a few separate problems that could be addressed through such a feature:
  1. finding subject-specific templates, e.g. infobox specializations, {{chem}}, etc.
  2. finding general-use formatting templates, e.g. {{nowrap}}, citation templates, etc.
  3. searching for how to do something with templates in general
  My first thought is that some of this is problematic because different communities have organized around differing formatting strategies, so globalization is tricky: the best bet is likely for a general-formatting-template system (2) to be curated mostly manually by language edition. On the subject-specific stuff (1), this might be doable by associating categories with sets of templates, but some of the problem overlaps with (3) where it falls into a more general problem of "template search". I see (1) and (3) as hard problems, since they'd present newbies with too many options to be helpful in many cases, but (2) might do well on wikis where certain page elements are standardized, like the use of hatnotes (i.e. {{main}}) as part of summary style on the English Wikipedia. {{Nihiltres |talk |edits}} 20:36, 31 March 2020 (UTC)

  ... Yes, and all of this is precisely why the option of making templates global has to come first. It's tricky, indeed: it's tricky to make the infrastructure for this, and it's tricky to migrate the templates that should be global to that infrastructure once it's created. Tricky, but possible and necessary. Only after this happens it will become easy to see which templates should be global and which shouldn't.

  We already have an example of a group of templates that can be easily found and inserted: The citation templates, using the Cite button in Visual Editor and in the 2017 wikitext editor. This is an excellent feature, but the trouble with it is exactly the same: it has to be configured by writing weird Citoid JSON files separately in each wiki. These JSON files are code, and this code is forked in an extremely non-robust way. And wikis that didn't configure them, don't have this button at all, and these can be wikis that are otherwise active, such as Malay (ms) and Danish (da). The reason they don't have this JSON configuration is that for some reason didn't write the JSON files, even though they do use Cite book and other templates, and they are very similar to what the English Wikipedia has. And sure, some citation templates are unique in some projects, and this is fine—they can stay unique. But many citation templates are the same, so their JSON configuration should be shared.

  The feature proposed here will have the same problem, but it will make it much bigger: Thousands and thousands of lines of code will have to be written separately for each wiki to make this feature work, and a very large part of that code could be shared.

  In conclusion, it makes a lot more sense to build the infrastructure for shareable templates before building the infrastructure for featured templates. --Amir E. Aharoni (talk) 11:52, 1 April 2020 (UTC)

By the way, I probably didn't make it clear enough that the proposed idea is generally great. As far as I can see, it corresponds very well to these tasks:

• https://phabricator.wikimedia.org/T55590
• https://phabricator.wikimedia.org/T67173
• https://phabricator.wikimedia.org/T103624
• https://phabricator.wikimedia.org/T103630

It also corresponds nicely to the sections about "semantic" templates in my global templates proposal.

All the above bugs and pages propose somewhat different and very raw ways to resolve this issue. I trust that real designers and engineers in WMDE can choose a good way to resolve it.

Nevertheless, templates should become global before they become semantic / searchable / filterable / featured. --Amir E. Aharoni (talk) 16:47, 1 April 2020 (UTC)

Hi @Amire80:, thank you for these reflections! I've seen some of the on-wiki configuration challenges you mention, in FileImporter's data files, and can appreciate how Citoid configuration has been a barrier to adoption for that project as well.

As a fellow software developer, I'd love to have fewer redundancies and easier sharing between wikis, but I would hesitate to say that shared templates needs to happen, or that it has to come before any other template improvements. My hesitations are, * shared templates is an enormous project that would require many committed resources, * there is no editor mandate to do this, and * there are plenty of serviceable implementation alternatives for "featured templates", which could be done in advance of potential work on global templates. For example, simply mapping "featured templates" and "maintenance templates" etc. categories through Wikidata could be easily scaled across wikis, and provides all the data store we need. This is just a conjecture and not a preferred implementation, of course.

(Disclaimer: I'm on the Technical Wishes team but this post is my personal opinion.) Adamw (talk) 18:22, 1 April 2020 (UTC)

shared templates is an enormous project that would require many committed resources - did anyone estimate how much? Is it much more than this project? Is it much more than all the time that will be spent by volunteer editors who will be customizing these configurations on each wiki?

there is no editor mandate to do this - Oh no, there very definitely is editor mandate to do it. It was the 3rd top wish in the 2015 community wishlist vote, and it was supposed to be done, but ended up not being done for some organizational reason that I don't totally understand, but it's still totally relevant. My recent proposal also received considerable support and practically no objection (I "cold-called" lots of people and groups and the only objection I've heard till now had already been addressed in the text). A similar proposal called Global-Wiki, in which I was not involved at all, received a lot of support as well. It has been requested since at least 2004 for templates and since 2012 for modules. So no, saying that there is no editor mandate to do this is just not true. There is.

simply mapping "featured templates" and "maintenance templates" etc. categories through Wikidata could be easily scaled across wikis - yes, this would be good if it reuses existing categories and structured data on the wikis. But getting people to create new local configurations, as it was done for Citoid, will be wasteful and non-robust for the big wikis, while the smaller wikis will, as almost always, be left to their own devices and will not enjoy this feature. --Amir E. Aharoni (talk) 19:12, 1 April 2020 (UTC)

WMF Community Tech's team assessment of the 2015 wish is a good if short summary of the challenges facing global templates, and seems like a reasonable explanation for why the project is stalled.

Thank you for championing code reuse and writing such a thoughtful and detailed proposal for global templates. Given the complexity of this effort however, do you see my point about wanting to decouple it from a much simpler feature? Please understand that I'm in favor of global templates in the long run, but also interested in the lower-risk improvements we might be able to make in the meantime, and with limited resources.

Another perspective I'd like to add is that we can do certain types of cleanup now, which will make it easier to share templates across wikis in the future, with or without a formal system for interoperation. For example, by consolidating many slightly varied templates into a smaller number of templates with configuration or parameters to provide the variations, or separating wikitext presentation from Lua logic. "Featured templates" could serve as one of these intermediate steps, since it would focus more attention on a smaller set of templates, and it would become clearer which are the essential templates for a new wiki to adapt. I share your hope that we could implement this feature in a way appropriate for smaller wikis with fewer template maintainers. Adamw (talk) 21:10, 1 April 2020 (UTC)

WMF Community Tech's team assessment of the 2015 wish is a good if short summary - This assessment, which is indeed very, very short, mentions the Shadow namespaces RFC, which would give an actual assessment of the technical architecture to develop this. This RFC is dormant, and the reason it is dormant is that the project is not prioritized. So we are stuck in a loop: we don't prioritize it because we don't have a technical assessment, and we don't do a technical assessment because it's not prioritized. How can we break out of this loop? Watch this video until the end to get an idea for the answer.

Doing the feature proposed here before making templates global will benefit the big wikis that have the people who will write the necessary local customizations —and there is little doubt they will be necessary—, but it will widen the gap between the big wikis and the small wikis, and make the implementation of global templates even harder than it is now. If you support global templates, you should support having them now and not in the long run. This should have been done in 2004, at the same time when images became global with the creation of Commons. And if not in 2004, then in 2015. And if not in 2015, then in 2020.

Another perspective I'd like to add is that we can do certain types of cleanup now, which will make it easier to share templates across wikis in the future, with or without a formal system for interoperation - projects in which there are enough wikitext experts are already doing it. This is certainly true for all the languages I know: English, Hebrew, Russian, and Catalan. Unfortunately, as far as I can see, only in Catalan this is done with the explicit goal of eventually going cross-wiki, and in the other languages these people are focusing on internal consistency. I don't see how will the featured template project make it better at this stage.

What you can learn from this, however, is that template maintainers would be totally on board with making big changes in the templates they have to make them more robust if the change is worth doing and they have good tools to carry it out. --Amir E. Aharoni (talk) 12:40, 2 April 2020 (UTC)

Given the big, and somewhat surprising, discussions about Wikilambda in the last few days, I've changed my mind about this a bit. It's far from being certain, but at the moment it sounds like the people behind Wikilambda have a serious intention to implement global templates or something very similar as part of their project. If it indeed happens, it is great, and the proposal here will definitely become relevant. However, I still strongly recommend targeting the global repository with it, so that we won't get stuck in a situation where we have different featured tempaltes and search filters for every wiki that would have to be later transitioned to the global repo. --Amir E. Aharoni (talk) 16:55, 8 May 2020 (UTC)

My idea

Hello, I have an idea to unify some templates on all wikis such as infoboxes. And each wikis would only create a linguistically relevant content for the article. This would make the translation easier. The names of the template parameters could also be translated to make it easier for editors who don't know other languages and they would work like [[file:]]. It doesn't matter what wiki we put the translation of this syntax in anyway, the file will be inserted correctly. Krzysiek 123456789 (talk) 23:02, 5 April 2020 (UTC)

My idea was also copied for discussion about other users idea https://www.mediawiki.org/wiki/Global_templates/Discuss I recommend you check this proposal because it has IMO strong support. --Krzysiek 123456789 (talk) 11:31, 19 April 2020 (UTC)

Prototype 2: Improve Syntax Highlighting

We would like feedback from any users familiar with template syntax, whether you are comfortable writing it from scratch or if you only rarely use nested templates or edit templates.

• Would you find these changes helpful?
• How would it impact your interactions with templates?
• Which proposal are you most excited about?

This is a good thing to work on. Highlighting the closing bracket when the caret is on the opening bracket would be (2b) would make all the editors' lives so much easier.

However, I do have a few comments. In order of priority, starting from the most important:

1. Syntax highlighting doesn't work at all on right-to-left wikis. Please, somebody, get that fixed. Otherwise, one of the guiding principles is violated: "When we consider the community as a whole, we aim to consider all its languages and geographies and to avoid global initiatives that favor communities speaking only our languages." (And yes, it's a WMF guiding principle, but everyone in the movement should follow it.) See https://phabricator.wikimedia.org/T170001
2. Bracket closing (2c) is a legitimate feature for people who like it, but I don't like it. I'm not alone: search the web for "turn off bracket closing atom" to see an example of how many people don't like it in just one code editor. I turn it off in every code editor that I use. If you implement it here, it must be possible to turn it off (and leave the rest of the syntax highlighting feature on).
3. A very annoying feature of the current syntax highlighter is that it increases the font size of the section headings. Wikitext is like source code, so all the text is supposed to be of the same size.
4. Evidently, it's possible to have syntax highlighting for MediaWiki's wikitext, because it is available in the page editing textarea. However, it doesn't work as a possible language attribute value for the <syntaxhighlight> tag. It would be very useful for help pages for editors. See https://phabricator.wikimedia.org/T29828
5. I couldn't find how to make syntax highlighting work in the New Wikitext Editor, also known as the 2017 wikitext editor. It's probably impossible at the moment, and it would be very nice to make it possible.
6. I use the LanguageTool add-on in Firefox. It suggests spelling corrections. If I click a suggested spelling correction while using a wikitext editing textarea, the word is changed in the textarea, and then immediately goes back to the previous wrong spelling. This works correctly while not using syntax highlighting. I'm not sure who to blame for this bug, but I'd say that MediaWiki's syntax highlighting is definitely related. And sure, it's not an issue that affects everyone, but I'm mentioning it anyway ;)

Thanks! --Amir E. Aharoni (talk) 11:16, 30 April 2020 (UTC)

I have a question: will the proposed highlighting changes just affect highlighting within templates, or will they affect the rest of the wikitext as well? It would be helpful to see what the proposed changes would mean for the rest of the text. — Toughpigs (talk) 16:12, 3 September 2020 (UTC)

Hi @Toughpigs:, thank you for your question and suggestion! The intention is to make the syntax highlighting changes available in all namespaces, if useful, so we will test them both on template wikitext and on other forms of wikitext. I hope this answers your question! Any feedback or suggestions about this approach is very welcome. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 08:47, 10 September 2020 (UTC)

Prototype 3: Improve working with templates in Visual Editor

All of this looks great to me. VE is very useful for inserting and editing templates, but some things could be polished.

Some particular comments:

• 3.1 Better help text. The text says: Currently, the name of the template appears twice. In the proposal, the icon and title are changed to describe the section more clearly and guide you to the right place when you are looking for help. Initially, I couldn't understand what does this mean. After running VE on a test page and adding a template I understood it. To make it easier to read, can you add screenshots of the current situation and the proposed state?
• 3.2 Required parameters Excellent! More descriptive text and less dependency on icons is generally a good thing.
• 3.3 Eliminate [[ ]] button Probably OK, but check with the original designers. Perhaps they had a reason for this.
• 3.4 Make instructions more visible Yes yes yes, one of the most important things. It often bugs me, and I don't know why haven't I bothered to report a feature request about it. This does require a bit of design however. For example, occasionally the instructions can be long.
• 3.6 Drop down menu Also a thing that I'd really love, and a lot of other people. There is an old request for it: task T53375. An important comment though: This list must be not only selectable in VE, but also conveniently editable in the TemplateData editor.
• 3.7 Improve autocomplete Huh, I thought it's there already for some reason, but apparently it isn't. Would be very good. Note, however, that some templates want a parameter value that looks like "[[File:Example.jpg|thumb|300px|Example caption]]", some want "File:Example.jpg", and some want "Example.jpg". Unfortunately, it's not standartized. I guess that the latter can be handled most easily, but make sure that you support the other options, or that you at least don't break them.
• 3.8a Add buttons to use existing Visual Editor media selector It's also good, although I'll just comment that there are a couple of things to fix in the media selector itself. For example, the automatic search for the article title has never been really useful for me, but it does take a few seconds. But it's OK if it's not a part of this project.

I cannot really select the one most important thing, they are all good.

However, can I ask for a few more things, all of which should be quite easy to implement?

1. Add citations without <ref> tags. Very often want to use the "Cite" button to mention a book or in the Bibliography section, or a website in the External links section. The Cite button is very useful for auto-generating whole Cite book and Cite web templates, but it always puts them in <ref> tags. To add them without the <ref> tags, I have to add them as a ref, and then edit the source to remove the tags.
2. Don't add parameters without values. Currently, if a parameter is suggested, but not required, and the editor doesn't fill anything, it is added without a value. It would be better to just not add anything at all. (Or maybe the TemplateData could specify what to do with such parameters: add as empty, or not add at all.)
3. Allow changing the name of an already-transcluded template without changing the parameters. Currently in VE, I can change parameters in the template editor form, but not the template title. Sometimes there are templates that have the same parameters, but a different title, and I'd love to be able to change just the title. To do this now, I either have to edit in source or to copy the parameter value, insert the new template, and paste the values there.
4. Edit the whole transclusion as wikitext, and not as a form with parameters. It would look similar to "Hieroglyphs", "Musical notation", or "Code block": A simple bubble where you can edit the transclusion's wikitext source. I often miss it. Currently I have to switch to wikitext editing to do this. (If you implement this, it will also mostly cover the previous point about editing the title, but implementing that point separately can be nice, too.)

Thanks! --Amir E. Aharoni (talk) 08:58, 30 June 2020 (UTC)

Prototype 1 Update: Template Finder

(Meta-comment: I honestly don't know why aren't other people commenting here. I tried telling this to some people, but no one else is coming.)

I watched the video for the "Prototype 1 Update: Template Finder" by Elisha Cohen.

It looks kind of nice, but if I look at the details, I find all kinds of things that may not work entirely well when this is deployed.

Entry point: The video shows the VE template insertion dialog as the entry point to this search page. It's OK to have a link to the search page from this dialog as an entry point, but in this form it appears to be targeted primarily at casual editors who don't know a lot template names. I doubt that taking them to this complex search page with a lot of fields will actually help them discover templates, and it may seem too complex. The only good solution for casual editors is not an advanced search form with a lot of fields, but toolbar buttons that say "Insert Infobox", "Insert 'citation needed'", "Insert quotation", etc. There is one such button at the moment: "Cite". It's only available in wikis that bothered to configure Citoid. Doing something like this for more templates is very desirable, but it will be reasonably feasible and scalable only once templates are global.

Target users: It's kind of the opposite from what the declared goals of this project are, but this search page itself looks very useful for experienced editors and template maintainers and less so for casual editors. It will be good to implement it, but the target user persona should be updated accordingly. Otherwise not a lot of people will use it: for casual editors this will be too complex, and advanced users won't even know about it, similarly to how a lot of experienced template maintainers don't know about TemplateStyles, even though it's very easy and useful, and not even about TemplateData, because they don't use VE much.

Filtering by existence of TemplateData: This is kind of similar to what I asked for at task T87444. It would be useful, but only for advanced users, who know about TemplateData, who are able to edit it, and who are willing to do it. This reduces the potential users of this feature by a lot. So, while I do think it's useful, and I'd definitely use it, don't expect many users. Again, the tragedy of TemplateData is that its existence is useful for people who edit in Visual Editor, and experienced template maintainers don't often edit in VE. Chicken and egg ¯\_(ツ)_/¯

Filtering by "type" and "page type": This looks like one of the most useful things, but only in the long run. To actually become useful, these types must be added first. There are more than half a million templates in the English Wikipedia, almost 150,000 in the Russian, almost 80,000 in the German, and so on (please correct my queries if they are wrong! I'm a very bad coder). Until these types are added, these search results will not be very useful. And sure, maybe they don't have to be added to all of the hundreds of thousands of templates to make this feature useful, and maybe just categorizing the top 10000 will already make a difference, but you would need to define what does "top" mean, and you would need tools to perform this efficiently.

So, at the first stage I'd recommend focusing on making very cool tools that help template editors to add this information. By "very cool tools" I mean tools that make the relevant people feel that it's fun to use them to take the number of templates without a type in their wiki from 0% to 5%, from 5% to 20%, from 20% to 100%. And I'm sorry I repeat myself so much, but it will be much more clever to get volunteer editors to do this categorization work after moving as many templates as possible to a global repository. Doing it on every wiki separately will waste literally thousands of volunteer hours on adding the same type to functionally the same template in different languages. This time could be better spent writing articles, fixing other bugs, or moving the templates to a global repo.

Filtering by category: This is one thing that actually has a good chance of working, because on the more active wikis all templates usually belong to categories. However, by itself this feature is redundant, because editors can simply use category pages to look for templates that they want. This can become truly useful only when used together with other search parameters, but as you can see above, they are premature.

So... a very nice idea, but I doubt that in this form it will work well in the real world. --Amir E. Aharoni (talk) 12:09, 14 July 2020 (UTC)

thanks a lot for the feedback @Amire80: and also for telling people about our project. Much appreciated! Robin Strohmeyer (WMDE) (talk) 05:53, 22 July 2020 (UTC)

Weiter

Hi User:Max Klemm (WMDE),

Not a mega-disaster, but on the survey, which is mostly in English, the "next" button is labeled in German: "Weiter". There's also a "Zurück" button for "back", and the final landing page after submitting the survey is all in German. It would be nice if you could fix it and a have a consistent language.

Thanks :) --Amir E. Aharoni (talk) 11:02, 14 October 2020 (UTC)

Hi @Amire80:, thanks for letting me know. I corrected it! The buttons should be in English now! -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 08:37, 15 October 2020 (UTC)

Syntax highlighting on RTL wikis

Max Klemm (WMDE), Michael Schönitzer (WMDE), Johanna Strodt (WMDE), what exactly is the issue with making syntax highlighting work on right to left wikis? --Amir E. Aharoni (talk) 08:10, 29 January 2021 (UTC)

@Amire80: Reading phab:T170001, it looks like the WMF's Community Tech team encountered problems in 2018 when they were implementing Syntax highlighting for our wiki projects, using CodeMirror. Apparently, there are bugs concerning RTL support in CodeMirror itself. But I'm afraid I can't really tell you more than what's in the ticket. I'll ask around if anyone has more information. -- Best,Johanna Strodt (WMDE) (talk) 08:56, 29 January 2021 (UTC)

Global templates, TemplateData and Wikifunctios wiki

I am.experiemcing with mw:Extension:TemplateData to make template translation and common functions comfortable. See also : mw:Global templates, Wikifunctions (partial work, only for mathematics and similar) and its wiki: https://notwikilambda.toolforge.org/wiki/Main_Page where we can make tests. I love Technical Wishes Templates (TW Templates) makes big improvements as an important part of this trend and effort. BoldLuis (talk) 06:18, 24 March 2021 (UTC)

@BoldLuis: Thank you for your comment! I'll pass it on to the rest of the team. -- Best, Johanna Strodt (WMDE) (talk) 08:56, 24 March 2021 (UTC)

@Johanna Strodt (WMDE):. Thanks to you, for your good work. The best I know for global and easy templates. --BoldLuis (talk) 12:16, 26 March 2021 (UTC)

An idea for TemplateData

Hey! Some parameters are multiplied to add new instances to a list, such as "image1", "image2", "image3". There should be an option on TemplateData to work better with that, like a button "add another image" (or "add another instance of this parameter"), where the TemplateData definition someway indicates that there are x parameters that make the same thing. I don't know if you understand this. Also, i have an idea for what i call "Parameter Groups", and that could be useful on templates like start-about-end, like a group for each related page.

"For {{{other_uses1}}}, see {{{page1}}}"

Parameter Group 1: other_uses1 and page1; Parameter Group 2: other_uses2 and page2;

This is just an idea, and probably there are no implementations possible or reasonable for this, but i wrote it down. Thanks. Dr03ramos (talk) 21:47, 17 May 2021 (UTC)

Supporting lots of numbered parameters is tracked as phab:T54582. Izno (talk) 07:01, 26 May 2021 (UTC)

Thank you for your suggestions. Being able to duplicate a parameter to easily add parameters that are similar to each other seems like it could be a useful addition, and your second idea about parameter groups is actually something we also considered early on in the project. We still consider this to be a useful feature, but it unfortunately didn't make our priority list, so we will probably not be able to implement it as a part of this project. Michael Schönitzer (WMDE) (talk) 14:19, 28 May 2021 (UTC)

Improvement the working with colors

Improvement is needed when working with a colors parameter, that includes a color name or color code. At the moment the color choice in that parameters is cumbersome. The templates themselves should be used on of the colors picker. Effib (talk) 07:15, 15 March 2022 (UTC)

@Effib: Thank you for that suggestion. Unfortunately, our work in this focus area is mostly done. We are currently in the process of finishing the last projects and will deploy them soon to all wikis. Then we'll move on to our other focus area from 2020 (geo information) and start research on the newest focus area (reusing references). -- Best, Johanna Strodt (WMDE) (talk) 08:36, 15 March 2022 (UTC)

Templates : Detecting if a template is used in a 'nested' or 're-enterant' manner..

Hi. I am mentioning this here in the hope that the issue will be considered at some future point:-

https://phabricator.wikimedia.org/T272718 where a template needed to determine if it was being used in a nested manner ( or in a wider use case in a potentially re-enterant manner, so it could change it's behavior accordingly, such as not generating additional HTML wrappers, or prohibited characters. ShakespeareFan00 (talk) 09:18, 30 April 2022 (UTC)

@ShakespeareFan00: Thanks a lot for your comment! Unfortunately, after more than two years, our work in this Templates project is coming to an end. From now on, we will only be doing some cleanup, so we won't be able to work on this. -- Best, Johanna Strodt (WMDE) (talk) 07:04, 11 May 2022 (UTC)

Templates: "Soft-Newlines"

I am mentioning this here so that the related issues are given consideration at some future date:- "Provide magic word for 'soft' newline insertion from template markup." https://phabricator.wikimedia.org/T253233

Having the magic word suggested, would allow for template writers to be more specifci about desired whitespace handling requriements. ( There is a related doLevels concern on Phabricator as well. https://phabricator.wikimedia.org/T134469 ) ShakespeareFan00 (talk) 09:26, 30 April 2022 (UTC)

@ShakespeareFan00: Thanks for this comment, too. We actually considered this suggestion in the research phase in 2019. But we had to determine which of the many ideas we could pursue, and this didn't make the list, because the other projects had even higher potential to be helpful for more people. -- Best, Johanna Strodt (WMDE) (talk) 07:09, 11 May 2022 (UTC)

Templates: Provide a clearer way to distinguish between "absent" and empty/blank parameters when handling them in templates and parser functions...

2 related Phabricator tickets:- https://phabricator.wikimedia.org/T196440 https://phabricator.wikimedia.org/T162375

Currently when calling templates in a nested manner, it is sometimes necessary to specify a value as a valid but empty value, and test for that in the called template, when the called template logic could be simplified if the calling template could indicate in some way that the nil or default value for a paramater in the called template should be used, when expanding.

The idea here is that where an called template has something like : {{{foo|0}}} the calling template could use something like foo={{{foo|{{#nil}}}}} to tell the called template to use it's default, rather than foo={{{foo|}}} as currently which supplies a valid but 'blank' entry. This would enable the logic of the called template to be simpler. ShakespeareFan00 (talk) 09:47, 30 April 2022 (UTC)