Page MenuHomePhabricator

Have a shorter name for <syntaxhighlight>
Open, Needs TriagePublicFeature

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 27 2020, 11:47 AM

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.

matej_suchanek added a subscriber: matej_suchanek.

Something else?

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

Xqt added a subscriber: Xqt.Jul 15 2020, 8:41 AM

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

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

matmarex removed a subscriber: matmarex.Jul 15 2020, 6:52 PM
jmnote added a subscriber: jmnote.Oct 25 2020, 12:06 PM
This comment was removed by jmnote.