Page MenuHomePhabricator

Keep the pipe trick ([[Piped link|]]) syntax in wikitext instead of converting it at pre-save transform
Open, LowestPublic

Description

Author: wikimedia-bugzilla

Description:
We should keep the [[w:pipe trick|]] as it is entered instead of converting it to [[w:pipe
trick|pipe trick]]. The pipe trick is clearer, easier to read, takes less space, and demonstrates
to newer users that it is possible.


Version: unspecified
Severity: normal

Details

Reference
bz5004

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:07 PM
bzimport set Reference to bz5004.
bzimport added a subscriber: Unknown Object (MLST).

As was pointed above by Chris Wood, and at wikitech [1] by Aryeh Gregor, this trick should be part of the saved wikitext, not pre-converted on saving the page.

[1] - http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/044359.html

conrad.irwin wrote:

A patch to fix this

I am not comfortable with fixing this myself, it seems like a very drastic change for very little benefit (particularly now the pipe trick works during normal parsing too).

While the usabiltiy concern that it might be less easy to read the wikitext if the pipe trick is left, was countered by the argument that then people would find out about the pipe trick sooner, and thus increase productivity.

The other downside is the possibility that this will cause problems for consumers and future parsers of wikitext, who have to reimplement the pipe trick for themselves; particularly if they are not expecting to find unexpanded links in the source. At the moment, having it in both places allows templates to work using the "in-parse" mode, while normal pages (and thus normal consumers) will always see the expanded version.

As it seems there is an overwhelming amount of support for removing as much as possible from the PST, I have attached a trivial patch to fix this issue. (anyone applying it will need to upgrade the parser tests that it breaks)

Attached:

Another reason to get rid of it: it prevents saving certain kind of syntax (affecting for example translations at translatewiki.net).

Changing severity from enhancement to normal.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

(In reply to Conrad Irwin from comment #2)

Created attachment 7093 [details]
A patch to fix this

patch -p0 > patch
patching file includes/parser/Parser.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file includes/parser/Parser.php.rej

Attached:

I don't really agree with this request. I prefer to see what is about to be saved.

Jdforrester-WMF lowered the priority of this task from Low to Lowest.Feb 14 2017, 1:47 AM
Jdforrester-WMF subscribed.

I'm not sure this is a good idea, though I can understand the argument about removing magic from "unseeable" places and making it more explicit.

Also, this would increase the complexity of wikitext parsing (which happens on every read) but save the complexity of wikitext saving (which happens only on every edit), which isn't ideal for performance reasons. ;-)

I don't really agree with this request. I prefer to see what is about to be saved.

Your comment was confusing. Did you get it backwards somehow? I definitely support this request because, as you said, I expect to see what is about to be saved. Expanding pipe tricks definitely feels like a strange or bugged implementation of pipetrick functionality. The underlying page is a simple text file. I expect WITIWIG behavior. What I Type Is What I Get(saved). Pre-save transforms should be kept to an absolute minimum. The only exceptions I can think of are the extremely noteworthy subst and signature cases. Those are critically important enough to violate textfile WITIWIG expectations.

Also, this would increase the complexity of wikitext parsing (which happens on every read) but save the complexity of wikitext saving (which happens only on every edit), which isn't ideal for performance reasons. ;-)

Jdf, please re-evaluate. You're trading off high value brain cycles for CPU cycles. Human usability should definitely outweigh an undetectable number of CPU cycles. This fix would help newcomers to edit more efficiently, and it makes the wikitext shorter, easier to read, and easier to edit. The pipe trick very efficiently expresses a specific intent. No neurons waste effort evaluating whether the pre-pipe-part matches the post-pipe-part. Expanded pipe tricks take more eye-cycles & brain-cycles to skip, and they are significantly more cumbersome to copy/paste. This issue is particularly impactful when it comes to signatures. All of these expanded pipe tricks needlessly clutter up discussion pages, and hinder the very common copy-pasting of piped user links.

If there are meaningful concerns about read performance then I'm sure there vastly more impactful wins to be had.