Last modified: 2014-05-19 07:37:23 UTC
Created attachment 12635 [details] screenshot of nested templates in VisualEditor Templates are sometimes nested into one another. For example, https://en.wikipedia.org/wiki/Template:Chembox relies on sub-templates like https://en.wikipedia.org/wiki/Template:Chembox_Properties , which itself relies on other templates etc. VisualEditor currently doesn't seem to handle these sub-templates. It shows a nice interface for the top-level template, then shows wikitext for the others (see screenshot).
These are currently supported, just as wikitext. :-) It depends on some changes in Parsoid (which they've put on ice during deployment), and some tweaks in VisualEditor, but this should be relatively do-able.
*** Bug 50355 has been marked as a duplicate of this bug. ***
This bug affects all attempts to edit items in lists which are set out in columns using {{tl|div col}} or {{tl|colbegin}}, so is going to disconcert a lot of editors. I hope it's near the top of the "to-do list": see [[Wikipedia:VisualEditor/Feedback#Editing_within_a_multi-column_list_.28ie_between_.7B.7Bcolbegin.7D.7D_and_.7B.7Bcolend.7D.7D.29]]
Something like <div class="mw-columns-2"> .. </div> with the proper class definition in common.css would work better for editing in VE, as the wrapper won't be template-generated then. Generally visual editing works best if a template produces a self-contained part of a page ('properly nested') rather than cut-up start / content / end templates.
*** Bug 50595 has been marked as a duplicate of this bug. ***
Adding keywords to summary to make this searchable. As noted in bug 50595, this bug prevents copy-pasting formatted text from the main document into a template.
I'm seeing a few comments that imply that nested templates are somehow the result of a poorly thought out design: I take issue with that. Take {{BillboardURLbyName}}, for example: it's got a very simple job: give it the name of a musical artist, and it will return the URL to the Billboard page for that artist's charts or biography. Billboard loves to redesign its site periodically and builds the URL based on six digit numbers, so we really don't want URL hardcoding going on. It would be a very poor design if we required every template that could accept a URL to understand how to translate an artist name into a URL. It's much better to do it the way we do: pass {{BillboardURLbyName|artist name}} as an argument to templates that require URLs, and let each template do its own job.
We also need to be able to add the template {{tl|multiple issues}} around existing tags: when editing [[Dadloi]] I wanted to add a second maintenance tag and then tidy them up into {{tl|mi}}, but of course had to do the latter in Edit Source after my VE edit.
*** Bug 51485 has been marked as a duplicate of this bug. ***
This has come up a few times at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#a_sensible_way_to_edit_.7B.7Bdiv_col.7D.7D_sections http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Bulleted_lists In reply to Gabriel Wicke, substing {{subst:div col}} would give <div class="mw-columns-2"> .. </div>. This would work fine for all subsequent edits with VE, but not for editors using wikitext. Ideally list in {{div col}} blocks would be edited in place. Just as if it was a normal list. I think this points to a wider question: that some templates are going to need special ways of editing them. You might be able to add a field to the template data, say, "type":"wikitext-block" indicating its a block which should be edited in place. Some sort of extension mechanism could be used, say with an associated lua module providing hints to VE on how to edit the data.
(In reply to comment #10) > In reply to Gabriel Wicke, substing {{subst:div col}} would give <div > class="mw-columns-2"> .. </div>. This would work fine for all subsequent > edits > with VE, but not for editors using wikitext. I don't see a big difference between a div start / end tag and {{div col}} / {{div col end}} template pairs. Both are disconnected and of roughly the same text length.
*** Bug 52786 has been marked as a duplicate of this bug. ***
