Strange, it seems like mw:Requests for comment/Future of magic links is marked as accepted, still there are a lot of serious opposing comments that are not addressed. It the points to phabricator, but this thread neither does address the raised concerns.

Quite frankly, I wonder if this RfC is accepted at all.

<rant>What a few developers do in this case is a quite good example of reimplementing a markup language A with another markup language B, without having a real discussion of why B would be a better language than A. Because of this "I have a much better idea then you" we have several partially implemented languages. It has turned into a complete mess, and it will not be better by adding more templates. The editors already has to memorize to many weird templates, and that is not a good path forward!</rant>

What is the status of this ticket? As far as I can tell, it has been more than three years since the release of MW 1.28 (https://www.mediawiki.org/wiki/MediaWiki_1.28), but magic links are still functioning, at least on en.WP.

Is it up to individual WP instances to turn off magic links locally? Did we at en.WP miss a memo at some point?

FWIW, we do not believe this task is blocked on Parsing-Team--ARCHIVED and we don't currently have this on our roadmap. Magic links are implemented and work in both the legacy parser and Parsoid as well as Visual Editor, so this is not blocking any feature development. It seems likely that magic links wouldn't be included in any notional "wikitext 2.0" proposal, but that's a long way off (if we ever get there).

If there is someone who wants to drive magic link removal, we are happy to support, but at this point that seems like it would be limited to a 2-ish line patch to add either a tracking category or a linter category to track "legacy" magic link usage on pages. We wouldn't write or deploy such a patch until we knew someone had an active effort to use this, though.

I don't understand the comment about tracking. The MW software has performed this tracking for more than three years, per Part 2 of the Exploration section of the original ticket description above.

See https://en.wikipedia.org/wiki/Category:Pages_using_ISBN_magic_links and https://en.wikipedia.org/wiki/Special:TrackingCategories

The categories, at least on en.WP, have been the subject of an active effort to convert article-space instances of ISBN magic links to ISBN templates for over three years, because MWF developers told us that magic links were going away.

At this point, this ticket is about Part 3 of the "Exploration" section of this ticket's original description, disabling magic links functionality. My understanding is that implementation of Part 3 is wholly in the hands of WMF developers. If I am wrong about that, and we should be implementing Part 3 (disabling magic links) locally on a per-wiki basis, please let us know.

I think @cscott was trying to say: we don't want to pursue removal at this time if it needs us to ensure that all wikis fix up their links first. But, if wikis have already done the work of fixing up their pages, then it becomes easier for us to remove this. This is mostly a matter of work priorities. We haven't researched where different wikis are at this point. We are currently focused on getting Parsoid to replace the current parser and if taking this RFC to completion requires us to spend energies to ensure all wikis to fix their magic links first, then, it is lower priority for us at this point.

That said, over the next year, we are likely going to discover new linting categories for making Parsoid the default wikitext engine for wikimedia wikis. At that point, we could potentially fold magic link removal effort with it if there are still wikis out there that are using magic links.

Feedback welcome.

Thanks for the response.

Can en.WP turn off magic links locally?

Yes, magic links are a per-wiki feature flag: https://www.mediawiki.org/wiki/Manual:$wgEnableMagicLinks

That said, I'm not certain that Parsoid and VE can turn these off quite that easily yet: https://codesearch.wmflabs.org/search/?q=EnableMagicLinks&i=nope&files=&repos= doesn't show anything checking this configuration variable in the VIsualEditor or Parsoid codebases. So if a wiki (enwiki?) is actually ready to turn off magic links in core, perhaps I was wrong and this is a task the Editing-team and Parsing-Team--ARCHIVED need to schedule. That's T145590: Update Parsoid to be compatible with magic links being disabled and T145589: Update VisualEditor to be compatible with magic links being disabled, which were created in 2016 but not linked up (until I just did now) as subtasks of this RFC.

Created T252054: Implement magic link functionality as an extension for possible future follow-up work that would let us pull the magic link functionality out of the core codebase. Not a blocker here; in fact pulling magic links out of the core codebase could be done even if we got blocked on actually turning off magic links on one of the WMF wikis.

@cscott Are there unanswered questions here and/or other outreach you'd like to happen before this proceeds? Note that closing of this RFC does not mean that it has to be disabled/removed from prod the next day, so if this plan is accurate and up-to-date and there are no unknowns, I'd recommend you propose this for Last Call :)

