Use of the <source> tag has been discouraged since May 2009 (the same day the <syntaxhighlight> alternative was added), because of the existence of an HTML element by the same name with an unrelated function. However, "discouraging" the use of a bit of markup, without any formal deprecation, doesn't accomplish anything, to the point that not only are there people who willfully use <source> instead of <syntaxhighlight>, but there are people who actively object to its replacement with <syntaxhighlight>. A decision should be made to either formally deprecate the <source> tag with the aim of removing support in the future, or to stop discouraging its use at all.
|mediawiki/extensions/SyntaxHighlight_GeSHi||master||+49 -5||Add tracking categories when deprecated syntax is used|
- Mentioned In
- T257899: replace <source> by <syntaxhighlight> in pywikibot scripts
T251116: Have a shorter name for <syntaxhighlight>
T250459: Publish a Python script to handle the SyntaxHighlight deprecations
rESHGf5b61126da85: Add tracking categories when deprecated syntax is used
T241636: Syntaxhighlight: Add tracking category when `enclose` is used
- Mentioned Here
- T20820: Cannot parse source code containing < source >
P10045 Use of <source> by wiki
T39042: Remove <source> syntax from SyntaxHighlight (GeSHi)
Sort of? I'm not looking specifically for deprecation and removal in this task (though that's what I personally would prefer), just a solid resolution to the "discouragement" of the syntax, one way or the other.
I'd say I wasn't actually aware of that issue, either, but apparently I left a comment there almost two years ago: T39042#3884198.
So its clear that the current "discouragement" isn't very effective. If it is officially deprecated with plans to remove it, there is then a valid rational for a bot task to replace uses (otherwise it would be a cosmetic edit):
- Add a tracking category when <source> is used
- Officially deprecate using <source> as part of the 1.35 cycle, with warnings that it may be removed in 1.36
- Carry out replacements on the wmf wikis
- Remove support in 1.36
That sounds good to me, though I'm leery on starting in on a course of action like this with only three participants in the discussion, especially without any explicitly developer-originating input/perspectives on it. (Though if you or @Izno have been speaking from a developer perspective here, feel free to shatter my illusions. =) )
Strong support for scheduled termination.
- It is not a good idea to maintain current doublespeak in eternity. One day this has to be discontinued.
- It has been discouraged for a couple of years now, it might be 2021 when support for source ends.
- Throwing a maintenance category for a year is a low level action to give opportunity for a smooth change of affected pages.
- It is most confusing in a syntax description that one thing known with an entirely different meaning is an alias for something with another major identifier.
- Even more if <source> is occurring within the displayed HTML code.
German Wikipedia migrated soon after renaming all encyclopedic articles and active project pages.
- Some recent C&P from enwiki, some user pages or archived discussions might still use source but can be cleaned up by bot easily.
Once the patch is merged and deployed, and its easier to track usage, I'll file bot requests on the most affected wikis (and if there are less that eg 100 uses just replace manually) - can I state that it is now "official" that it will eventually be removed?
See P10045 for number of uses of source by wiki
Please pay attention thag there is at least one bot (on Commons, at least was a year ago, didn't check later) that creates new pages with this tag on the fly, so the replacement only will not prevent from new ones to appear.
Looks like you all have this under control already, but since @Legoktm tagged us here to solicit our opinion, wanted to add that we are on board with the cleanup (deprecation of <source> and fixing associated bots, etc). While the linter could also be used for this, given the straightforward nature of this and tracking-category based workflows of many editors, using a tracking editor to clean this up is okay with us since it also eliminates a dependency on us. But, if there are any specialized tracking required that needs linting, let us know.
I understand that there is problem with confusing name, but the new
<syntaxhighlight> is more prone to typing error (syntaxghilight), longer and less understandable for non-english speakers.
Pitty, that new name is not shorter.
Yeah, this is sad because the "syntaxhighlight" is longer, and more complex which means slightly more PITA in real life. I have been avoiding using the "syntaxhighlight" because it has been PITA for me to type "syntaxhighlight" without my fingers not confusing themselves.
Same here. Couldn’t we add an abbreviation that abbreviates syntaxhighlight (in contrast to source, which has nothing to do with it)? This would free up source with its multiple issues, yet it would save us much typing.
If you would like to add a new tag that is recognized and works in addition to syntaxhighlight, please file a new task; this task was related to the fate of source, and has been resolved
No one is obligated to open a new task. If the request is something you want to see, the best way to ensure a task is filed for it is to go ahead and file it yourself, rather than hoping someone else will instead.