Change Details

This is similar to {T141689}, but probably (even) more controversial than that, which is why I, again, put "consider" in the task's title. One of the most common reasons for auto-inserting `<nowiki>` tags is users typing [[stuff that looks like an internal link]] which is VisualEditor or ContentTranslation. I've been meticulously examining all cases of auto-inserted `<nowiki>` tags since June 2015 in the Hebrew Wikipedia, and there was not a single case when actually having double square brackets in the text was the editor's intention. It's pretty clear to me how it happens in Content Translation, which doesn't use the full-fledged VE component ([[ https://phabricator.wikimedia.org/T105447 | yet ]])—users think that [[brackets]] work in the translation editor ({T115184}). It's less clear to me how does this happen in VE, which should guard against this: Pasting text that includes wiki syntax like `economist [[Jambyn Batmönkh]] was the last leader of communist [[Mongolia]]` into VE now usually auto-renders "Jambyn Batmönkh" and "Mongolia" as a link in a DWIM way and typing `[[` shows a link inspector. These VE features are excellent, and they measurably reduced the number of `<nowiki>` auto-insertions. Evidently, however, these features are not bullet-proof, as plenty of edits still result in `text with <nowiki>[[links]]</nowiki>` that aren't rendered as links, and require subsequent removal of `<nowiki/>` tags. ("Plenty" is dozens per month in the Hebrew Wikipedia, and probably more in larger language editions.) Cases when double square brackets are actually needed are so rare that I couldn't find even one out of hundreds. Therefore, `[[text in brackets]]` should be auto-rendered as a link and not put inside `<nowiki>`, probably upon saving. If after implementing this suggestion typing `[[something like this]]` will really be needed, I can suggest two ways to do it: # Allowing the user to perform the Undo action to remove the automatic link, similarly to how it is done in all WYSIWYG editors. # Using a template such as {{Nowiki}}. The first option is much more straightforward, of course, but some people may prefer the second, and it already works in any case without any additional development.

This is similar to {T141689}, but probably (even) more controversial than that, which is why I, again, put "consider" in the task's title. One of the most common reasons for auto-inserting `<nowiki>` tags is users typing [[stuff that looks like an internal link]] which is VisualEditor or ContentTranslation. I've been meticulously examining all cases of auto-inserted `<nowiki>` tags since June 2015 in the Hebrew Wikipedia, and there was not a single case when actually having double square brackets in the text was the editor's intention. It's pretty clear to me how it happens in Content Translation, which doesn't use the full-fledged VE component ([[ https://phabricator.wikimedia.org/T105447 | yet ]])—users think that [[brackets]] work in the translation editor ({T115184}). It's less clear to me how does this happen in VE, which should guard against this: Pasting text that includes wiki syntax like `economist [[Jambyn Batmönkh]] was the last leader of communist [[Mongolia]]` into VE now usually auto-renders "Jambyn Batmönkh" and "Mongolia" as a link in a DWIM way and typing `[[` shows a link inspector. These VE features are excellent, and they measurably reduced the number of `<nowiki>` auto-insertions. Evidently, however, these features are not bullet-proof, as plenty of edits still result in `text with <nowiki>[[links]]</nowiki>` that aren't rendered as links, and require subsequent removal of `<nowiki/>` tags. ("Plenty" is dozens per month in the Hebrew Wikipedia, and probably more in larger language editions.) Cases when double square brackets are actually needed are so rare that I couldn't find even one out of hundreds. Therefore, `[[text in brackets]]` should be auto-rendered as a link and not put inside `<nowiki>`, probably upon saving.

This is similar to {T141689}, but probably (even) more controversial than that, which is why I, again, put "consider" in the task's title. One of the most common reasons for auto-inserting `<nowiki>` tags is users typing [[stuff that looks like an internal link]] which is VisualEditor or ContentTranslation. I've been meticulously examining all cases of auto-inserted `<nowiki>` tags since June 2015 in the Hebrew Wikipedia, and there was not a single case when actually having double square brackets in the text was the editor's intention. It's pretty clear to me how it happens in Content Translation, which doesn't use the full-fledged VE component ([[ https://phabricator.wikimedia.org/T105447 | yet ]])—users think that [[brackets]] work in the translation editor ({T115184}). It's less clear to me how does this happen in VE, which should guard against this: Pasting text that includes wiki syntax like `economist [[Jambyn Batmönkh]] was the last leader of communist [[Mongolia]]` into VE now usually auto-renders "Jambyn Batmönkh" and "Mongolia" as a link in a DWIM way and typing `[[` shows a link inspector. These VE features are excellent, and they measurably reduced the number of `<nowiki>` auto-insertions. Evidently, however, these features are not bullet-proof, as plenty of edits still result in `text with <nowiki>[[links]]</nowiki>` that aren't rendered as links, and require subsequent removal of `<nowiki/>` tags. ("Plenty" is dozens per month in the Hebrew Wikipedia, and probably more in larger language editions.) Cases when double square brackets are actually needed are so rare that I couldn't find even one out of hundreds. Therefore, `[[text in brackets]]` should be auto-rendered as a link and not put inside `<nowiki>`, probably upon saving. If after implementing this suggestion typing `[[something like this]]` will really be needed, I can suggest two ways to do it: # Allowing the user to perform the Undo action to remove the automatic link, similarly to how it is done in all WYSIWYG editors. # Using a template such as {{Nowiki}}. The first option is much more straightforward, of course, but some people may prefer the second, and it already works in any case without any additional development.