Page MenuHomePhabricator

Have a shorter name for <syntaxhighlight>
Closed, DeclinedPublicFeature

Description

In T237267, multiple users expressed that they use <source> instead of <syntaxhighlight> because of its shortness. As <source> is being phased out, we need another short alternative that saves typing time when using this tag on discussion pages.

Acceptance criteria

  • Find an abbreviation for syntaxhighlight. It should be no longer than 5-6 characters, but it should resemble the full name (one of the reasons to deprecate source is that it has nothing to do with syntaxhighlight). syntax? synhi? Something else?
  • Make it an alias to syntaxhighlight.
  • Document it on https://www.mediawiki.org/wiki/Extension:SyntaxHighlight and announce it in Tech News so that people are aware of it.

Event Timeline

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).

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).

  • 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)?

<sourcecode> sounds good

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.

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>?

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.

This comment was removed by jmnote.

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

<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.

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

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.

Krinkle added a subscriber: Krinkle.

I believe we generally don't create new syntax to aid in brevity of existing syntax. There are templates and such for alternative constructs that communities could reach for if preferred.

We do have precedent for aiding in writing of content. One being VisualEditor where it doesn't have to be typed, and one can click instead, or type <source or <syntax (see the question mark button in VE for other keyboard shortcuts). There isn't currently a ctrl+ something shortcut, but I suppose creating a task and proposing one could be done.

Apart from VE, there is also WikiEditor which has a menu that remembers expanded state with various one-click inserts as well. If this isn't there, it could be added there.

And lastly, there's Edittools (from CharInsert) which is another system we have and maintain for this purpose.

I'm declining this as it seems scope creep and unhealthy precedent to introduce more syntax based on this particular kind of rationale, unless e.g. we can come to an agreement to decommission one or two of the other aforementioned systems.

If a smaller group of people feel strongly about this. I suggest perhaps starting by popularising this as a user script first, e.g. shared at https://www.mediawiki.org/wiki/Snippets. Something like:

// T251116
$('textarea#wpTextbox1').on('blur', function () {
  this.value = this.value.replace(/<(\/)?anything(\s[^>]*)?>/g, '<$1syntaxhighlight$2>' );
});