I can't speak for anyone else, but its (lack of) resemblance to <syntaxhighlight> was not one of the reasons I had in mind when I proposed the deprecation of <source>, and similarly I don't think there's any reason to require a new shorthand element to have a resemblance to <syntaxhighlight>. To that end, maybe a tag name like <codehighlight> or <coloredcode>? I'd also suggest <sh>, but I have no idea how safe it'd be adding a two-character tag when it's not inconceivable that a tag of the same name could be added to HTML at some point.

More generally, if you wanted some form of the word "highlight" in the alias, the spellings "hilight" and "hilite" could also be considered, though I can't say anything about how non-native-English speakers would handle them. "Color" is also worth thinking about, but needs a bit of care because it has potential for being confused with the deprecated color HTML attribute (which is why I didn't suggest <codecolor> above).

In T251116#6086641, @Dinoguy1000 wrote:

I can't speak for anyone else, but its (lack of) resemblance to <syntaxhighlight> was not one of the reasons I had in mind when I proposed the deprecation of <source>

I was absolutely sure someone explicitly wrote this, but now I can’t find it either. Maybe I was just dreaming…? Nevertheless, my own opinion is also that resemblance to the full name is important, even though it may not be priority number one. However, some reference to (source) code is absolutely necessary—<color> may refer to setting the background/text color, a colored box in a map legend etc. <sh> also came into my mind, but in addition to its too shortness and thus ambiguity, it’s the executable name of the Bourne shell, which makes me think it’s only for shell scripts (or is it just me?). <codehighlight> and <coloredcode>, in contrast, are too long, not much shorter than <syntaxhighlight>.

Strongly opposing.

It puts a burden on many others:

• Those editors who encounter a rare keyword they never heard about. They need to check the manual and find out that it is just another name for something they know very well.
• Every search by Cirrus would need to be done twice, one time for the real one and a second time for the abbreviation.
• Every software, gadget, parser would need to be prepared and modified to deal with two keywords. Three, since some source may be found as well.

In summary: This is an invention which is focussing that one time one editor will save a few seconds when typing manually, but will put days and months and years on the shoulders of those who will follow in the decades later.

• Smart people do not type syntax keystroke by keystroke.
• At least you have a crib on your hard disk, a cheat sheet as simple text file, and you insert template and syntax patterns by C&P if you need something very often.
• Many people created a user page with a cheat sheet for their personal needs with links and template and syntax patterns.
• The world is moving towards editing tools, like VisualEditor. German Wikipedia is maintaining a gadget to insert the entire element pattern for more than a decade, we need just one click. From mid of 2000s there is Extension:CharInsert which may be configured to insert important things when source editing is done. Many other code inserting gadgets are used on wikis.
• Somebody who is not frequently using that element will need a manual page anyway, at least to get the required language code. There you may do C&P for the element pattern. Everything better than typing manually keystroke by keystroke the entire syntax.
• C&P does not make typing errors, nor do you need to recall whether it has been hilite or highlight.

The decision has been made a decade ago, at that time some other name for code markup which puts things in bold, italic and colours might have been suggested. Now it is done.

• Code is dedicated to be self explaining, not cryptic. That is a general blocker for all smart abbreviations from the era of Unix nerds, at least to make abbreviations persistent in source code. A personal shortcut to trigger some action is short by nature, but does not leave any trace and does not affect other people.

You suggest copy&paste as a faster solution. It is not. By the time I open my text file or user page, by the time I move my hand from the keyboard to the mouse and click on CharInsert’s toolbar (it’s far from being keyboard accessible!), I typed the full tag name three times. For larger code blocks like frequently-used templates, I use a browser extension, which is way faster than any of your suggestions, but still slower than simply typing a such short word. If you want to keep only the long version, perform a pre-save tranform (like with applying subst: or expanding signature tildes).

In T251116#6087707, @PerfektesChaos wrote:

• Every software, gadget, parser would need to be prepared and modified to deal with two keywords. Three, since some source may be found as well.

For example? What are the tools that absolutely need to process wikitext themselves instead of relying on the MediaWiki parser? They are broken by any other (non-alias) new tag anyway; wherever possible, tools should do parsing with the MediaWiki API.

Something else?

