Page MenuHomePhabricator

Autolinking for URLs and magic links (ISBN etc.) not applied when copy-pasting a block of text
Open, LowPublic

Description

Autolinking is not applied when copy-pasting a block of text, only when copy-pasting just the autolinkable string.

For example, copy-pasting these works – the VE core logic to autolink URLs, and the VE-MW logic to autolink magic links like ISBNs, kicks in:

  • http://example.com/
  • ISBN 1234567890

But when copy-pasting these, it doesn't:

  • Visit http://example.com/ to see an example.
  • Doe, John (2000). On examples. Example Publisher. ISBN 1234567890.

In particular, when copying a large block of content into a wiki page (e.g. an article you drafted in a text editor, or a notes from a session in an Etherpad), any links and ISBNs in it will not be autolinked, and will end up in wikitext wrapped in <nowiki>.

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Jdforrester-WMF subscribed.

This is intentional product design (as external links in copy are explicitly not wanted for MediaWiki users), but maybe it should be disableable by the platform (so it works in VE but not VE-MW) and by special kinds of links (like ISBNs)?

To be clear: I mean copy-pasting the examples as plaintext (e.g. from Notepad, or from a regular textarea on a web page). I don't mean rich text / HTML <a> links.

(This was filed as a "follow-up" to T162095.)

Yeeeah… maybe it'd be OK to have different behaviour if you were to paste foo http://www.example.org/ bar and get links, and <p>foo <a href="http://www.example.org/">http://www.example.org/</a> bar</p> and not, but I'm not wholly convinced users wouldn't be confused (the latter would nowiki as now).

If we're instead doing entirely a let's-reduce-nowikis pass after all pastes (regardless of source) in VE-MW to convert inline http://www.example.com/ to <a href="http://www.example.org/">http://www.example.org/</a> that's… more interesting, but possibly a bit magic? I dunno.

This problem seems to apply when you paste rich text (such as from a google doc) where the URL is already linkified. For example, this is in a gdoc, with the URL linkified:

Advanced edit quality support for Romanian Wikipedia incoming (https://phabricator.wikimedia.org/T156503)

If you copy and paste that into VE, the link becomes <nowiki>'d plain text. I would have expected rich links to come through unharmed, rather than having to go back through the auto-link process.

I wanted to add that this is very frustrating for those of us who paste meeting notes into mediawiki.org. There are often links to phabricator tasks, wiki pages, articles of interest, etc.

Would it be easy to enable/disable rich text link preservation on a per-wiki basis? I would think that some non-wikimedia sites running mediawiki would find link preservation really helpful.

I wanted to add that this is very frustrating for those of us who paste meeting notes into mediawiki.org. There are often links to phabricator tasks, wiki pages, articles of interest, etc.

Would it be easy to enable/disable rich text link preservation on a per-wiki basis? I would think that some non-wikimedia sites running mediawiki would find link preservation really helpful.

@Deskana , I think this is now going to be addressed by T145252, what about the rest of the task?

@Deskana , I think this is now going to be addressed by T145252 […]

Most, but not all, of it. The solution to that task attempts to preserve bold, italics, underline, strikethrough, superscript, and subscript, but nothing else. The "correct" way to handle other things, such as links, is unclear per T162291#3158146.

[…] what about the rest of the task?

What, exactly, is "the rest"? This task has been pulled in a few different directions, so I'm not clear what exactly is being requested any more.

Is this faulty edit (internal anchor links with manual superscript, and nowiki tags around ISBNs) related to this open bug?

https://en.wikipedia.org/w/index.php?title=Charles_James_%28designer%29&type=revision&diff=815077031&oldid=805363780

Is this faulty edit (internal anchor links with manual superscript, and nowiki tags around ISBNs) related to this open bug?

https://en.wikipedia.org/w/index.php?title=Charles_James_%28designer%29&type=revision&diff=815077031&oldid=805363780

I doubt it. The problem you've described seems like a different one.

This problem (adding nowiki tags around ISBNs in Visual Editor) is still happening. Here's an edit from 6 November 2018:

https://en.wikipedia.org/w/index.php?title=Chuang_Che&type=revision&diff=867577478&oldid=867567666

Please stop Visual Editor from adding these nowiki tags. They prevent magic linking from working, and bots converting magic links to templates will avoid ISBNs inside nowiki tags.

Given that these magic links were removed a couple of years ago, it doesn't seem like there's still a need to nowiki ISBNs and such, right? So could we just have plain text, please?

ISBN magic links have not been removed from en.WP, despite that change being planned and announced many years ago. Here's an example of a functioning magic link:

https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox3&oldid=930518392

But yes, please, plain text. Don't handle ISBNs in a special way when copying and pasting, or whatever action is involved here.

Note "just treat ISBNs as plain text" is exactly *opposite* from the original request made in this bug, which is to somehow ensure that ISBNs are properly magic linked.

And someone mentioned cut-and-paste from google docs; I believe if you cut-and-paste a URL into google docs it isn't automatically auto-linked as well. In both VE and GDocs your text is pasted "as is" and you need to add formatting to it if that's what you want.

Please read the request again. It is not entirely clearly written, but the request is asking ISBNs to be pasted as plain text. The MW software turns plain-text ISBNs into magic links (deprecated but still active). Treating ISBNs as plain text has been the request this whole time.

Note "just treat ISBNs as plain text" is exactly *opposite* from the original request made in this bug, which is to somehow ensure that ISBNs are properly magic linked.

Please read the request again. It is not entirely clearly written, but the request is asking ISBNs to be pasted as plain text.

I think @matmarex didn't take a position on what should happen, and rather neutrally noted an inconsistency in behavior. This has allowed everyone to view their preferred resolution to the situation as the original request. :D

That said, there's an ambiguity here about the phrase "plain text", related to what view of the data you're taking. There's "visually plain text" and "wikitext unwrapped-by-nowiki plain text". Or maybe "plain text output" vs "plain text input", if you prefer.

The current behavior is that you paste an ISBN that's part of a block of text and it appears in visual mode as plain-text. I.e. it's not visually shown as a link, it's just text. Because visual mode has represented it as not-a-link, it is thus proper WYSIWYG behavior to wrap it in nowiki tags when converting it to wikitext, because otherwise the visual representation would have been inaccurate. You'll note that this is consistent with other cases where you might enter wikitext into VE; if it doesn't get turned into a visual representation, it's nowiki'd.

If you want to remove the nowikis, the way to get that is to auto-link the ISBNs in visual mode when they're pasted in a block. Because then the visual representation will be consistent with the output.

(That is, I think you both mean the same thing about what should happen, because you're using opposing definitions of "plain text".)