Last modified: 2011-03-13 18:05:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4308 - RFE: pipe trick uniform syntax
RFE: pipe trick uniform syntax
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-19 00:54 UTC by William Allen Simpson
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description William Allen Simpson 2005-12-19 00:54:46 UTC
Having just read several other bug/enhancements, such as (Bug 845) and (Bug
3527), and waded through en: documentation before proposing, it seems to me that
the "pipe trick" doesn't behave the way that many folks expect. In particular,
the effect of leading colons and other marks has unexpected behaviour. Part of
the problem is that it doesn't appear until after saving, so folks don't know
whether it worked properly.

Understanding that it won't affect the actual database (as a preprocessing
trick), I propose that a more complete and uniform syntax be adopted.

Leading empty pipe -- "[[|" -- keep leading elements.  That is, "[[|One, Two]]"
yields "[[One, Two|One]]".  And "[[|One (Two), Three]]" yields "[[One (Two),
Three|One]]".

(Note: This would replace the current parentheses pipe trick in a
non-astonishing way, and might be easier to parse.  It would handle nearly all
the requested enhancements, including the odd placenames.  This would be more
consistent with expectations, and should work for any non-blank specials.)  

Leading multiple empty pipes -- "[[||" or "[[|||" -- keep multiple leading
elements.  That is, "[[|||One, Two, Three, Four]]" yields "[[One, Two, Three,
Four|One, Two, Three]]".  

(Note: It's been requested, but not sure that it's worth the effort.  But it
should still be documented for future use, or to avoid conflicts, or just to
disallow.)

Leading special pipe -- "[[ |" or "[[ |/|" -- keep leading elements using the
specified special, rather than just any special.  That is, "[[ |One Two]]" would
yield "[[One Two|One]]".  And "[[,|One Two, Three]]" would yield "[[One Two,
Three|One Two]]". 

(Note: This should be possible syntactically, as these are not legal leading
links.  Perhaps these should be limited to a few specials, or even just blank.
The blank form has been requested repeatedly for "Placename type, Division,
Country" to extract the Placename alone.)

Non-empty lead with single pipes in the middle would operate as proposed in (Bug
3527).  That is, "[[Some|thing|where]]" yields "[[Something|Somewhere]]".

(Note: the two single pipes are probably closer in user expectations from
template parameters, and better than trying to recognize "||" or "|-", but the
programmers will tell us.)

Trailing empty pipe -- "|]]" -- keep trailing elements.  That is, "[[WP:VIP|]]
yields "[[WP:VIP|VIP]]".

(Note: This is what would be used for colons, but handled in a more consistent
manner.)

Trailing multiple empty pipes -- "||]]" -- keep multiple trailing elements. 
That is, "[[:en:WP:VIP||]]" yields "[[:en:WP:VIP|WP:VIP]]".

Trailing special pipe -- "| ]]" or "|/]]" -- keep trailing elements using the
specified special, rather than just any special. 

(Note: Currently, these are minor errors yielding blank spaces and other wierd
behaviour.  Now they do something, giving a visual indication to future editors.) 

Combining the techniques should work as expected.  That is, parse the leading
and trailing elements, generate the combined display string.
Comment 1 Brion Vibber 2006-10-04 16:35:33 UTC
I got lost two paragraphs in -- this is not simple or consistent, it's jut confusing. :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links