Ask, or just silently replace? But then it will 'dirty diff' if this has been done deliberately. Also, to do this, link inspector will need to have a concept of canonical URLs and optional other URLs for this context, which is messy as hell.

Sometimes it is done deliberately, e.g. at https://en.wikipedia.org/w/index.php?title=English_Wikipedia&oldid=558847653 . In that case, they do use olids (permalinks), which is a way you could distinguish if you wanted to do the auto-replacement.

(In reply to comment #2)

Sometimes it is done deliberately, e.g. at
https://en.wikipedia.org/w/index.php?title=English_Wikipedia&oldid=558847653
.
In that case, they do use olids (permalinks), which is a way you could
distinguish if you wanted to do the auto-replacement.

We could do an always-replace for [http://foo/wiki/* $1], but that feels like a fragile regexp. :-(

Seeing a few of these in the feed. Warn, perhaps? (In the link inspector dialog.)

I'd go for "prevent". (Also, it would be really nice to have it soon).

I think maybe it should just recognize when a url points to an existing Wikipedia article, and offer that as an internal link option, similarly to the way that you get an internal link option for the article titled http://en.wikipedia.org/wiki/foo. That latter behavior represents a tiny edge case, though, as there are very few articles that start with http://. If there is ever going to be some sort of 'advanced' mode for links, then options to use external links to existing articles and internal links to articles starting http* should be hidden away there. In the vast majority of cases, users intend to create internal links if the article exists, and do not intend to create internal links to pages starting http*.

Incidentally, we want to add the same functionality to the EducationProgram extension for when users paste in a url to the article form: bug 44397.

Also, when users create a new article and want to link back to it immediately, they end up attaching "?venotify=created" to the external link they're copy/pasting, and this is something VE will need to strip before converting the URL to a wikilink.

Feels like this has consensus that we should convert newly-added [http://en.wikipedia.org/wiki/foo] links to [[foo]] automatically; I think that this should be done inside Parsoid, so moving there.

(In reply to James Forrester from comment #8)

Feels like this has consensus that we should convert newly-added
[http://en.wikipedia.org/wiki/foo] links to [[foo]] automatically; I think
that this should be done inside Parsoid, so moving there.

But only for VisualEditor edits? if Parsoid is going to be used in other stuff eg. bots.

(In reply to Liangent from comment #9)

(In reply to James Forrester from comment #8)

Feels like this has consensus that we should convert newly-added
[http://en.wikipedia.org/wiki/foo] links to [[foo]] automatically; I think
that this should be done inside Parsoid, so moving there.

But only for VisualEditor edits? if Parsoid is going to be used in other
stuff eg. bots.

No, all edits - this is the same as [http://fr.wikipedia.org/wiki/Foo Bar] being automatically converted by Parsoid to [[:fr:Foo|Bar]] which it already does.

(In reply to James Forrester from comment #10)

No, all edits - this is the same as [http://fr.wikipedia.org/wiki/Foo Bar]
being automatically converted by Parsoid to [[:fr:Foo|Bar]] which it already
does.

I feel there're still some deliberate use cases of external local links, for example, to prevent Echo notifications (see [[Template:Noping]]).

(In reply to Liangent from comment #11)

(In reply to James Forrester from comment #10)

No, all edits - this is the same as [http://fr.wikipedia.org/wiki/Foo Bar]
being automatically converted by Parsoid to [[:fr:Foo|Bar]] which it already
does.

I feel there're still some deliberate use cases of external local links, for
example, to prevent Echo notifications (see [[Template:Noping]]).

Users making hacks around bugs in Echo sounds like something we should fix in Echo so users don't have to do it, though. :-)

• Bug 57019 has been marked as a duplicate of this bug. ***