Page MenuHomePhabricator

External link syntax should be the same as internal [[url|text]]
Closed, DeclinedPublic

Description

Author: ui2t5v002

Description:
Why is the syntax different for internal and external links? They are both
intuitively the same thing, yet are typed differently. How many times have you
seen an external link with extra brackets around it by accident? This is
confusing for newcomers and sometimes for the rest of us. Let's just use
[[link|text]] for both types of links:

[[Article name|text]] → <a href="/wiki/Article_name">text</a>

text → <a href="http://www.example.com">text</a>

We could leave the old syntax in place for backwards compatibility and just
encourage people to use the new.


Version: 1.6.x
Severity: enhancement
URL: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=29594115#Internal_and_external_links

Details

Reference
bz4110

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:58 PM
bzimport set Reference to bz4110.
bzimport added a subscriber: Unknown Object (MLST).

This is probably a dupe, but I can't find the older entry at the moment.

rowan.collins wrote:

Hm...

Firstly, like various other syntax change proposals, I'm unconvinced by this,
simply because of the vast number of users (and content!) already using the
current system. I know this particular case could have a "backwards
compatibility" option but this has a number of drawbacks, such as the fact that
the more ways there are of doing the same thing, the harder the syntax is to
learn by example, and the more code there is to maintain.

Secondly, while it's true that RFC 1738 says that "|" "must always be encoded
within a URL", I think there's a *visibility* issue with using it as a separator
after a long URL - consider a complex example like
49th comment vs
[https://secure.example.com/exec/Jack%20Jones/foobar.pl?action=view&product_id=77bg49a3#c49
49th comment] - I find it much easier to spot the gap in the latter style.
[Incidentally, discussion of Lee Crocker's radical syntax proposal covered the
idea of only ever using double characters, which would give us a link style of
[[foo||bar]] and |example, which creates quite a nice gap
IMHO.]

Finally, knowing how complex and fragile the internal link parsing is, I dread
to think how many programmer-hours it would take to get this working right, but
who knows, maybe someday someone will fully implement a sane parser...

Oh, we'd also have to work out whether http://example.com would be
equivalent to current [http://example.com] (auto-numbered style) or to a
displayed as-is "free link" (render as "http://example.com", just as [[example]]
would render as "example"). The latter seems logical if consistency is the aim,
but it means the autonumber feature can only be obtained through "deprecated"
syntax.

Well, that's my initial {£|$|€}0.02 on the idea, anyway...

ui2t5v002 wrote:

I think there's a *visibility* issue with using it as a separator
after a long URL - consider a complex example like

That applies to internal links with underscores and number signs and the current
syntax, too.

[Incidentally, discussion of Lee Crocker's radical syntax proposal covered the
idea of only ever using double characters, which would give us a link style of
[[foo||bar]] and |example, which creates quite a nice gap
IMHO.]

Hmm.. Where is this described? I don't see why it would be necessary or
helpful to use double characters.

Oh, we'd also have to work out whether http://example.com would be
equivalent to current [http://example.com] (auto-numbered style)

Yes.

rowan.collins wrote:

(In reply to comment #3)

I think there's a *visibility* issue with using it as a separator
after a long URL - consider a complex example like

That applies to internal links with underscores and number signs and the current
syntax, too.

Well, that's sort of true, but the majority of internal links are much simpler
than external ones - nearly all external links contain at least "/", and often
all sorts of garbage (&,=,%,etc) whereas pretty much only section-anchor
internal links contain much other than words and numbers (underscores can nearly
always be replaced with spaces, and should be, for legibility). And then, like I
say, I think something like "a||b" would be clearer than "a|b", *for all links*,
since it creates some visual space without needing to reserve the space character...

[Incidentally, discussion of Lee Crocker's radical syntax proposal covered the
idea of only ever using double characters, which would give us a link style of
[[foo||bar]] and |example, which creates quite a nice gap
IMHO.]

Hmm.. Where is this described? I don't see why it would be necessary or
helpful to use double characters.

Well, the proposal I was referring to is
http://piclab.com/lee/index.php/Wiki_syntax_examples which actually doesn't
stick *rigidly* to double-characters but the rationale as discussed on the
mailing lists was that having two symbols for each markup element makes parsing
easier as it makes false positives less likely and reduces special cases.
Consider why we use "[[foo]]" not "[foo]", and remember that these radical
discussions held consistency and forward-planning in higher regard than familiarity.

Oh, we'd also have to work out whether http://example.com would be
equivalent to current [http://example.com] (auto-numbered style)

Yes.

Yes, we'd have to work it out, or yes, it would be equivalent to current syntax
rather than consistent with internal link syntax? If the latter, why? (Remember,
we'd already be breaking familiarity in favour of consistency...)

Wiki.Melancholie wrote:

I really would love if the html address is seperated
from the text by something different than a space
character! Bug 2757 is a prime example for the need of a
better seperator, but not the only one (I already had
the wish to work with a different syntax several times,
when working on system messages and templates e.g.)

I think using two pipes "||" is a pretty good idea. But
maybe we could use the combination of a space character
and a pipe "␣|" (i.e.: " |"). So it would be possible to
use the old style syntax further on, but then there
would be a possibility to explicitly tell the parser to
allow space characters on the left side of the syntax
when it finds "␣|"! That would be an easy and sometimes
extremely helpful enhancement.

robchur wrote:

One question. Why bother? The syntax we have is fine, isn't it? This seems like
a needless change to me.

Wiki.Melancholie wrote:

No, personally I do not want to "change" it, but to
"extend" it, like i wrote.

For example:
With [http://searchengine.com/search?title={{PAGENAME}}
Search in Search Engine XY] it does not search for
"space character", but only for "space". Yes, for this
there is {{PAGENAMEE}}, I know. But for $1 in system
messages it doesn't work, yet! This is the problem at:
[[wikt:de:MediaWiki:Pagemovedtext]]; see bug 2757.

Another example:
http://de.wiktionary.org/wiki/Hilfe:
Ich_brauche_Hilfe#Wortverbindungen_in_Referenzen
Sorry for the wrapping of the link; but see the links
there, especially the first one ("rector Spiritus
rector") that is wrong and ugly.

Of course, mostly there is a different way, like you can
see in my last example; but is there a problem of having
the possibility of this syntax:
[http://abc.com/foo bar foobar |ABC.com with...]
beside the old one? So nothing would change, but there
would be a new "gimmick".

Best regards, and 'not really bothering ;-)',
Melancholie

john.varghese wrote:

The space is the only character guaranteed to not exist in an external link
*AND* is easily visible. Plus its working just fine now. Let's leave it as it is.