Last modified: 2006-06-07 03:30:22 UTC
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> [[http://www.example.com|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.
This is probably a dupe, but I can't find the older entry at the moment.
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 [[https://secure.example.com/exec/Jack%20Jones/foobar.pl?action=view&product_id=77bg49a3#c49|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 [[http://example.com||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...
> 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 [[http://example.com||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.
(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 [[http://example.com||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...)
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.
One question. Why bother? The syntax we have is fine, isn't it? This seems like a needless change to me.
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
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.
