Last modified: 2014-11-04 19:23:53 UTC
Hidden templates, like Template:Use British English, are displaying as carriage returns. These are pretty easy to mistakenly identify as typos or errors and delete. We need a better way of displaying those within the VE, or (as a long-term goal) a better way of surfacing metadata, a la the "page settings" page.
Template:Clear is also a good example of this. Although it doesn't even display as a carriage return. You can insert the template, and then it complete disappears.
A side-effect of this is that it's impossible to maintain good formatting (keep a blank line between metadata and article text, for example) because the content does not exist from an editor's perspective.
btw What's the standard of "hidden templates". Are templates generating <div style="display:none;">something</div> hidden, or what about <div class="hidden">something</div> when [[MediaWiki:Common.css]] contains .hidden{display:none;} ?
I have no idea if there /is/ a standard. A good illustration is https://en.wikipedia.org/w/index.php?title=Template:Persondata&action=edit
Even with non-hidden, but floating templates it can be confusing. To quote a user: http://en.wikipedia.org/w/index.php?title=Peach_Springs_Trading_Post&oldid=563257259 I place the cursor to the left of the line that begins "The Peach Springs Trad....", just after the malformed comment, then press backspace, in the hopes of starting to delete said malformed content, the entire infobox disappears. This is quite startling. Perhaps a warning is required for the short term ? "Are you sure you want to delete template... ?"
How about this: If the cursor is before or straight after a template, pop the 'puzzle' indicator into view. You could make it float above the current line, with a droplet (as a sort of cursor) downward pointing at the position where there is a template that is invisible or floating. When you click the icon, move the cursor to be on 'template', blue highlighting the template content if it is not hidden (this will help direct the users eye from cursor position to content) and directly open the template editor.
Oliver and others watching this bug, what's your sense from reviewing changes how often this (accidental deletion of hidden templates) is currently occurring in practice? Knowing this (even if it's anecdata) would help setting priority for this bug.
I've seen it a couple of times so far, but not that often. Having said that, we haven't been actively patrolling recentchanges in a while. I'd personally like some kind of resolution pre-IP rollout, because even if it's relatively rare we're throwing sheer numbers at every bug.
Why not allowing deletion of a template by keyboard only if the template is selected, not just if the cursor if just before or after the template ? I don't know if it's difficult to implement, but that would help preventing accidental deletions.
*** Bug 49633 has been marked as a duplicate of this bug. ***
FYI: I count 3 reports in the last 10 posts on WP:VP/T today related to accidental 'hidden' or 'floating' templates deletion.
Whatever solution is here should also apply to templates that normally produce text but have been created empty for whatever reason. For example it is possible to add a {{small}} template with no text to display.
*** Bug 51322 has been marked as a duplicate of this bug. ***
Regarding the English language variable templates specifically, it would be great if these were handled by pushing it into a meta tag (bug 52166) and incorporate it into page settings. Regarding top icons, there is a core enhancement for a pre-defined area for these icons (bug 23796), and a VE enhancement request to do the same (bug 51420). Regarding others, a puzzle piece sounds like a great UI for it. Or a custom icon defined in TemplateData?
PamD at en.wp complains that: "[When] I add invisible matter to an article (eg {{coord missing}}), it's too easy to delete it later in the same edit while "tidying up" blank lines etc." Suggestions have been made above about how to deal with this in advance of working out how to display hidden templates, e.g. in comment 9. Alternatively invisible templates could just be declared not deletable in VE (i.e. just treat them like nowikis). It will occasionally leave unnecessary templates in but that is going to be far rarer than deleting them without meaning or even knowledge as happens now. A work around for this allowing you to add and not delete stuff you've added would be to make their removal undoable. Not ideal but better than nothing.
> > A work around for this allowing you to add and not delete stuff you've added > would be to make their removal undoable. Not ideal but better than nothing. Though the problem is that you don't know you've removed them until you realise on saving the page that something you thought you'd added isn't there! A message like "removing invisible template: are you sure?" would be helpful.
*** Bug 52658 has been marked as a duplicate of this bug. ***
> > A work around for this allowing you to add and not delete stuff you've added > > would be to make their removal undoable. Not ideal but better than nothing. > > Though the problem is that you don't know you've removed them until you > realise > on saving the page that something you thought you'd added isn't there! A > message like "removing invisible template: are you sure?" would be helpful. Yes. Although reading comment 15 again I meant to say "make their addition undoable." (not removal). Sorry for the confusion.
*** Bug 60830 has been marked as a duplicate of this bug. ***
*** Bug 52551 has been marked as a duplicate of this bug. ***
On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on "white lines" as a blocking issue for turning VE on as default. On top of pages like: * https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit * https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit * https://nl.wikipedia.org/wiki/Rijn?veaction=edit * https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit * https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit as well as on other places on the page "white lines" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page. (Deleting white space at the bottom of a page might also delete accidently categories and other metadata.) How can I help to resolve this 'bug'?
(In reply to Ad Huikeshoven from comment #21) > On nl.wp a discussion has started to turn on VE. In the process feedback has > been collected on VE. Some users commented on "white lines" as a blocking > issue for turning VE on as default. > On top of pages like: > * https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit > * https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit > * https://nl.wikipedia.org/wiki/Rijn?veaction=edit > * https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit > * https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit > as well as on other places on the page "white lines" or carriage returns > appear in VE edit mode which do not appear in read mode. On mouse over the > white line turns blue. > > Some users fear that newcomers others will delete those white lines and > carriage returns. However, after deletion of those lines images are > accidently deleted from the page. > > (Deleting white space at the bottom of a page might also delete accidently > categories and other metadata.) > > How can I help to resolve this 'bug'? This feels like you don't think the resolution to bug 47790 in March was sufficient; I'm not sure that this has anything to do with this bug, however. Take the conversation there?
Ok to take the conversation there. I've read through bug 47790 and the reported issues are more or less the same. Bug 47790 is solved. What is the timeline of deployment?
(In reply to Ad Huikeshoven from comment #23) > Ok to take the conversation there. I've read through bug 47790 and the > reported issues are more or less the same. Bug 47790 is solved. What is the > timeline of deployment? It's already deployed. It was deployed to MediaWiki.org on 6 March 2014 (see the "Milestone" field), so it would have reached the Dutch Wikipedia a week later, on 13 March 2014. That's what I meant by "This feels like you don't think the resolution to bug 47790 in March was sufficient". :-)
Hi James. Thanks for the explanation. Today I learned the word "slugs". To me they are sufficiently clear that those aren't white space but something different. Some vocal users on nl.wp portray slugs as "ugly white rows" and fear accidental deletion, the examples provided that would be images. I will continue discussion on bug 47790 and bug 55336 about accidental deletion of FocusableNodes. I've seen a live case in which slugs cannot be deleted. However the cases mentioned above can be.
As an additional item (from bug 51978 comment 6): > Using the {{כ}} template works correctly while editing articles, and the > original test page https://he.wikipedia.org/wiki/User:Amire80/ve-rlm shows > everything correctly. > > That said, there are issues with handling this template after it's inserted: > * The bubble that shows its name appears in a wrong location. This is related to this bug – the context seems to find the nearest thing that actually displays and attaches to that. When we display a place for the context to show, it will presumably show there. :-)
*** Bug 72963 has been marked as a duplicate of this bug. ***
