Topic on Talk:Requests for comment/Future of magic links

Kaldari (talkcontribs)

The proposal as written sounds reasonable to me. In the long run, I imagine ISBN, PMID, and RFC links will be handled the same as DOI, JSTOR, IEC, NGS, ITIS, and IMDB links. In other words, with dedicated templates. The current behavior was a good idea at the time, but I think we've outgrown it.

Strainu (talkcontribs)

I personally would prefer to extend the number and reach of magic links, with Magic Words or any other wiki-configurable method, to just removing them. Templates are good, but writing "RFC 1234" is shorter and much simpler (especially on mobile) to type than "{{RFC|1234}}". I'm not even talking about how hard it currently is to insert a template in VE.

Legoktm (talkcontribs)

But really, how many times have you wanted to link to an IETF RFC? I've been editing for how many years now, and have used the RFC magic link functionality exactly once.

I agree that making it easier to link to references or external websites is a good thing, but I don't think the current implementation of magic links is the way to do it.

Strainu (talkcontribs)

Well, you're asking the wrong person - I've linked hundreds of times to RFCs, but I'm clearly way above average since I'm writing articles about different networking protocols.

But just like I'm writing articles about things described in RFCs, others write articles that use other external ids (to use Wikidata terminology) and should benefit from such shortcuts. If the current implementation is non-scalable and hard to maintain, the solution should be to replace it, not dump it.

Saper (talkcontribs)

I'm a bit surprised: it's a feature that actually makes something easier and effortless to the users and we would like to remove it.

I spend some time editing non-Wikimedia wikis (sometimes being invited to solve an ad-hoc problem somewhere) and it is always a pain having to find out a list of available interwiki links, which I find extremely unfriendly.

Templates are even worse: their syntax is cumbersome and finding out what kind of template a particular MediaWiki install is using is a challenge. If somebody desires a Wikipedia-like look and feel of their own MediaWiki install the most painful thing is to import some set of "standard" templates into their own wiki, for example to be able to create infoboxes or navigation templates.

As per actual issues - hardcoded links, non-extensible - I fully agree, but maybe this can be fixed?

Kaldari (talkcontribs)

Personally, I find the magic link behavior to be a pain in the butt, since I commonly discuss RFCs on wiki, but not IETF RFCs. So I always end up linking to the wrong webpages and confusing people. The assumption that magic words make things easier only applies if you happen to be using the magic words as they are intended to be used, which isn't always the case. Also, you have to remember which words are magic and which ones aren't. I would rather have a consistent, flexible system that is less magic.

LeadSongDog (talkcontribs)

So far, the dual meaning of RFC (IETF vs MW) seems to be the only viable argument in favour of this change. I've seen no meaningful argument that supports killing the PMID or ISBN functionality. So, will they continue to be enabled on WP and WD after they are no longer the default installation?

Legoktm (talkcontribs)

Hi @LeadSongDog, did you read the various Phabricator tasks linked in the "Problem" section? I think those are valid arguments for removing the other 2 magic links as well.

The default has already been switched to disabled, but they are still enabled on Wikimedia sites currently.

LeadSongDog (talkcontribs)

Yes I've read them, but it was not clear whether or not established usage on en wp will eventually be disrupted. It's nice to confirm that it hasn't happened yet, thank you, but not enough. The "unlocalizable" argument seems to be at most weakly supported, in a forum that goes largely unseen. It is certainly not clear why it is "unlocalizable".

As is often the case, the issue is that when devs make a decision without consulting the affected volunteer users, those volunteers experience the results as an unwelcome surprise breaking change. Such actions cost us editors. It is a real issue. If the change does not break things for users then why make them think it will?

Reply to "Proposal"