@Dinoguy1000: <source> is deprecated, but not removed yet. I think it should not be removed from the documentation as long as it works—feel free to add a huge warning advising users not to use it, but not mentioning it while it’s still used on all over Wikimedia creates even larger confusion than what was before. For example a user may wonder why a page ends up in Category:Pages with syntax highlighting errors when there’s no <syntaxhighlight> on the page at all (only <source> tags); if <source> is also mentioned, it’s more clear the two are synonyms (at this time).
Topic on Extension talk:SyntaxHighlight
It is still mentioned, at the end of the "Usage" section. I don't believe, given its current status and pending removal, that more than that mention is warranted (though the tracking category that gets added when it's used should be included).
Here's more general details on the removal: https://phabricator.wikimedia.org/T237267
Please don't remove the "source" alias, before letting the extension generate a tracking category, and allow tracked pages to be updated.
The problem is that "source" is much easier for most wiki users, that have difficulties to properly get the orthograph "syntaxhighlight" (or is it "syntaxhilite"?) without typos (and what is the correctc capitalisation between the two words?) May prefer "source", which is evident (don't be limtied to the fact that internally you use some highlighting library like GeShi or other, that uses the term "highlight" or "hilite"). So there are in fact MORE needed aliases with the "syntaxhighlight" term (which is very errorpone), but none for "source", which is definitely the best choice and should be the canonical name of the tag in MediaWiki ("syntaxhighlight" is a legacy).
If "source" does not make evidence that the source code will be highlighted (or because it has another use in HTML5) or this is indicating source code, then use "beautify" or "colorcode", or "programming" which also makes more evident that the parameter "lang" is not specifying a humane language (BCP47) but a programming language or just "syntax" (drop the term "highlight" kept only as a legacy alias); or support it only as an extended attribute of the "code", "tt", or "pre" elements (but then change "lang" parameter name into "syntax" or "as" for the XML-like syntax of this extension):
<code #tag:syntax:as="C">some code in C</code>{{#tag:syntax|some code in C|as=C}}
(I wonder if MediaWiki supports hooks for custom attributes in the HTML/XML-like syntax, instead of just custom elements).
And note that there's still the problem of the unsafe embedding for the source code (see the other message about HTML-unescaping, which is needed to avoid havoc with the wiki parser, falsely interpreting the source code and modifying it)
@Verdy p: The extension is already generating a tracking category on pages using the old source tags.
@Dinoguy1000: I think it’s much more confusing for readers for the time being; especially for those who get there using a section link like Extension:SyntaxHighlight#Syntax highlighting error category. I don’t think it makes sense to remove references for it everywhere (I’m speaking about such documentation pages, not actual usage, of course). The deprecation notice could be made more prominent (like adding a colored box on the top of the page), but that’s all. And if you think keeping them will make replacement bots more complicated, you’re wrong—they should be made more sensitive anyway to stop doing replacements like the one I reverted here—<source> is in nowiki, and has nothing to do with the SyntaxHighlight extension at all…
@Verdy_p: See phab:T251116; further discussion about whether removing <source> is a good idea or whether there should be another short name is off-topic here.
Note that the addition of the tracking category is very recent (I did not see it until very recently, this was not announced and I do not see it on every wiki, so the "deprecation" was decided by developers even if this was annouvned as their "intent" a long time ago. But the change to use "syntaxhighlight" only was never voted, and it is a nightmare for most editors, so the prefered name chosen is really on topic: ir could have just been "syntax" or we could have just used a "namespaced attribute" to standard HTML "pre", "tt", "code" tags, like " ... ).
As well you kept the non-conforming use of the required lang="*" attribute (whose value is not the BCP 47 language tag, but a symbolic name for the programming language, but could also have been the type="*" attribute like for standard "script" elements)....
The reason for the deprecation of the "source" element is also very fuzzy/doubtful:
- we are actually NOT parsing HTML5 input, we just parse a MediaWiki syntax (that will then be used to *generate* HTML5) which has its own rules for acceptable elements/attributes and acceptable rules for self-closing tags, plus it adds its own private tags that are not HTML5 and the extra wiki-specific syntax for lists, tables, wikilinks and a few styles (bold, italic, monospaced blocks, and headings). There's absolutely no need for the Mediawiki text to be HTML5 compliant: it has never been compliant with HTML, and it will never be (unless we abandon the Mediawiki syntax completely for editing pages in pure HTML5, but then how will we even support templates or even this syntax coloring extension?).
- we still don't accept random HTML5 input, so we still don't support on input any newer semantic elements like "heading"/"section"/"footnote"/"summary"/..., or and not even some older but standard and non-dangerous useful elements from HTML4 like "colgroup" (wanted since long!), or "thead"/"tfoot"/"tbody"/"rowgroup"...
- The only convincing reason for deprecating the "source" tag is that because you want to add it to Mediawiki so that it will match the HTML5 semantic tag. But why only this one? Why we still don't have "colgroup"?
Clearly the deprecation anticipates a possible future change that has not even been prepared and fully designed, never been discussed (for its scope of application). For now there's clearly no need at all. And the replacement tag proposed is horrible to type for most people and its current full name was not approved by anyone.
Such deprecation just annoys people needlessly (just like the previous deprecation of self-closing tags when tags may have no content (like <s id="x"/> like in the XHTML standard syntax, which is shorter and simpler than <s id="x"></s> to place a content-less anchor on a page: you've created unnecessary work on every reviewers to maintain lot of pages without any added benefit)
@Tacsipacsi: mentioning source without including the fact that it is deprecated and soon to be removed, at every mention, is unacceptable. It doesn't matter if one mention of it does specify that, if any others do not, especially if they're on a completely different part of the page. This is plainly and clearly demonstrated by the fact that the page has listed source as "discouraged" since May 2009, and yet, over a decade later, it's still used so widely as to require a full and proper deprecation period, including tracking category and bot runs to clean up.
Adding an ambox at the top of the page isn't going to do much either; Wikipedia's extensive use of them for article issues has successfully trained people to ignore them, exactly the same as banner ads from past decades did for getting people to ignore any banner-style image elements on web pages.
Any further mentions of source that are added to this page must be clearly in the context of its deprecation and eventual removal, so there is absolutely no ambiguity about whether it should be used, especially for people who arrive at the page via a deep-link directly to a section.
So what about writing
<syntaxhighlight>or (deprecated)<source>
(listing <source> second everywhere; probably without the parentheses)? That would keep the references, but it would make clear deprecation is now a real thing. (And I think a banner is worth adding in addition to other notices, including this parenthesized one—probably not everyone will notice it, but it still helps the people who do.)
By the way, I don’t interpret that 2009 wording (which was used till this April) that the short name was discouraged. This wording states that the long name “may help avoid conflicts if your source code itself contains <source>”—most source codes don’t contain <source>, in which case (in my interpretation) this sentence doesn’t encourage either tag name over the other. (This is why I happily used the short version for years even though I knew about this part of the documentation.)
I just don't see the benefit on including a mention of source with every mention of syntaxhighlight. Other deprecated markup doesn't get this treatment. If the deprecated tag is mentioned every time the current tag is as well, it makes it sound like the documentation doesn't really think the tag should be deprecated, and encourages confusion and doubt in readers. To flip this on its head, the documentation used source largely without mention of syntaxhighlight for over a decade, and to my knowledge, no one complained about it. Why is it suddenly so important that we do the opposite?
The full wording is "In older versions [...] the extension used [...] This is still supported, but [...]"; this has always read to me as a clear discouragement of using source.
I don’t know what happened for over a decade and I don’t know when this over a decade was (my diff link above shows a state where the two were already equally represented). I’m not aware of any other deprecated markup either. I just see the current changes and would like to keep as much information as possible as long as it’s relevant (which is until it’s finally and fully decommissioned). But I see I won’t succeed…