Page MenuHomePhabricator

Decide the fate of <source>
Closed, ResolvedPublic

Description

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.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 4 2019, 3:16 PM
DannyS712 added a subscriber: DannyS712.EditedDec 1 2019, 10:27 AM

Proposal: formally deprecate, add a tracking category when it is used

Dinoguy1000 updated the task description. (Show Details)Dec 1 2019, 2:09 PM
Dinoguy1000 updated the task description. (Show Details)

@Dinoguy1000 could we add a tracking category when it is used, for now, so that its easier to see the extent of changes needed on-wiki?

could we add a tracking category when it is used, for now, so that its easier to see the extent of changes needed on-wiki?

I'd be fine with that, though TBH I'm not sure why you're asking me; I'm not the one who'll be implementing anything resulting from this issue.

Izno added a comment.EditedDec 31 2019, 4:14 PM

(Mind you, I support deprecation and removal too. There are only 10k uses on en.wp and that's the largest wiki. Only 2.8k of those are in the mainspace.)

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.

There are only 10k uses on en.wp and that's the largest wiki. Only 2.8k of those are in the mainspace.

That sounds good, until you do the same searches for syntaxhighlight instead and find it's only used 3.8k times in total, and only 812 times in the mainspace.

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.

There are only 10k uses on en.wp and that's the largest wiki. Only 2.8k of those are in the mainspace.

That sounds good, until you do the same searches for syntaxhighlight instead and find it's only used 3.8k times in total, and only 812 times in the mainspace.

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

Proposal:

  • 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

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

Proposal:

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

Legoktm added a subscriber: Legoktm.

I definitely think it's worth revisiting this since T39042 was decided 8 years ago since our stance on what changes to wikitext we're willing to make is rather different. I would suggest getting the input of the Parsing-Team and then probably writing an RfC for it.

Add a tracking category and stop supporting.

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.

Change 562085 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/SyntaxHighlight_GeSHi@master] Add a tracking category when deprecated syntax is used

https://gerrit.wikimedia.org/r/562085

DannyS712 claimed this task.Jan 6 2020, 6:31 AM
Restricted Application added a project: User-DannyS712. · View Herald TranscriptJan 6 2020, 6:31 AM
Nirmos added a subscriber: Nirmos.Jan 6 2020, 8:56 AM

Agree with deprecation and eventual removal of <source>.

DannyS712 added a comment.EditedJan 6 2020, 10:55 PM

Agree with deprecation and eventual removal of <source>.

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

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?

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.

ssastry added a subscriber: ssastry.Jan 7 2020, 3:49 AM

I definitely think it's worth revisiting this since T39042 was decided 8 years ago since our stance on what changes to wikitext we're willing to make is rather different. I would suggest getting the input of the Parsing-Team and then probably writing an RfC for it.

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.

This comment was removed by DannyS712.

I definitely think it's worth revisiting this since T39042 was decided 8 years ago since our stance on what changes to wikitext we're willing to make is rather different. I would suggest getting the input of the Parsing-Team and then probably writing an RfC for it.

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.

Can the parsing team take a look at the patch provided?

Change 562085 merged by jenkins-bot:
[mediawiki/extensions/SyntaxHighlight_GeSHi@master] Add tracking categories when deprecated syntax is used

https://gerrit.wikimedia.org/r/562085

JAnD added a subscriber: JAnD.Apr 16 2020, 6:13 AM

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.

<syntaxhighlight> is not particularly "new"; it was added as an alternative to <source> in revision 50696, in May 2009 (in response to T20820). Not that this invalidates concerns for non-English speakers, of course, but I don't have any good answer for that.

DannyS712 closed this task as Resolved.Apr 16 2020, 5:08 PM

Fate: officially deprecated, to be removed

revi added a subscriber: revi.Apr 17 2020, 2:13 PM

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.

Dinoguy1000 updated the task description. (Show Details)Apr 21 2020, 1:00 AM

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.

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

this task was related to the fate of source, and has been resolved

Just like when @revi commented on it. I can open a new task, of course, but why me, and not revi?

this task was related to the fate of source, and has been resolved

Just like when @revi commented on it. I can open a new task, of course, but why me, and not revi?

I didn't see revi's comment

this task was related to the fate of source, and has been resolved

Just like when @revi commented on it. I can open a new task, of course, but why me, and not revi?

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.