<sourcecode> (10 chars but not so hard to type)?

In T251116#6303830, @matej_suchanek wrote:

Something else?

<sourcecode> (10 chars but not so hard to type)?

<sourcecode> sounds good

In T251116#6303830, @matej_suchanek wrote:

Something else?

<sourcecode> (10 chars but not so hard to type)?

<sxhl> (4 chars only.)
See https://en.wikipedia.org/w/index.php?title=Template:Sxhl&redirect=no and https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Sxhl&limit=500.

In T251116#6307773, @Cedar101 wrote:

In T251116#6303830, @matej_suchanek wrote:

Something else?

<sourcecode> (10 chars but not so hard to type)?

<sxhl> (4 chars only.)
See https://en.wikipedia.org/w/index.php?title=Template:Sxhl&redirect=no and https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Sxhl&limit=500.

I don't know what you were hoping to demonstrate with the WLH link for the en.WP redirect, but when you filter out non-transclusions, it's used on only 24 pages. Without actually looking into it, I wouldn't be surprised if basically all of these were added by the same person. This is cryptic, unpronounceable, and unmemorable, especially for non-English speakers.

In T251116#6307590, @Xqt wrote:

In T251116#6303830, @matej_suchanek wrote:

Something else?

<sourcecode> (10 chars but not so hard to type)?

<sourcecode> sounds good

I second this.

It seems very silly to me to deprecate the existing alias just to immediately invent a new one. I was not following the previous task; can anyone explain what is wrong with using <source>?

<source> is a HTML5 tag for embedding media.

I see. I'm not entirely sure if that's a good enough reason for the disruption, but at least there's a reason. Thanks.

In addition to be long, syntaxhighlight is subject to typos (from French-speaker point of view).

In T251116#6309463, @matej_suchanek wrote:

<source> is a HTML5 tag for embedding media.

Given how MediaWiki handles media ([[File:filename]]), and since in HTML standard, <source> must be inside <video>, <audio> or <picture>, un-deprecating <source> alias seems me the best solution.

It is confusing to use well defined HTML elements for something different.

Never ever try to type elements and syntax from scratch.

Smart people are using C&P and copy the entire skeleton into source edit area, or are using tools for insertion:

<syntaxhighlight lang="">
</syntaxhighlight>

If not attempting to type syntax on the keyboard but have a guide with explanations and patterns for C&P it is not error-prone at all. German users are not native English writers either.

A <source> element, even if colliding with HTML, could be understood as wikitext <code> or other. This would cause unlimited confusion.

In T251116#6977220, @PerfektesChaos wrote:

Never ever try to type elements and syntax from scratch.

Never ever tell us how to get things into the edit box. I can type pretty fast, so typing <source> is way faster for me than any smart method, which inevitably involves something other than the basic typing keys (Ctrl/Alt/whatever key, mouse etc.). And I don’t mistype it. Even typing <syntaxhighlight> is faster than any auxiliary methods if I happen to type it correctly for the first time. I do have methods to avoid typing things, but I save it for much more complicated/much longer snippets.

I don't think it makes sense to add a new parser tag just for the purposes of having something shorter. I would however support a shorter alias in VisualEditor, etc. that prompts to insert <syntaxhighlight>... when typed, and it looks like that's already the case. If you type just <syntax it'll open the dialog. Is that good enough?

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/SyntaxHighlight_GeSHi/+/refs/heads/master/modules/ve-syntaxhighlight/ve.ui.MWSyntaxHighlightDialogTool.js#37

In T251116#7329929, @Legoktm wrote:

I don't think it makes sense to add a new parser tag just for the purposes of having something shorter. I would however support a shorter alias in VisualEditor, etc. that prompts to insert <syntaxhighlight>... when typed, and it looks like that's already the case. If you type just <syntax it'll open the dialog. Is that good enough?

I don’t know how other people use SyntaxHighlight, but for me, it’s almost nothing: I use it on talk pages 99% of time, where VE is not an option (DiscussionTools has a VE mode, but it doesn’t support multi-line extension tags, and SyntaxHighlight blocks are usually multi-line). I rarely write code blocks in articles, but often add snippets of SPARQL and SQL queries, Pywikibot scripts, Lua modules etc. to talk pages.