Talk:Inworld Locations for Volunteers

Note: Some SLurls not working

SLURLS not working on two name sims? Some of these links work when using the templates, others do not. The only pattern I can see is that the two name Sims seem to break. The space is parsed as a "+". Is this correct?
01:16, 9 February 2007 Blueman Steele

The root template for the SLurl templates uses MediaWiki's urlencode function.

This may sound odd, but it's SLurl.com that's broken, not the Wiki- SLurl.com isn't decoding the URL correctly.

SignpostMarv Martin 04:49, 9 February 2007 (PST)

A bug has been filed in JIRA for this issue to be fixed. [1]

SignpostMarv Martin 04:59, 9 February 2007 (PST)

It's a bug that can be fixed in the SLURL Template, and as soon as LL fixes the wiki's schizophrenic versioning I'll deploy it. The issue as Blueman noted the PHP urlencode function replaces spaces with '+' instead of '%20'. With the new update we have #replace, which i'll use to replace the '+' with '%20'. Strife Onizuka 09:30, 9 February 2007 (PST)

The bug is with SLurl.com, altering the SLurl template would only be a workaround. It would be better if SLurl.com was fixed instead of altering Template:SLurl.

SignpostMarv Martin 09:35, 9 February 2007 (PST)

And what about sims with '+' in their names? It's an easily avoidable ambiguity. On a side note MediaWiki does not supports using '+' instead of spaces in page names. I see it as a bug in the template and not the other way around. Strife Onizuka 10:51, 9 February 2007 (PST)

Simple: %2B {{urlencode:+}}

Further example, lets say the open-source text editor Notepad++ Gets an island in Second Life, you'd end up with Notepad++ Island^🖈 {{SLurl/simple|Notepad++|128|128|0}} generating http://slurl.com/secondlife/Notepad%2B%2B/128/128/0/?&title=Notepad%2B%2B+Island

I repeat; If a problem exists with a remote service that is used by many many clients, the behaviour of the remote service should be fixed, rather than changing the behaviour of the many many clients.

Basically, SLurl.com needs to be interpreting "+" as " " and "%2B" as "+"

SignpostMarv Martin 15:08, 9 February 2007 (PST)

RFC 1738 states Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL.

The current configuration of SLurl.com is not interpreting "+" for it's reserved purpose, it is instead either interpreting it as "%2B", or just plain sneezing.

SignpostMarv Martin 15:19, 9 February 2007 (PST)