mediawiki.bugzilla wrote:

(Sorry for the multiple-mail noise)

Link to the thread on smw-devel where I brought this up: http://sourceforge.net/mailarchive/forum.php?thread_name=alpine.DEB.2.00.0810240859330.23744%40alchemy.localdomain&forum_name=semediawiki-devel

I fear that the current processing is not "mis-decoding" but was a deliberate change in the way parameters are processed, with the goal of allowing SMW to create internal links with arbitrary parameter values from wiki pages (this was not possible before, creating all kinds of problems with special symbols).

The current encoding works as follows: first encode special symbols (including "%", "/", and "-") URL-style (using %), and then replace all "%" with "-". Multiple parameters are separated with /. One reason for the replacement of "%" is that we use the same encoding method everywhere, including in our XML-based export: In XML tags, % is not allowed as a symbol.

The replacement of " " by "_" is something that happens for all links in a wiki. I assume that we cannot avoid this at all. In the above encoding, one would write "-20" for spaces. This is another reason why we cannot use % encoding: "%20" could be used to encode " ", but then the URL does again contain "_" in this place.

I am rather sure that the new encoding is much more reliable than the old method. We can now encode essentially all parameter values in a way that allows us to make an internal wiki link and an XML entity. I also understand your request but I do not see a significantly better solution that is still able to encode all possible symbols reliably -- and changing the encoding would also change many existing URLs that might be used in other places.

I could offer to support a syntax like [[Special:SearchByProperty/Your-Mom::Wears Polyester]]. This syntax would then have no way to encode " " at all (the example would again mean "[[Special:SearchByProperty/Your-Mom::Wears_Polyester]]"), but - would work as expected.

mediawiki.bugzilla wrote:

Howdy Markus,

Sorry about the delay. I would appreciate that syntax, since it would be able to encode everything but " " (and it seems to me that using ugly URLs one should be able to encode " " anyway).

In light of recent changes in SMW 1.8 and in respect of [1], does the described behaviour still prevail?

[1] https://gerrit.wikimedia.org/r/#/c/32023/

I think all parameters are still using the same escaping strategy as before. We should change this at some point. The special escaping was needed for RDF/XML export but there does not seem to be a reason why we should use a uniform escape strategy for all cases (so we can have special escaping for RDF and standard escaping for other functions).

Well in this case I put this one on the 1.9 tracking ticket (bug 41842) so we don't have to break a leg or two here.

Removing as blocker for 1.9

Setting to new as no one is working on this

Solved by [0, 1].

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/537
[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/tests/phpunit/includes/MediaWiki/Specials/SearchByProperty/PageRequestOptionsTest.php