rowan.collins wrote:

Um... I'm not entirely sure I understand all the layers of templates you seem
intent upon creating, or quite how the end result is expected to function, and
where the actual content resides. But, looking at [[en:User:Gangleri/tests/breed
discussion g]], I think I can solve most (but not all) of your problems. As
explained at [[Help:Variable]], you can build extra bits of URL (such as
"&action=history") into the {{localurl}} variable [e.g.
{{SERVER}}{{localurl:Foo|action=history}}]. And there is an even easier way to
pass pagenames to things like Special:Whatlinkshere - you do an internal link as
though the target was a subpage, so [[Special:Whatlinkshere/Foo]] gives you the
backlinks for [[Foo]].

Armed with this knowledge, I have created a page
[[en:User:IMSoP/Gangleri/maintenance links]] which creates the links you seem to
have been hoping for. To demonstrate, [[en:User:IMSoP/Gangleri/dog list]] is a
copy of [[en:User:Gangleri/tests/list (maintenance g)]] using this new template.

You will notice that the Google links are still broken (and that I've removed
the use you made of the Google: interwiki prefix). The problem is that the
parser sees the first space inside the [] as being the end of the URL and
beginning of the label; but replacing spaces by underscores wouldn't be right
either, since Google doesn't treat those as spaces at all; instead, we'd need to
do generic URL-escaping, where space becomes %20. Perhaps this is what you meant
with your {{FORMATURL:foo}}? I couldn't work out what you meant by that one, but
certainly a {{generically_url_escape_this_text:}} key-word would provide one
solution. (I've made this the summary of this bug, since it seems to be the
main/only real request)

The [[Google:foo]] interwiki prefix has even worse problems: because it *does*
escape its argument, but in a MediaWiki way, not a generic way, so spaces become
underscores, and certain characters kill the link completely. This behaviour,
and possible ways round it, is discussed at bug 707.

• Bug 1192 has been marked as a duplicate of this bug. ***

• Bug 1461 has been marked as a duplicate of this bug. ***

halftime wrote:

I would like to add a few comments for this feature request. I would like very
much to be able to create a template that displays and address and links to
Google Maps. A way to escape a URI would make this possible.

As stated above, search criteria, especially addresses contain spaces, which do
no play well with the way external links are created. If I have a template that
looks like this:
<nowiki>
{{{1}}}} [http://maps.google.com/maps?q={{{1}}}} Google Map]
</nowiki>

My query string will only contain the address up to the first space. So usually
just the number portion.

If I could URI escape the second string, this would be a non-issue. Example:
<nowiki>
{{{1}}}} [http://maps.google.com/maps?q={{{escape_uri:1}}}} Google Map]
</nowiki>

If the second instance of the variable is escaped before it is sent to the link
parser, this would solve the problem.

I can see this being very useful for creating standard and consistent ways of
linking to things, such as Google, Amazon, IMDB, etc, etc. This also allows the
flexibility to update links globally in case an external site changes or creates
a better method for linking to their pages.

gangleri wrote:

changed title: variable -> method ; method might be *escape_uri:* somthing like
*subst* OR an extension if
bug 2681: Can't include an extension inside a link
is fixed

• Bug 5012 has been marked as a duplicate of this bug. ***

This is a simple implementation, simlar to implement lc and uc.

gangleri wrote:

Do we need three different functions?
a) for foo in http://example.com/foo
b) for bar in http://example.com/foo?param=bar
c) for foobar in http://example.com/foo?param=bar#foobar

a) is using %xx
b) ?
c) is using a different escaping technique as a) and b) .xx

The escaped character sets differ.

halftime wrote:

I think using the php "urlencode" function would be more than sufficient. In
the example above, there is nothing fancy being done to the URL as a whole, just
a specific part that needs to be escaped.

robchur wrote:

We could just install the urlencode extension knocking about somewhere.

halftime wrote:

There is an order of operations issue. The extension is found at:
http://meta.wikimedia.org/wiki/Urlencode

However, when passed a variable, the variable name is not expanded out before it
is encoded, so this results in a literal {{{foo}}} being translated and passed
through the URL.

Maybe the extension can be fixed to replace variables with their values before
they are esacped?

david.alex.lamb wrote:

I have a [[Wikipedia:Template:bibleref]] template where the argument ought to be
URL encoded to eliminate spaces. Should I deduce from
[http://bugzilla.wikimedia.org/show_bug.cgi?id=839#c11] that this won't
work(yet)? Also, who would place the urlify.php somewhere? Someone at Wikipedia?

gangleri wrote:

(In reply to comment #12)
a) You should *not* use spaces in [[template:Bibleref]] This breaks the links.
Tray "_", "%20", "+" etc.
b) Some UTF-8 characters will require %nn%nn%nn 'translation' also some special
characters from the 'Unicode Basic Latin Block' as in
http://www.google.de/search?num=100&as_q=%26uselang=de
http://www.google.de/search?num=100&as_q=foo%26bar
this is *not*
http://www.google.de/search?num=100&as_q=foo&bar

If you make a template which "cites" url's / if you do not use [link foo] syntay
but *link* some trailing characters from the 'Unicode Basic Latin Block' need to
be escaped as well: ".", ":" etc.

