A couple of us were trying to figure out the syntax to add a working link to Special:Log in a template.
[{{fullurl:Special:Log|page={{{1}}}{{{2}}}}} log]
Works fine as long as parameter 2 is only one word. With a space in 2, only the first word shows up in the URL.
Tried wrapping {{fullurl:{{{1}}}{{{2}}}}}, but page= won't take a full page name.
[{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
Always works.
Is there some reason that fullurl stops encoding spaces to underscores when it runs into a pipe?
And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match the latest parser syntax?
On 4/25/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
[{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
Always works.
Because it's part of the full URL generated (see below).
Is there some reason that fullurl stops encoding spaces to underscores when it runs into a pipe?
The pipe adds parameters, basically {{fullurl:...}} seems to take this:
{{fullurl:<page>|<param-1>|<param-2>|...|<param-n>}}
And convert it into:
<page: converted to full URL>?<param-1>&<param-2>&...&<param-n>
And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match the latest parser syntax?
Probably because the latter would break existing pages relying upon {{fullurl: ...}}. Also, my understanding of {{# was that it was only used for parser extensions (not built-in magic words/functions).
Anyways, getting back to the problem of spaces in parameters, I don't think URL encoding parameters would work. A better solution (IMO) would be to add two new magic words:
{{urlencode:<string>}} {{urldecode:<string>}}
Which would allow us to encode/decode URL parameters as necessary. Now if a dev could be convinced this is wise, we'd be set. =)
-L
Locke Cole wrote:
William Allen Simpson wrote:
[{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
Always works.
Because it's part of the full URL generated (see below).
Look it is carefully. It uses a / to indicate the parameter, yet when you use the navigation bar, it generates: http://en.wikipedia.org/w/index.php?title= Special:Whatlinkshere&target=User%3AWilliam_Allen_Simpson
I just tried hand typing: http://en.wikipedia.org/w/index.php?title= Special:Whatlinkshere/User%3AWilliam_Allen_Simpson
So, both forms work, and I'm guessing that the slash form was created as a workaround for the parsing issue.
Is there some reason that fullurl stops encoding spaces to underscores when it runs into a pipe?
The pipe adds parameters, basically {{fullurl:...}} seems to take this:
{{fullurl:<page>|<param-1>|<param-2>|...|<param-n>}}
And convert it into:
<page: converted to full URL>?<param-1>&<param-2>&...&<param-n>
Yes, but it's parsing the parameters, yet failing to do the escaping on them. Seems like a *bug* to me. However, there might be a good reason, it's just not documented....
And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match the latest parser syntax?
Probably because the latter would break existing pages relying upon {{fullurl: ...}}. Also, my understanding of {{# was that it was only used for parser extensions (not built-in magic words/functions).
The "{{#if:" started using the standard PHP "if", although it now is a variant more like CPP #ifdef.
I'm not clear on the difference between parser extensions and magic functions. But I've not really looked at the code yet....
Anyways, getting back to the problem of spaces in parameters, I don't think URL encoding parameters would work. A better solution (IMO) would be to add two new magic words:
{{urlencode:<string>}} {{urldecode:<string>}}
Which would allow us to encode/decode URL parameters as necessary. Now if a dev could be convinced this is wise, we'd be set. =)
But urlencode and urldecode (and rawurlencode and rawurldecode) are PHP functions. They don't work the way we'd like, they encode spaces as '+' "for historical reasons" (that is, M$ visual basic), while we need '_'.
Maybe something like that is needed, but I'd rather concentrate on fixing possible bugs in this function before going off and making yet another almost but not quite the same as a floor wax and a dessert topping. (Mixing Hitchhikers Guide with Firesign Theatre metaphors.)
On 4/25/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
But urlencode and urldecode (and rawurlencode and rawurldecode) are PHP functions. They don't work the way we'd like, they encode spaces as '+' "for historical reasons" (that is, M$ visual basic), while we need '_'.
The method used need not be the standard PHP urlencode/urldecode functions. But I've rethought things a little, see below.
Maybe something like that is needed, but I'd rather concentrate on fixing possible bugs in this function before going off and making yet another almost but not quite the same as a floor wax and a dessert topping. (Mixing Hitchhikers Guide with Firesign Theatre metaphors.)
Agreed. And I've entered what I believe to be an accurate (or at least, accurate enough to diagnose and fix the issue) bug report at--
http://bugzilla.wikimedia.org/show_bug.cgi?id=5720
Vote/comment/etc. as you see fit. =)
-L
Locke Cole wrote:
Agreed. And I've entered what I believe to be an accurate (or at least, accurate enough to diagnose and fix the issue) bug report at--
http://bugzilla.wikimedia.org/show_bug.cgi?id=5720
Vote/comment/etc. as you see fit. =)
A fine report. And disconcerting to find that this has been a problem since http://bugzilla.wikimedia.org/show_bug.cgi?id=839 (2004-11-07).
Meanwhile, I'm still hoping that somebody can remember why the escaping stopped at the pipe, while the piped '|' arguments are properly converted to '&' arguments. This must have been a deliberate design decision.
And, while I'm thinking about it, what exactly the difference is between fullurl and fullurle? I haven't been able to find any documentation.
On 26/04/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
And, while I'm thinking about it, what exactly the difference is between fullurl and fullurle? I haven't been able to find any documentation.
As noted on http://meta.wikimedia.org/wiki/Help:Variable "Localurle and its counterpart fullurle perform additional character escaping on the resulting link, are intended for internal use only, and work in wikitext only for backwards-compatibility reasons. The unescaped versions should always be used in wikitext."
As I remember it, {{fullurle}} was implemented purely for the sake of completeness - since {{fullurl}} is just {{SERVER}}{{localurl}}, it seemed logical to create a counterpart for {{SERVER}}{{localurle}}, even though it's never actually used, and never has been.
-- Rowan Collins BSc [IMSoP]
"William Allen Simpson"
Locke Cole wrote:
William Allen Simpson wrote:
[{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
Always works.
Because it's part of the full URL generated (see below).
Look it is carefully. It uses a / to indicate the parameter, yet when you use the navigation bar, it generates: http://en.wikipedia.org/w/index.php?title= Special:Whatlinkshere&target=User%3AWilliam_Allen_Simpson
I just tried hand typing: http://en.wikipedia.org/w/index.php?title= Special:Whatlinkshere/User%3AWilliam_Allen_Simpson
So, both forms work, and I'm guessing that the slash form was created as a workaround for the parsing issue.
Have into accont that you can use the slash form with a simple wiki link [[Special:Whatlinkshere/User:William_Allen_Simpson]] while {{fullurl is intended to use when you need to pass extra parameter which cannot be created with wiki links, so you need a full url syntax.
And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match the latest parser syntax?
Probably because the latter would break existing pages relying upon {{fullurl: ...}}. Also, my understanding of {{# was that it was only used for parser extensions (not built-in magic words/functions).
The "{{#if:" started using the standard PHP "if", although it now is a variant more like CPP #ifdef.
I'm not clear on the difference between parser extensions and magic functions. But I've not really looked at the code yet....
Magic words are like environment variables. Parser extensions are functions called by a spell-word.
Anyways, getting back to the problem of spaces in parameters, I don't think URL encoding parameters would work. A better solution (IMO) would be to add two new magic words:
{{urlencode:<string>}} {{urldecode:<string>}}
Which would allow us to encode/decode URL parameters as necessary. Now if a dev could be convinced this is wise, we'd be set. =)
But urlencode and urldecode (and rawurlencode and rawurldecode) are PHP functions. They don't work the way we'd like, they encode spaces as '+' "for historical reasons" (that is, M$ visual basic), while we need '_'.
You can use then str_replace(urlencode(<whatever>), "+", "_"); If there were plus signs into whatever they would've been %aged so you're using a urlencode-like function which replaces spaces into underscores.
What does MS VB have to do into it? The + sign is defined as a valid space encoding at RFCs.
AFAIK, at the beginning, a way to encode a space was needed in order to avoid it mistanding with the separator for the HTTP version field on the request. Then more symbols needed escaping, thus developing the more advanced %hex way, having the + form a %20 synonim.
On 26/04/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match the latest parser syntax?
Because the "latest" syntax comes from an extension written a long time after the first magic words were.
Rob Church
Rob Church wrote:
On 26/04/06, William Allen Simpson william.allen.simpson@gmail.com wrote:
And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match the latest parser syntax?
Because the "latest" syntax comes from an extension written a long time after the first magic words were.
Sorry, my query wasn't sufficiently explicit.
What are the technical reasons for the syntax "{{fullurl:"?
What are the technical reasons for the syntax "{{#if:"?
My underlying question: are these planned differences or arbitrary?
And this may be related to my lack of understanding of the difference between "magic words" and "parser extensions"....
Could somebody please explain?
William Allen Simpson asked:
Sorry, my query wasn't sufficiently explicit.
What are the technical reasons for the syntax "{{fullurl:"?
What are the technical reasons for the syntax "{{#if:"?
There are no technical but historical reasons.
My underlying question: are these planned differences or arbitrary?
Wikisyntax is not planned. It evolves and mutates. Some people say that there is a cabala to make the languages consist of brackets and pipes only in the end. I don't think so because I don't think that there will be an end (maybe praying to RFC, W3C, ISO or the God of Wiki helps?).
And this may be related to my lack of understanding of the difference between "magic words" and "parser extensions"....
Could somebody please explain?
In a perfect world you first design a language, test it and specify it so you can create a parser and applications that understand the language. We don't live in this world.
Greetings, Jakob
P.S: How about an obscure Wikisyntax writing contest at Wikimania?
P.P.S: If you interested in a wiki markup standard then you should join this list: http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards
On Tue, 25 Apr 2006 19:38:55 -0400 William Allen Simpson william.allen.simpson@gmail.com wrote:
A couple of us were trying to figure out the syntax to add a working link to Special:Log in a template.
[{{fullurl:Special:Log|page={{{1}}}{{{2}}}}} log]
Works fine as long as parameter 2 is only one word. With a space in 2, only the first word shows up in the URL.
Tried wrapping {{fullurl:{{{1}}}{{{2}}}}}, but page= won't take a full page name.
[{{fullurl:Special:Whatlinkshere/{{{1}}}{{{2}}}|limit=999}} links]
Always works.
As far as I know this will fail if Special:Whatlinkshere/{{{1}}}{{{2}}} is longer then 255 characters. In such case one should / might use "&target=".
Is there some reason that fullurl stops encoding spaces to underscores when it runs into a pipe?
And speaking of syntax, why {{fullurl: instead of {{#fullurl: to match the latest parser syntax?
regards reinhardt [[user:gangleri]]
wikitech-l@lists.wikimedia.org