I don't see this happening anytime soon, we can't just break backwards compatibility like that.

What backwards compatibility if you run a replace bot?

Besides isn't full functionality more important than backward compatibility?

(In reply to comment #2)

What backwards compatibility if you run a replace bot?

So you want to advice everyone that has syntax setup on their wikis to
a. learn how to operate a bot
b. run the bot and make the changes

I doubt many people/other users care about not being able to use the output in xml based format/exports etc...

(In reply to comment #3)

I doubt many people/other users care about not being able to use the output in
xml based format/exports etc...

That's not about XML format/export at all.

It's about displaying XML (eg. HTML5) syntactically hilited source on wikis without hacks.

d0ng2000 wrote:

(In reply to comment #2)

What backwards compatibility if you run a replace bot?

Besides isn't full functionality more important than backward compatibility?

I agree with Niklas in comment #1. Even though it would be nice to remove this feature completely, you still cannot just break legacy compatibility. A lot of users depend on this. Yes, you could use a bot/script to clean up the issue and replace it with your own. Just be careful that it does not unintentionally replace the wrong information.

To move this thread forward, if you would like to see a script which scrubs the usage of the old "source" tags then please submit one.

I see nothing wrong with creating a cleaning system. However if one is to be implemented then it would have to go through a very strict QA process.

Wontfixing this.

Just for the record, aside from valuing wikis that don't have the luxury of bot operators. We also need to consider:

• Processes that aren't stored on a wiki page.

Think for example a bot that may update a wiki page once a day or month. Fixing that _target page doesn't fix the bot that will overwrite that page once a day.

• Complex pages with wonderfully constructed meta-templates that may not literally contain <source ?*>, but could contain {{#tag: source}} and the many variations on that.

• Protected pages.

• ..

Speaking about backward compatibility when it's known that new parser is going to break bunch of current constructions seems to me at least inconsistent...

Could this be added as something that Extension:Linter tracks? (Would it make sense to do that?) This would provide an avenue for wikis without bot-operation expertise to update occurrences. In addition, support for using "source" could be sequestered behind a configuration variable (enabled by default) so that wikis which care to migrate could clean up all instances and then switch support off.

I'm curious whether it's possible to only enable the source tag when parsing old revisions (depending on timestamp), to fix the incompatibility for new content without breaking the rendering of old content.

Is there a non-theoretical extension developer blocked on this to support <source> for its HTML5 video semantics, in wikitext? I'm all for multimedia but I find this a bit hard to believe, especially since parser tags generally don't nest. So one could already implement a <video> tag today, that would accept (a somewhat-safe subset) of arbitrary HTML within it including <source>, and that should work fine even with SyntaxHighlight continues to support <source> as alias for it (which a community can choose not to use if they find it confusing or otherwise don't like it).

In T39042#7071773, @Krinkle wrote:

Is there a non-theoretical extension developer blocked on this to support <source> for its HTML5 video semantics, in wikitext? I'm all for multimedia but I find this a bit hard to believe, especially since parser tags generally don't nest. So one could already implement a <video> tag today, that would accept (a somewhat-safe subset) of arbitrary HTML within it including <source>, and that should work fine even with SyntaxHighlight continues to support <source> as alias for it (which a community can choose not to use if they find it confusing or otherwise don't like it).

I am reopening the task to be consistent with the prior decision. Either it's deprecated (and thus slated for removal) or it's not, and we decided it is, and subsequently patched to identify uses, and then someone ran a bot to replace it furthermore.

If you want to discuss whether that was the correct decision, the other task is probably a better place.... (I am not one to fall privy to sunk cost fallacy, but then I don't see why the actual "hard" deprecation of the tag was +2d, with quite a few WMF faces popping in...; in fact, the tag was, as documented in the other task, soft-deprecated a decade ago).

In T39042#7071538, @matmarex wrote:

I'm curious whether it's possible to only enable the source tag when parsing old revisions (depending on timestamp), to fix the incompatibility for new content without breaking the rendering of old content.

I think there are other extensions (halllooooo Translate + Parsoid) where that question is more interesting. Anyhow, I'm not real sympathetic to some desire to need it. We haven't figured out how to do it for templates, where there's probably an even greater desire for it. Why should extensions be different? (But if you want to spend time on that, feel free I guess. Volunteer project etc.)