Capturing a note from other travels on a reasonable task: Sanitizer::safeEncodeAttribute() is hiding an arm/leg of the auto-linking code.

Pretty weird that we've disabled magic links on English wikipedia (where they are generally reasonable, ie RFC links to an english-language documentation site) but not yet disabled them on other wikis, which I thought were the original complaintants here. Is there a plan for turning these off WMF-wide? @Legoktm ?

No plan, but still interested in moving this forward, I'll try to look at what the landscape looks like (presumably there are small wikis that aren't using these entirely) and propose a plan.

IIRC a lot of the complaints against disabling came from de.wp. Unfortunately they've disabled the tracking categories so we don't even have quick stats (I'll pull them from a dump).

In T145604#8572109, @Legoktm wrote:

No plan, but still interested in moving this forward, I'll try to look at what the landscape looks like (presumably there are small wikis that aren't using these entirely) and propose a plan.

Still working on surveying wikis, but as an update I've been mostly refreshing my knowledge of the RfC and objections, as well as looking at software things, especially T179769#8608433 and T145590#8608455.

IIRC a lot of the complaints against disabling came from de.wp. Unfortunately they've disabled the tracking categories so we don't even have quick stats (I'll pull them from a dump).

In the main namespace, via the enterprise HTML dump:

• ISBN: 2,471,474 (in refs: 755,037 or ~30%)
• RFC: 3,010 (in refs: 239 or ~8%)
• PMID: 71,487 (in refs: 58,891 or ~82%)

Note that these are total number of links, not pages with the links.

Regarding German Wikipedia you need a smart stategy, then it will work.

• Looking at LINT errors dewiki will proceed; compare with enwiki.
• However, among 20.000 people there are a dozen fellows who started in 2005 and they do not want any change and everything has to be kept as it was in 2005. Unfortunately, they are quite loud and experienced and collected a lot of merits for their work as authors over two decades.

A promising plan would be:

• Wait until Vector2022 has been established successfully.
  • A war on two frontiers simultaneously is not a good idea.
  • Currently even enwiki is reluctant.
  • Gadgets need to be adapted to new page arrangement.
• After sea has calmed, announce a change for RFC within about 3 or 6 months; end of 2023 or July 1st 2024 or whatever, for all projects.
  • There is already a template.
  • RFC 1 can be switched easily by bot in article space towards RFC&nbsp;1<ref>{{RFC-Internet if not already within <ref>, then change access inside <ref> elements, then cleaning up the remainders. Other namespaces are no longer linked.
  • Tracking category may be activated then and tells occurrences for several years even if no link is generated any longer.
• Then announce discontinuation of PMID within 3 or 6 months.
  • Those will be overcome by [[pmid:1|PMID&nbsp;1]] whereever they occur.
• For ISBN you will need a global parser function {{#isbn:0-123-456-7|1}} with second parameter for invalid ISBN but printed in books and registered in national library catalogues.
  • This should format and hyphenate correctly and will apply a class and nowrap and error message and maintenance category and everybody is happy.
  • Since it is widely used, bots will need ages and version histories get lots of entries.
  • Small wikis have no bots.
  • A global migration plan needs to be developed, perhaps via server script (a parser function can be applied everywhere while a template needs local support and might collide with a local template).
  • When migrating to next Parsoid storage level this might be done automatically.
  • VE might dump parser function formatting.
  • When retrieving wikitext content deliver new syntax, or store new syntax every time when publishing. Will take some ages.
• After each stage, check riot level in all wikis. Adapt roadmap if necessary.

In T145604#8627941, @PerfektesChaos wrote:

Thanks, this is a good starting point.

What is the value of splitting up the migration of RFC and PMID into two steps? Wouldn't it be less of a hassle to do both at the same time?

• Wait until Vector2022 has been established successfully.

Definitely, and it'll take a while to get the necessary technical work done first anyways.

• After sea has calmed, announce a change for RFC within about 3 or 6 months; end of 2023 or July 1st 2024 or whatever, for all projects.
  • There is already a template.
  • RFC 1 can be switched easily by bot in article space towards RFC&nbsp;1<ref>{{RFC-Internet if not already within <ref>, then change access inside <ref> elements, then cleaning up the remainders. Other namespaces are no longer linked.

I am a little surprised a template is preferred over [[rfc:1|RFC 1]], but OK.

• Tracking category may be activated then and tells occurrences for several years even if no link is generated any longer.

Having the tracking category stick around longer is an interesting idea, I think it should be possible.

• Then announce discontinuation of PMID within 3 or 6 months.
  • Those will be overcome by [[pmid:1|PMID&nbsp;1]] whereever they occur.
• For ISBN you will need a global parser function {{#isbn:0-123-456-7|1}} with second parameter for invalid ISBN but printed in books and registered in national library catalogues.

So...why do we need a parser function? Back in 2016 you had proposed using a template (c.f. T148274#2788218), which I agree with and prefer.

• A global migration plan needs to be developed, perhaps via server script (a parser function can be applied everywhere while a template needs local support and might collide with a local template).

I have some ideas for a global bot, but yeah, that should be part of this. That said, I do think spending the time to get the local support part right is worth it (e.g. maybe standardize https://www.wikidata.org/wiki/Q5617482), it'll help with other cross-wiki imports, ContentTranslation, etc.

I have some ideas for a global bot

I have one that's already been run(ning) on two wikis and could be run globally.

So...why do we need a parser function? Back in 2016 you had proposed using a template (c.f. T148274#2788218), which I agree with and prefer.

Does not sound like a good idea to rely on templates until we have global templates

In T145604#8631274, @Legoktm wrote:

In T145604#8627941, @PerfektesChaos wrote:

What is the value of splitting up the migration of RFC and PMID into two steps? Wouldn't it be less of a hassle to do both at the same time?

Look at the figues, especially deWP.

• RFC is a test balloon.
• Amount is not too large, check how support for small wiki will succeed.
• Give them some months to take breath; learn from experiences in RFC step.

I am a little surprised a template is preferred over [[rfc:1|RFC 1]], but OK.

It has been an answer for deWP circumstances.

• We do have a template already.
• In deWP it is actually not permitted to have external links within major article texts, but magic links are below radar here.
• An RFC actually needs a title in citation, but RFC and number is part of the title. It is a native publication as Internet RFC. A PMID is only a catalogue number for something published whenever in any journal, and PMID is an additional hint to catch an abstract or the entire text for free. PMID is appended to a citation from a journal issue.
• For global purpose I would recommend wake procedure as with pmid:.

• For ISBN you will need a global parser function {{#isbn:0-123-456-7|1}} with second parameter for invalid ISBN but printed in books and registered in national library catalogues.

So...why do we need a parser function? Back in 2016 you had proposed using a template (c.f. T148274#2788218), which I agree with and prefer.

The answer was given below meanwhile.

• {{#isbn:0-123-456-7|1}} cannot collide with any local template.
• Functionality is the same as by local template, and should include nowrap, hyphenating and intentionally invalid code as well as detection of invalid ISBN (not really possible for PMID and RFC).
• This is more functionality than just [[rfc:1|RFC&nbsp;1]] since there are smaller numbers in ID.
• A parser function is implemented and maintained once globally, and available everywhere.
• I am trying to learn something, at least since 2016, and might get additional insights.

I have some ideas for a global bot, but yeah, that should be part of this. That said, I do think spending the time to get the local support part right is worth it (e.g. maybe standardize https://www.wikidata.org/wiki/Q5617482), it'll help with other cross-wiki imports, ContentTranslation, etc.

Such local template might have differing parameters and additional functionalities, making more use of the ISBN, providing direct link to national library of that language. And you would have to distribute and update the hyphenization database to every single wiki.

• As you might have noted in that Wikidata item, there is no such template in deWP.
• However, we do have a formatting function (example).

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

In T145604#9804125, @Rich_Farmbrough wrote:

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

It was not, AFAIK. See the part of https://www.mediawiki.org/wiki/Requests_for_comment/Future_of_magic_links#Proposal where it says "Update: this part was controversial, and will be re-evaluated based on the response to disabling by default."

Magic links were made enable-able on a per-wiki basis instead of a built-in feature of the core code that could not be turned off or on.

The English Wikipedia overwhelmingly decided to turn them off: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=772133164#Future_of_magic_links

12 Support votes for en.wp does not qualify as "overwhelmingly decided", even if there were only few opposing voices because this small number is far from being representative and therefore is prone to small group bias. I really doubt that a community representative vote was wanted. Imho, that was underwhelming.

Please, this is not the venue for parochial on-wiki community disputes; take it there.

The first sentence is correct, but please don't ask community members to go away. Imho, this is not the best problem resolution.

@Legoktm: German Wikipedia discontinued to use RFC magic in article space for almost a year now.

I suggest to publish via TechNews now that RFC magic will no longer cause links by 1 Jan 2025.

• RFC has the smallest number of usages, PMID is next.
• Both are easily to replace, and do no harm if not linked.
• Some three months are sufficient time for minor wiks to run bots.
• It should be offered to run bots of major wikis in small wikis if requested.

See what will happen,

• on announcement,
• in the following months.

Next step might be to discontinue PMID magic by 1 Jan 2026, announced in summer 2025.

An entirely differnet issue is ISBN, which is more important and link to special page is used and needed in all wikis. Only some larger wikipedias are using RFC and PMID at larger scale.

In T145604#9804569, @Jonesey95 wrote:

In T145604#9804125, @Rich_Farmbrough wrote:

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

It was not, AFAIK. See the part of https://www.mediawiki.org/wiki/Requests_for_comment/Future_of_magic_links#Proposal where it says "Update: this part was controversial, and will be re-evaluated based on the response to disabling by default."

Magic links were made enable-able on a per-wiki basis instead of a built-in feature of the core code that could not be turned off or on.

The English Wikipedia overwhelmingly decided to turn them off: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=772133164#Future_of_magic_links

The first quote "Update: this part was controversial, and will be re-evaluated based on the response to disabling by default." means that WMF decided to do it and maybe revert if enough noise was made.

That second link was not the RFC, that was an attempt to get consensus on EN about what to do when it was turned off. However the fact that WMF had already made the decision, meant that there was less support, or even discussion about retaining the magic. One editor even commented:

@Rich: This discussion is about how to replace magic links, not whether to replace magic links.

Even worse, if I understand it correctly, the whole thing was started because the WMF engineers could not make it work in RLT languages.

The major issue on this kind of magic is that they are a nightmare on parsing.

• And hard to understand and teach and describe to authors as well.
• It is blowing up syntax description and make things even more complicated.

Every time you encounter letters like IPR you need to investigate the preceding and following characters, whether letters before or punctuation and spacing characters, and whether next is SMF, then BIC, then ND, then look for a space, even as entity, or U+00A0. Then inspect the sequence of digits, perhaps hyphens or dots in ISBN.

A good language is triggered by some special characters, like <, [, {{, __, -{, {| etc. Then you can look for the closing counterpart. If matching, you can examine what happens in between, perhaps before.

A : is hard enough. Are letters preceding, until first non-letter, then check whether they match things like html or mailto, and perhaps // are following where expected, and find the characters terminating a magic URL.

And yes, for all non-latin scripts things like ISBN, PMID, RFC are not appropriate, and the Wikipedia audience is not necessarily able to understand such glyphs they have never seen.

In T145604#8631274, @Legoktm wrote:

So...why do we need a parser function? Back in 2016 you had proposed using a template (c.f. T148274#2788218), which I agree with and prefer.

I will advocate for ‘why’s for a parser function here:

1. does not increase template size limit as much as a template would (which is important in citation templates since many are still wikicode-based, not Lua based, so having a template that does [[Special:BookSources/{{{1}}}|ISBN {{{1}}}]] will be much more expensive the more citations you use);
2. does not add additional hundreds of thousands of rows to template links table on all big wikis;
3. seems correct at least for ISBN since it links to a special page anyway.

I think the recommendation should be to implement {{#isbn:}} as a parser function in the same extension that implements Special:BookSources (or in core if it implements it), and to remove PMID and RFC since those are not used as much and can be done by templates. I am sure Latin script wikis do not have to encounter technical limits as much as non-Latin wikis do, but for me that is a huge concern before trying to deal with magic links on ruWP. I do not have the resources to re-implement every citation template in Lua, and just switching to even the most well-written version of {{ISBN}} would add many additional bytes to citations that use wikitext-based templates.

For smaller of almost 1000 WMF wikis it is hard enough to migrate current pages towards {{#isbn:}} in all pages. While larger wikis do have bots, many small projects have just three or four regular article authors. A global support by bots in foreign wikis will be needed.

• When migrating, all 1000 wikis would need to maintain a template implementation of {{ISBN}} which might collide with existing implementations.
• A {{#isbn:}} is not local, but maintained globally and present everywhere.

Both RFC and PMID are very specific issues, almost within larger wikipedias and a few wikibooks or wikiversity pages. If they stop to create links, projects might help themselves. Major wikis already terminated to use RFC on a regular basis, at least in article space. If not linked any longer this is not a desaster. Global bot help may be offered on demand.

Tbh I don’t think it is that much of a tragedy if some smaller wikis do not have those links for some time. Bot support is definitely needed, but these sorts of replacements are easy to do just with tools like AWB/JWB. So someone just needs to come up with a documentation page on how to do a switch using those sorts of tools. They do not require some very complicated bots, so if magic links do not work until someone runs a bot, that’s fine. It’s not like ISBN data will combust when magic links are not there.

This is stalled on T179769. Minor wikis are not going to change magic links while any VisualEditor change can change them back to magic links. It should be an obvious non-starter.

Visual Editor / T179769 has been fixed since 779e3f97de636ac13678a74c69f4880c55453a81 (sept 2024).

https://www.mediawiki.org/wiki/Parsoid/Feedback#nlwiki:Alexandrinskitheater has some discussion about ISBN magic links triggering unexpectedly on nlwiki.

Could you disable the ISBN / RFC / PMID magic links at IA.wikipedia? We are ready, all usages have been replaced by the appropriate templates. As you can see in the [https://ia.wikipedia.org/w/index.php?title=Wikipedia:Taverna&oldid=691639#ISBN_/_RFC_/_PMID_-_magic_links IA Village Pump], the only other active admin at the project strongly encourages to disable the old magic links.

In T145604#11483536, @Jcb wrote:

Could you disable the ISBN / RFC / PMID magic links at IA.wikipedia?

@Jcb I've created T414019 for this. Thanks!

Could you disable ISBN / RFC / PMID magic links at NL.wikipedia? We are ready, all usages have been replaced by the appropriate templates. As you can see in the village pump: https://nl.wikipedia.org/w/index.php?title=Wikipedia:De_kroeg&oldid=70570413#Uitschakelen_magische_links , the change is clearly supported by the local community.

As I mentioned on wiki, best practice is to open a new subtask of this task, and link in the description of the subtask to a discussion on-wiki supporting the change for traceability and accountability. Feel free to assign the task to me for the time being, and I will make the appropriate patch to mediawiki-config.

Change #1237373 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[operations/mediawiki-config@master] Disable magic links on nlwiki

https://gerrit.wikimedia.org/r/1237373

Change #1237373 merged by jenkins-bot:

[operations/mediawiki-config@master] Disable magic links on nlwiki

https://gerrit.wikimedia.org/r/1237373

Mentioned in SAL (#wikimedia-operations) [2026-02-09T22:14:27Z] <cscott@deploy2002> Started scap sync-world: Backport for [[gerrit:1237373|Disable magic links on nlwiki (T145604)]], [[gerrit:999060|Turn on Parsoid read views by default on labs (T357054)]], [[gerrit:1237348|Enable site notices on Minerva (T416644)]]

Mentioned in SAL (#wikimedia-operations) [2026-02-09T22:16:22Z] <cscott@deploy2002> jdlrobson, cscott: Backport for [[gerrit:1237373|Disable magic links on nlwiki (T145604)]], [[gerrit:999060|Turn on Parsoid read views by default on labs (T357054)]], [[gerrit:1237348|Enable site notices on Minerva (T416644)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-02-09T22:25:48Z] <cscott@deploy2002> Finished scap sync-world: Backport for [[gerrit:1237373|Disable magic links on nlwiki (T145604)]], [[gerrit:999060|Turn on Parsoid read views by default on labs (T357054)]], [[gerrit:1237348|Enable site notices on Minerva (T416644)]] (duration: 11m 20s)