Last modified: 2011-03-13 18:06:27 UTC
Alternate link text is very often a substring of the link text itself: [[Largemouth bass|largemouth]], [[Harrisburg, Pennsylvania|Harrisburg]], [[The Holocaust|Holocaust]], [[Neutral country|neutral]] The proposal is to allow such cases to be specified as follows: [[^largemouth^ bass]], [[^Harrisburg^, Pennsylvania]], [[The ^Holocaust^]], [[^Neutral^ country]] which would mean only display the text enclosed in carets, thus saving the repetetive typing. This would be in addition to the pipe markup, not a replacement for it. This idea was posted on the Wikipedia:Village pump (proposals) page on July 7, 2005 and was well received.
Similar ideas were kicked around in 2002, but never accepted as it simply makes things much more complex than it needs to be. See old closed feature request: http://sourceforge.net/tracker/index.php?func=detail&aid=586885&group_id=34373&atid=411195 It also breaks the ability to use titles with that character, which may break links.
(In reply to comment #1) > Similar ideas were kicked around in 2002, but never accepted as it simply makes things much more > complex than it needs to be. > See old closed feature request: > http://sourceforge.net/tracker/index.php?func=detail&aid=586885&group_id=34373&atid=411195 > It also breaks the ability to use titles with that character, which may break links. Well, OK, but if it was proposed before and now it's proposed again, that would seem to imply that it's a useful feature (note previous comments: "Looks insteresting and useful", "I actually rather like this idea"). I assume that it would not be that difficult to run a query to find out how many times the text following a pipe in a link appears to the left of the pipe. I think you'd find it's a very common phenom. The caret might not be the best character to use (originally proposed using the tilde, but it was objected that not all keyboards have the tilde). Seems to me that the previous proposal to use square brackets was, indeed, confusing. What about curly brackets: [[{Harrisburg}, Pennsylvania]] = [[Harrisburg, Pennsylvania|Harrisburg]]?
While it looks cute, it provides no new capabilities in return for making the syntax more complicated. Cost: * Wiki becomes harder to use * Increased likelihood of bugs Benefit: * None This was my eventual analysis and is why that feature request was closed. This is likely to be closed as WONTFIX as well unless something changes.
(In reply to comment #3) > Cost: > * Wiki becomes harder to use Only until you learn the syntax, then it theoretically becomes easier to use. > * Increased likelihood of bugs true > Benefit: > * None * Less typing
(In reply to comment #3) > While it looks cute, it provides no new capabilities in return for making the syntax more complicated. > Cost: > * Wiki becomes harder to use > * Increased likelihood of bugs > Benefit: > * None > This was my eventual analysis and is why that feature request was closed. This is likely to be closed as > WONTFIX as well unless something changes. I have trouble seeing the validity of the "Wiki becomes harder to use" objection. This is the sort of markup where you look at the displayed page, you look at the markup, it's obvious what's going on. As for "Benefit: None", I can't tell you how often I curse the repetetive typing of the piped alt text. It's especially annoying when doing a list of things, all of which have the same text you want left out-- a list of towns all in the same state, a list of lakes or rivers, a list of trees (where they're all pines) or fish (where they're all different bass). Not to mention the possibility of introducing a typo in the alt text.
I think the "Wiki becomes harder to use" objection comes from the fact that every new piece of wiki syntax adds to the learning curve which must be followed by new contributors. It may be obvious to *you* what it does, but some people require quite a lot of experimentation before they get the hang of such things. That said, I agree that this would be a relatively easy one to spot what's going on. As discussed at bug 845, there are ways we could extend the existing "pipe trick" to other circumstances - although it's voodoo in that you can't learn by example because it's never there in the source, that approach does keep the syntax simpler for new users to read. It's also less likely to cause bug headaches, because an on-save translation can be manually fixed if it's wrong, whereas parsing errors can happen to existing text and require the software to be fixed before they become correct again. The other observation worth making is about how well existing syntax is used - I often come upon completely unnecessary things like [[Computer_program|computer programs]], presumably written by editors who don't realise that [[computer program]]s is exactly equivalent. While it seems wasteful to go round seeking out and correcting such inefficiencies, the more ways there are of doing one thing, the more confusing the source becomes, as examples of all of them will proliferate depending on the editor.
I still have trouble accepting the "Wiki becomes harder to use" objection. Rowan Collins writes "every new piece of wiki syntax adds to the learning curve which must be followed by new contributors". But this is an entirely optional syntax-- it need not be followed by new contributors. The pipe trick continues to work exactly as before. It simply becomes unnecessary whenever the display text is a subset of the link text (which is, I would guess, better than half the time). The point about existing syntax being poorly used is well taken, except that I see relatively few instances, given the number of novice editors at work.
