Last modified: 2014-07-24 10:50:49 UTC
VisualEditor should display HTML comments, which are often used as notes or warnings to other editors. It would be nice if they were editable too.
I think this is a duplicate of Bug 42124 ? It doesn't specifically mention HTML or Hidden, so I'm not positive.
I don't think so. That one's just about preventing them from being silently removed on save. This is about actually displaying them to the editor.
That bug isn't fixed then (or was re-broken), because Hidden Comments are being deleted when we save. (This problem is now worse, because it is now only noticeable if we opt to "Review your changes" before saving.) See http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox and test with adding text anywhere in the article http://en.wikipedia.org/wiki/Bleak_House for example. It always removes the comments from the infobox. There are additional threads on that page mentioning the same thing.
Quiddity, yeah, I know, I just filed that (bug 49608).
(In reply to comment #4) > Quiddity, yeah, I know, I just filed that (bug 49608). For clarity, that's a problem with HTML comments in transclusions rather than in general, which does still work. Sorry. :-( We'd probably need to do this enhancement in stages - first, show comments and let them be deleted; later, make them editable and creatable. The second phase might be postponed indefinitely if the "co-ment" work comes to something. A treatment for in-line comments will be needed; possibly just a span of some kind. Will look at this.
(In reply to comment #5) >The second phase might be postponed indefinitely if the "co-ment" work comes to something. A treatment for in-line comments will be needed; possibly just a span of some kind. Will look at this. I'm mentoring that (along with Tyler). I don't think Richa's looked yet at integrating with VE. But it's still early. If you think the VE API is mature enough that it integration is feasible, you can suggest that at bug 46440.
(In reply to comment #6) > (In reply to comment #5) > >The second phase might be postponed indefinitely if the "co-ment" work comes to something. A treatment for in-line comments will be needed; possibly just a span of some kind. Will look at this. > > I'm mentoring that (along with Tyler). I don't think Richa's looked yet at > integrating with VE. But it's still early. If you think the VE API is mature > enough that it integration is feasible, you can suggest that at bug 46440. I know - see your own comment at bug 46440 comment 13 :-) - but I thought that the proposal was to build this for wikitext editor and then we'd take on porting it over to VE once it was done?
I don't think it was officially decided. Most likely, it will be wikitext first, but that could change if the VE API is ready.
(In reply to comment #8) > I don't think it was officially decided. Most likely, it will be wikitext > first, but that could change if the VE API is ready. I don't know what you mean by "the VE API", let alone it being "ready". :-) We negotiate with people to build whatever hooks they need (and we felt were justified) in the normal way. However, a commenting system like this feels more like core VE work than a plugin (so it wouldn't be a matter of hooks available for code in general); it'd sit well with the planned real-time collaborative editing functionality we're building in the new financial year, for which a chat/comment-like tool would be wanted.
(In reply to comment #9) > (In reply to comment #8) > > I don't think it was officially decided. Most likely, it will be wikitext > > first, but that could change if the VE API is ready. > > I don't know what you mean by "the VE API", let alone it being "ready". :-) > > We negotiate with people to build whatever hooks they need (and we felt were > justified) in the normal way. However, a commenting system like this feels > more like core VE work than a plugin Okay, based on that, I think it makes sense not to use VE for the inline comment prototype.
Is there any progress or movement on this? Specifically, will hidden comments at least be displayed by the Monday deployment?
Example of edit where displaying the hidden comment would have been very useful (because the edit goes against what is stated in the comment) : http://en.wikipedia.org/w/index.php?title=List_of_English-language_book_publishing_companies&curid=746089&diff=564359255&oldid=563535930
Another example: http://en.wikipedia.org/w/index.php?title=Jacques_Lacan&diff=566246717&oldid=561090875 We are getting multiple reports about this specific issue, so thanks for your attention on this.
Bump. https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=567981801
It has been reported on en.wp today that a user of VE was: [..] continually making changes to articles contrary to comments in the wikisource (''two examples of such comments being "<!-- DO NOT CHANGE THIS NATIONALITY WITHOUT DISCUSSION ON TALK PAGE -->" and "<!-- This is, as Wikipedia guidelines suggest, as he self-identifies and by long-term consensus -->") This bug is already marked as high priority and has been for over 2 months. It really needs to be fixed before much longer.
John Broughton suggests as a first step that hidden comments could very easily be made visible but not editable. He suggests putting the comments in a different colour, possibly white on black, to distinguish them from regular content. Obviously being able to edit hidden comments is needed functionality too, but that is less urgent than displaying them.
resetting priority to high. I didn't intend to change it and didn't realise I had, sorry.
I agree with James Forrester that this should be done in stages, and that the first stage would be to "show comments and let them be deleted. In terms of isolating hidden (aka "invisible") comments, the logic is pretty much the same as for templates, except easier: look for <!-- as the left boundary, then look for --> as the right boundary. Treat the result as a block that can be deleted or moved. Looking at https://en.wikipedia.org/wiki/Help:Hidden_text , it's not clear that text within an invisible comment is essentially nowikied, but that is in fact the case, because - by definition - the text can't be seen in either read or preview mode. From a programming viewpoint, this means that even if, for example, there is an http link within the comment, or a reference - both quite possible - no rendering is needed: all text should be treated as text, NOT interpreted. What the person doing the edit sees is really the critical question. It seems to me that there are two options: (1) Display as a text, mixed in with regular text, but in a different color font and background color. This is what is done with templates. Regarding the color: Hidden comments are typically warnings/notices to editors, so perhaps yellow? The font/coloring will, ideally, make it clear that the text is not part of the article. (2) Treat like a comment in Excel - put a character (I suggested a warning icon - see http://findicons.com/search/warning; in yellow) into the visible text that, when a person hovers on the icon, displays the hidden/invisible text. While this is less visible to editors, in some sense - they have to hover to read - it's more visible in the sense that hidden comments, in wikitext editing mode, are in the same font as everything else, and thus less likely to be noticed than a bright yellow warning icon. Option (2) lends itself nicely to the second phase mentioned by James: Here there would be an icon on the toolbar, for adding a new comment. In addition, if a person hovers over an existing comment, then an editing icon appears nearby, which allows the person to edit the comment or to delete it [via trashcan icon].
(In reply to comment #18) > In terms of isolating hidden (aka "invisible") comments, the logic is pretty > much the same as for templates, except easier: look for <!-- as the left > boundary, then look for --> as the right boundary. Treat the result as a > block that can be deleted or moved. The parsing part is solved. Comments are already preserved (as HTML comments) in the Parsoid DOM.
(In reply to comment #18) > I agree with James Forrester that this should be done in stages, and that the > first stage would be to "show comments and let them be deleted. > > In terms of isolating hidden (aka "invisible") comments, the logic is pretty > much the same as for templates, except easier: look for <!-- as the left > boundary, then look for --> as the right boundary. Treat the result as a > block > that can be deleted or moved. > > Looking at https://en.wikipedia.org/wiki/Help:Hidden_text , it's not clear > that > text within an invisible comment is essentially nowikied, but that is in fact > the case, because - by definition - the text can't be seen in either read or > preview mode. From a programming viewpoint, this means that even if, for > example, there is an http link within the comment, or a reference - both > quite > possible - no rendering is needed: all text should be treated as text, NOT > interpreted. > Of the two options I would be much happier with (1): in many circumstances these comments need to be obvious to the naive editor, who will not necessarily have the savvy or curiosity to hover over an icon. Please display these comments clearly on screen for all editors, at the point in the article where they have been inserted: different font on coloured background sounds good. > What the person doing the edit sees is really the critical question. It seems > to me that there are two options: > > (1) Display as a text, mixed in with regular text, but in a different color > font and background color. This is what is done with templates. Regarding the > color: Hidden comments are typically warnings/notices to editors, so perhaps > yellow? The font/coloring will, ideally, make it clear that the text is not > part of the article. > > (2) Treat like a comment in Excel - put a character (I suggested a warning > icon > - see http://findicons.com/search/warning; in yellow) into the visible text > that, when a person hovers on the icon, displays the hidden/invisible text. > While this is less visible to editors, in some sense - they have to hover to > read - it's more visible in the sense that hidden comments, in wikitext > editing > mode, are in the same font as everything else, and thus less likely to be > noticed than a bright yellow warning icon. > > Option (2) lends itself nicely to the second phase mentioned by James: Here > there would be an icon on the toolbar, for adding a new comment. In addition, > if a person hovers over an existing comment, then an editing icon appears > nearby, which allows the person to edit the comment or to delete it [via > trashcan icon].
Like Pam I think it is best that these notices are visible and in-your-face so there is no doubt that you have seen them. Hover also causes issues on touch screen devices I think. One thing that would be possible would be for there to be an icon associated with the comment that collapsed it to get a more WYSIWYG view (and then expanded it again on a subsequent click). The default display would be shown. I guess that custom css/js to have them hidden by default would be possible if people wanted, but I don't suggest the devs do anything other than make it possible for users to write this. I don't know how difficult any of this would be to program though. On the issue of rendering, I know that some comments contain links, for example from [[Patrick Stewart]]: <!--Do not change this to KBE, see [[Knight Bachelor]]--> Obviously this is shown like any other link in the source editor, but it makes it clear that it is a link to an article and people with navpopups can select it and get a preview of the link. If VE could parse links (and I guess external links) then that would be a nice to have.
I've just discovered that, at present at least, <!-- blah --> does not get nowikied so html comments are creatable in VE but not visible once saved so this functionality really very useful yet. Other HTML tags do get nowikied so this behaviour may subsequently change - see [[Wikipedia:VisualEditor/Feedback#HTML comments not nowikied - should they be?]]
It should go without saying, but another consequence of this, beyond the comment being ignored, is that it can easily be misplaced, ending up in places where it does not belong and it does not make much sense, as user:Fram points out at en.wp today.
(And of course, this means comments can not be easily deleted right now, in case they display obsolete information, for example.)
*** Bug 51732 has been marked as a duplicate of this bug. ***
*** Bug 52036 has been marked as a duplicate of this bug. ***
Change 140773 had a related patch set uploaded by Jforrester: [WIP] Show comments inline to the user https://gerrit.wikimedia.org/r/140773
Change 140773 merged by jenkins-bot: [BREAKING CHANGE] Show comments inline to the user https://gerrit.wikimedia.org/r/140773
