@Esanders, @Jdforrester-WMF I wanted to get your thoughts about how easy/difficult it would be to extract out the Insert template module and port it to be a gadget for the old editor. I noticed that there used to be a module for doing this but it doesn't seem to be there anymore. Was it moved to a different repository?
Thanks!

The wish: Infoboxes are useful tools for enriching articles or making them easily comprehensible/accessible. However, it is necessary for the contributor to know the existence of the infobox that interests him/her and to know more about its structure. He will then have to go to the infobox template page, copy and paste the code and fill it in. The most common practice is still to copy and paste it from other articles, which still poses a problem: if the original article had a previous version or an incomplete version of the infobox, it will spread to other articles.

Proposed solution: Create a search function available from the main toolbar when editing an article. This search will allow you to browse the infoboxes (search by title or category) and then directly retrieve the structure of the infobox (in its latest version) in the article.

I had a helpful chat with James about Infobox wizard in VE. It’s a pretty generic Transclusion Dialog which allows editing multipart templates. It’s not feasible to extract the dialog out of VE. It depends heavily on the data model and the other functionalities provided by the editor.

We could write an extension to do this but the amount of work involved here seems fairly small. This project doesn't deal with any databases or user data, nor is it dependent on any other extensions or core functionality. In my opinion, the best path forward is to create a gadget for doing this.

A few possible ways for the gadget to work:

1. Have a search tool in the editor which lets the user search for infoboxes. When the user picks an infobox and clicks "Import infobox" the blank template is copied into the editor. The infobox will be inserted where the cursor last was. The list of templates can be fetched from the API.
   • Pros:
     1. Very simple to build and use.
     2. No complex UI required.
   • Cons:
     1. Often infoboxes have extraneous rows which aren’t really required for a given article. Either the user will have to remove those or they will remain in the wikitext, taking up space.
     2. Might be problematic to control where the template gets added.

2. Have an infobox wizard where the template parameters and input fields are presented in a user friendly way in a JS popup. The user fills in the fields in the popup and when they hit save, the pre-filled template is loaded in the editor. This is similar to what VE does.
   • Pros:
     1. This solves the problem with the extraneous rows. The user can pick and choose which fields they want to insert.
     2. We can show template and field information like here:
        1. 
   • Cons:
     1. It's more work to build, potentially. The template data API (see example) provides template information for a given template.
        1. TemplateData works when templates have the TemplateData blob. It can be enabled by editing a template and clicking 'Manage TemplateData'. It does need manual review though. On wikis other than English, it's not clear how many templates are enabled for use with TD. I did find a couple of templates on Hindi wikipedia which are not enabled to work with TD (it's possible on other wikis too - I didn't find any stats). But if it's not enabled with TD, it doesn't show up for VE autocomplete. I think we should follow the same.
     2. Would need some design input.

Open questions:

1. Even though the wish only talks about having this for Infobox templates, we can build a more generalized version for all templates. This is what the VE transfusion dialog does. The amount of extra work should be negligible. In fact this might reduce the work slightly because we don't need to filter templates for Infoboxes alone. But there is a possibility that some templates might be overly complex etc. Thoughts?
2. This feature would most likely not work for people who haven't enabled JavaScript, as is the case with all gadgets. Is that alright?

@kaldari @TBolliger @MusikAnimal @Samwilson Feel free to shoot holes into this^. Anything obvious that I missed? I don't know a whole lot about templates so it's very possible.

Making this a gadget seems pretty straightforward, especially as there's no required server-side code (which is all provided by TemplateData) but I'd still like to suggest we do think about making it an extension. This is definitely the sort of wizard that'd be useful on lots of different wikis, and with that comes all the usual issues that lead us to wanting global gadgets — and one of the current ways away from those issues is to make gadgets into extensions. :-) Basically, an extension would be more time-consuming to deploy everywhere, but easier to upgrade and much easier to develop (i.e. in a normal dev environment). It would also be more usable by third party installs, and with them comes more developers (hopefully). If it were to be an extension, is there a case to be made for actually just adding the wizard to the TemplateData extension?

As for the actual functioning, I think option 2 is the best, especially as it'd largely be copying the UI of the existing VE system. Could option 1 be a fallback though, for templates without TemplateData? Although, I'm not quite sure of how the wizard would fetch the blank template... there doesn't seem to be a standard way of expressing the blank templates in template documentation pages (this is one reason why TemplateData exists). One way could be to look for /preload subpages, and use those.

Alternatively, I think it'd be fine to ignore templates without TemplateData, because if editors want those to be available they can easily add the required data.

The template search feature sounds brilliant, and I can see the autocomplete-on-template-name being pretty intuitive, but how does category search work? Is there just one input box, and as you type the list of templates under it is filtered, based on title and categories? And I guess it'd ignore parent categories?

I think building an actual wizard/dialog box to let the user choose the parameters they want is going to be the right solution here. Some templates have dozens of optional parameters and people are not going to like having to clean them up manually. Either way, we will be relying on TemplateData so I don't really see that as a "con". (There's no way to automatically retrieve a blank template syntax.)

As for whether we should support just infoboxes or all templates, it seems like all templates is way to go (assuming we're just talking about inserting templates and not editing them which is way more complicated).

I think building it as a gadget is a good proof of concept and once we have something that works we can talk about making it into an extension (or adding to the WikiEditor or TemplateData extensions). I don't think we should worry about supporting non-JS users. They can still add templates manually.

Is porting the existing insert template feature from VE to the current wikitext editor an acceptable solution for this problem?

Note that the "new wikitext editor" (the "2017 wikitext editor" beta feature, which is essentially a wikitext mode for VE) already has a wikitext version of every VE tool, including this one.

In T184145#3953574, @Catrope wrote:

Is porting the existing insert template feature from VE to the current wikitext editor an acceptable solution for this problem?

Note that the "new wikitext editor" (the "2017 wikitext editor" beta feature, which is essentially a wikitext mode for VE) already has a wikitext version of every VE tool, including this one.

Right. The wish is about having this tool for WikiEditor (we suck at naming things). "Porting" here meant extracting out the JS for this tool from VE and using it as a gadget for that. Which apparently is more work than building one from scratch.

You might be able to reuse some of the model code that VE uses for this (ve.dm.TransclusionModel and friends). @Esanders might be able to help.

In T184145#3953629, @Catrope wrote:

You might be able to reuse some of the model code that VE uses for this (ve.dm.TransclusionModel and friends). @Esanders might be able to help.

Thanks Roan! I'll shoot Ed an email to get his input.