Page MenuHomePhabricator

VisualEditor: Add support for editing templates' parameters as DOM elements ("visually"), including supporting nested templates
Open, MediumPublic

Assigned To
None
Authored By
Ironholds
Jun 28 2013, 9:49 AM
Referenced Files
F3459623: Screen Shot 2016-02-29 at 17.47.14.png
Mar 1 2016, 1:50 AM
F3459624: Screen Shot 2016-02-29 at 17.47.23.png
Mar 1 2016, 1:50 AM
F3459622: Screen Shot 2016-02-29 at 17.49.12.png
Mar 1 2016, 1:50 AM
Tokens
"Like" token, awarded by Pppery."Love" token, awarded by Liuxinyu970226."Love" token, awarded by RodrigoTavares."Love" token, awarded by Ltrlg."Meh!" token, awarded by Dvorapa."Love" token, awarded by Gryllida."Orange Medal" token, awarded by Krinkle.

Description

Many templates serve merely as wrapper around free-form wikitext content. TemplateData specifies the parameter type "content" for this purpose.

This task tracks the implementation in VisualEditor to provide an edit surface for editing the values of these parameter. Similar to how we already support rich editing of the content inside References.

Use cases:

  • Wrap-templates. Such as message boxes, and the parameter-consuming variants of the "something-start"/"something-end" templates.
  • Nested infoboxes.
  • Simple infobox fields that support text but allow/encourage use of inline templates for formatting. Currently these expose raw wikitext to end-users.

A lot of infoboxes et al - the one on https://en.wikipedia.org/wiki/Fulgencio_(Modern_Family) comes to mind - have infoboxes /within/ the infoboxes that need editing. I'm not sure what the answer is here - it feels wrong, somehow, to offer an infinitely deep template inspector inside a template inspector inside...etc, but I can't think of another solution short of manually going around making the template namespace make sense or accepting that users will always have to learn markup, just not immediately.

Details

Reference
bz50355

Related Objects

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:45 AM
bzimport set Reference to bz50355.
  • This bug has been marked as a duplicate of bug 50182 ***

Re-wording; this isn't a duplicate of bug 50182, which is about non-dialog editing of templates.

Jdforrester-WMF lowered the priority of this task from High to Medium.Jan 15 2015, 12:35 AM
Jdforrester-WMF set Security to None.

Current thinking about switching modes:

Basic appearance
Screen Shot 2016-02-29 at 17.47.14.png (75×400 px, 6 KB)
Editing with support
Screen Shot 2016-02-29 at 17.47.23.png (104×407 px, 7 KB)
Switched to 'wikitext' mode
Screen Shot 2016-02-29 at 17.49.12.png (76×409 px, 6 KB)

@Ironholds the page has become a disambig since you filed. Looking at the history were you linking to https://en.wikipedia.org/wiki/Fulgencio_(Modern_Family) originally?

I have literally no idea, it was in 2014.

TrevorParscal subscribed.

@Ironholds the page has become a disambig since you filed. Looking at the history were you linking to https://en.wikipedia.org/wiki/Fulgencio_(Modern_Family) originally?

I fixed the link.

Comments from discussion about this:

  • Wikitext button should look depressed when used. MW theme needs this to be improved mode generally. Need to avoid mode error
  • Important to remember that the types aren’t for validation, just hints – don’t frustrate the user if they want to over-ride, make it easy to replace.
  • Styling of wikitext mode needs improving.
  • Need to separate “allowing to use VE” from “helping with type hinting”
  • Flow has this issue too (switching mode) – share feature design?
  • Edge case (partial wikitext) for not being able to use VE isn’t very common, we believe?
  • One switch for the whole dialog?
    • Issues?
    • In Advanced mode? (alongside multi-template transclusion editing)
  • Possibly get rid of the (i) too, to simplify the clutter around boxes?

Wikitext button should look depressed when used. MW theme needs this to be improved mode generally. Need to avoid mode error

Would a ButtonSelectWidget make sense here?

Jdforrester-WMF renamed this task from VisualEditor: Add support for editing templates' parameters as DOM elements, including supporting nested templates to VisualEditor: Add support for editing templates' parameters as DOM elements ("visually"), including supporting nested templates.Sep 13 2017, 6:27 PM

There is no facepalm token, so consider this little goat as the facepalm token, because still we literally force VE users to use wikicode for nested templates.

Change 451020 had a related patch set uploaded (by Chris Barnard; owner: Chris Barnard):
[mediawiki/extensions/VisualEditor@master] Working on Task #T52355 - ve.ui.MWTemplateDialog and ve.ui.MWParameterPage changed.

https://gerrit.wikimedia.org/r/451020

Change 451020 abandoned by Bartosz Dziewoński:
Working on Task #T52355 - ve.ui.MWTemplateDialog and ve.ui.MWParameterPage changed.

Reason:
Patch doesn't seem to actually do anything related to task T52355, no response from submitter

https://gerrit.wikimedia.org/r/451020

Basically, the central thing for me would be this:

Some templates are difficult (infoboxes) and some templates are easy ({{Quote}}, {{lang-it}}). VE allows editing links and bold text directly as first-class content element, but all templates are seen by VE as templates and not as formatting, and forces users to edit their content using the dialog. The result is that it's easier to edit such templates in wiki syntax (if you know which parameter to change, of course) than in VE for everyone: both wiki syntax lovers and newer people who like VE.

If VE could allow editing at least some simpler templates as just text, and treat them as custom formatting rather than a complex form, this would make editing much easier. Perhaps TemplateData could be modified to allow specifying some parameters as "directly-editable" or something.

I understand it's not trivial and requires some development time, but it's worth revisiting this.