With few exceptions, the important part of talk page archives is the actual discussion. Many lint errors arise from deprecated markup constructs that impact the readability of pages they appear on (a good example is closing tag semantics, which have changed in the past few years; many talk pages/archives from the distant past have malformed tags which, under the current parsing semantics, cause various styles like strikeout, superscript, or small to be applied to the entire rest of the page); therefore, I would argue, updating this markup is important for preserving the readability of these archives, and broadly speaking does not change the actual text, only the underlying markup and the styling applied to the text. In this light, these updates are desirable and positive. As for the purely preservationist perspective, well, the original markup is still present in page histories.

We provide tools for surfacing problems, and provide specific guidance where we need pages fixed ( https://www.mediawiki.org/wiki/Help:Extension:Linter#Why_and_what_to_fix ). But, I think it is up to individual wikis to figure out their policies around what to fix and how to fix. I imagine different wikis will have different policies. But, that said, to add to what @Dinoguy1000 said, some of these errors will affect readability of archived pages in the long run as the software evolves.

There is currently an ongoing discussion very closely relating to this on Meta that appears to be garnering consensus in the other direction/against this ticket/proposal.

Thanks @TheSandDoctor. I'm inclined to agree with the emerging consensus on that page as well.

I can totally empathise with not wanting to be distracted by edits that appear to add no value. When two ways of writing the syntax both technically work, then personally I would agree that archived content should remain as-is no matter how unusual, confusing or otherwise unpopular the old syntax may've been. Even if it was written that way by mistake, if it works, leave it! Anyway, that's my opinion. Local communities should make their own policies.

But I hope you can trust the developers that if there was a reasonable way for old syntax to continue to work, we would do so. If you find a linter rule has been deployed without the expectation that the affected syntax will break the rendering of those archived pages, then please contest the general deployment of that specific linter rule, and not the linter system itself or the ways users are helping fix the problems it found.

@Krinkle it is my understanding that deprecated font tags will be supported by the browsers,, is that not the case?

In T249483#6038342, @Billinghurst wrote:

@Krinkle it is my understanding that deprecated font tags will be supported by the browsers,, is that not the case?

There is no guarantee that browsers will continue to support deprecated/obsolete tags/attributes and I think it's a reasonable statement to say that there is also no guarantee MediaWiki will continue to support deprecated/obsolete tags/attributes. (I make no statement or suggestion as to the timeline in which it will come to pass that browsers and MediaWiki will stop supporting deprecated/obsolete tags/attributes.)

In T249483#6038563, @Izno wrote:

In T249483#6038342, @Billinghurst wrote:

@Krinkle it is my understanding that deprecated font tags will be supported by the browsers,, is that not the case?

There is no guarantee that browsers will continue to support deprecated/obsolete tags/attributes and I think it's a reasonable statement to say that there is also no guarantee MediaWiki will continue to support deprecated/obsolete tags/attributes. (I make no statement or suggestion as to the timeline in which it will come to pass that browsers and MediaWiki will stop supporting deprecated/obsolete tags/attributes.)

It's also worth pointing out that any resemblance between a particular bit of MediaWiki markup and a particular HTML element is incidental; all markup is tokenized during parsing, so in theory any unique string could serve as the identifier for any given bit of parsed HTML. Ultimately this means it's perfectly reasonable for some bit of markup to be deprecated by the devs even if an exactly identical HTML element exists and is not deprecated by the W3C (of course, whether it would make sense to deprecate any particular bit of markup is its own question, e.g. I don't think anyone would sanely suggest to deprecate the <br> or <div> tags).

Can we close this? It's simply not a bug.

Yeah, I think this is a reasonable close (and Krinkle edit-conflicted my decline 😃 ). I will respond to one specific requested actionable: T231161: Add in/not in content namespace to Special:Linterrors is a request to make it easy to tell what needs to be fixed in a content namespace. Consider subscribing/following.