"We could just install the urlencode extension knocking about somewhere." Is
there something preventing this? If so, the suggested {{formate:}} function
would suffice. This would be very useful in templates like {{vandal}}, where
multi-word strings need to be put in query strings.

halftime wrote:

(In reply to comment #14)

"We could just install the urlencode extension knocking about somewhere." Is
there something preventing this?

See comment #11. The extension ends up encoded the literal variable value
instead of its value. So if it did get installed, it wouldn't work for what you
are trying to do.

beauxcphus wrote:

I propose that a new variable be made similar to {{PAGENAMEE}} - excep thtat it returns a url encoded version of the page name. you could make it {{PAGENAMEU}}. I am not certain
where this bit of code would go...

robchur wrote:

(In reply to comment #16)

I propose that a new variable be made similar to {{PAGENAMEE}} - excep thtat

it returns a url encoded version of the page name. you could make it
{{PAGENAMEU}}. I am not certain

Someone correct me if I'm having a bit of amnesia, but isn't that what PAGENAMEE
does?

wikt.3.connelm wrote:

(In reply to comment #17)

(In reply to comment #16)

I propose that a new variable be made similar to {{PAGENAMEE}} - excep thtat

it returns a url encoded version of the page name. you could make it
{{PAGENAMEU}}. I am not certain

Someone correct me if I'm having a bit of amnesia, but isn't that what PAGENAMEE
does?

No. One uses an underscore the other would use a plus sign.

gangleri wrote:

(In reply to comment #17)

Someone correct me if I'm having a bit of amnesia, but isn't that what PAGENAMEE
does?

{{PAGENAMEE}} does not accept 'user' parameters and is identical to the searched
{{searched_method:{{PAGENAME}}}.

{{searched_method:foo}} would return the same resuld regardless from what page /
from where you call it.

robchur wrote:

Right, the phrasing was ambiguous. I read it as a request for a URL-encoded page
title which is what PAGENAMEE does, we're still asking for a general URL encode
magic word. OK.

beauxcphus wrote:

it is my understanding that PAGENAMEE does not do a complete urlencode -
specifically spaces are returned as underscores - so if i want to build a link
to an external search engine using the {{PAGENAMEE}} variable - it does not
work correctly because most search engines use underscores to imply that the
words must always appear together:

• for example -

http://www.mysearch.com/search.php?query={{PAGENAMEE}}

becomes

http://www.mysearch.com/search.php?query=Page_name_here

which would return a very different result from the ideal which is:

http://www.mysearch.com/search.php?query=Page+name+here

or

http://www.mysearch.com/search.php?query=Page%20name%20here

i am not familiar with {{searched_method:{{PAGENAME}}} and could not find any
other reference to this tag.

beauxcphus wrote:

but i agree that a general urlencode tag that does not just
encode the variable name would be ideal and prefereable.

gangleri wrote:

(In reply to comment #21)

http://www.mysearch.com/search.php?query={{PAGENAMEE}}

i am not familiar with {{searched_method:{{PAGENAME}}} and could not find any
other reference to this tag.

*search_method* is the imagary magical name requested here. Devlopers will
finaly decide about the name.

Beside

http://www.mysearch.com/search.php?query=Page_name_here
http://www.mysearch.com/search.php?query=Page%20name%20here
http://www.mysearch.com/search.php?query=Page+name+here

There exists also:
http://www.google.com/search?num=100&q=%22Orson+Welles%22
http://www.google.com/search?num=100&q=Orson-Welles
both give the same result: 6,270,000 hits

The first is the syntax for search with *exact* match, the second might be a
google exploit.

BTW:
http://www.google.com/search?num=100&q=Orson+Welles
http://www.google.com/search?num=100&q=Orson%20Welles
gives 7,070,000 hits

http://www.google.com/search?num=100&q=Orson_Welles
10,500

These differences are all handeled at
Bug 707: Google search with [[Google:search term]]
Please follow the demo links there.

This request (bug 839) is about a method to URL escape constructs similar to
{{localurl:w:sv:Öland}}
http://sv.wikipedia.org/wiki/%C3%96land
This was the original requirement.

a better method *could* support also anchors
{{localurl:w:sv:Öland}}#Tätorter_på_Öland
today this is useless / invalid because the anchor is not ANCHOR escaped to
http://sv.wikipedia.org/wiki/%C3%96land#T.C3.A4torter_p.C3.A5_.C3.96land

a better method *could* support both parameters and anchors
{{localurl:w:sv:Öland|oldid=1803465}}#Tätorter_på_Öland
today this is useless / invalid because neither the anchor is ANCHOR escaped nor
the parameters are preserved (today) in interwiki links

The nice to have (now 1 1/2 year after opening this bug) would be:
http://sv.wikipedia.org/w/index.php?title=%C3%96land&oldid=1803465#T.C3.A4torter_p.C3.A5_.C3.96land

*note* development goes step by step. It would be better to provide the original
/ minimal requirement then nothing.

best regards reinhardt [[user:gangleri]]

robchur wrote:

{{urlencode}} magic word added in SVN trunk, r14273.