Spaces can also cause problems: Obviously a space " " gets encoded as a plus "+". This breaks the links generated for Iconclass notation (P1256). For example http://iconclass.org/11H(COSMAS+&+DAMIAN) generated from "11H(COSMAS & DAMIAN)" instead of http://iconclass.org/rkd/11H(COSMAS%20&%20DAMIAN)/ (from this item).

@Marsupium Have you tried using the wmflabs tool wikidata-externalid-url? I used it for the formatter URL for Twitch game ID (P4467) in September because of the space issue, and it worked without any changes to the actual Toolforge code.

In T160281#5127418, @Jc86035 wrote:

@Marsupium Have you tried using the wmflabs tool wikidata-externalid-url? I used it for the formatter URL for Twitch game ID (P4467) in September because of the space issue, and it worked without any changes to the actual Toolforge code.

Yes, I found that workaround in the end and then forgot to report here. Thanks for mentioning it!

Does the frontend need to URL encode external IDs? If they are meant to be resolvable there should be no need to do so in the first place right?

Turns out this is also a problem within WDQS. When it comes to IDs and URIs is there a reason for encoding this type of information in the first place instead of leaving that to applications?

https://www.wikidata.org/wiki/Property:P2000 is another one that's affected by the incorrect encoding of spaces to '+'. Given that these values are strings like "Cantigas de Santa Maria", which generates a failing link of http://www1.cpdl.org/wiki/index.php/Cantigas+de+Santa+Maria, it probably fails more often that it works. It should be encoded as %20, which would work everywhere.

I report here my issue: "As reported in https://www.wikidata.org/wiki/Property_talk:P9112#ID_IFLA_link_to_an_error_page, the link generated by https://www.wikidata.org/wiki/Property:P9112 always encodes # as %23 ( e.g. in https://www.wikidata.org/wiki/Q719309#P9112 links to https://www.iflastandards.info/unimarc/terms/key%23ab ), causing in fact a wrong link." Are we sure this is "low" priority? Thanks in advance!

I wonder if the work in T271126 will fix this.

I report also https://www.wikidata.org/wiki/Property_talk:P9070#Backslash_decoding_problem, maybe it can be useful

Another problem of encoding: https://www.wikidata.org/wiki/Property:P2549 contains "&" in its IDs and due to encoding of "&" all the links are broken.

Example:

• https://www.wikidata.org/wiki/Q3757035#P2549 (link not working on Wikidata)
• https://it.wikipedia.org/wiki/Gaetano_Mancini#Collegamenti_esterni (same link working on Italian Wikipedia)

Could this be solved? Thanks!

For what it's worth, https://www.wikidata.org/wiki/Property:P4035 is also broken, and I'm told the reason is this ticket.

New property https://www.wikidata.org/wiki/Property:P10609 is also broken. The formatter URL is https://bioportal.bioontology.org/ontologies/PLOSTHES/?p=classes&conceptid=http%253A%252F%252Flocalhost%252Fplosthes.$1 and the values of $1 include a # symbol, e.g. 2017-1#9401. The link doesn't work. This direct link does work: https://bioportal.bioontology.org/ontologies/PLOSTHES?p=classes&conceptid=https%3A%2F%2Flinproxy.fan.workers.dev%3A443%2Fhttp%2Flocalhost%2Fplosthes.2017-1%239401

The fundamental problem here is that encoding of the parameter is specific to which part of the url you are inserting it into .This is why we have so many functions to handle encoding in wiki pages: https://www.mediawiki.org/wiki/Help:Magic_words#URL_data

Considering that this is not specified per formatter right now what type of encoding to apply to escape the values, it is currently not possible to do this without mistakes. A solution could be to add a property to the url formatter which specifies what part of the url the value will be substituted into, and use that to determine the correct encoding when escaping the values for the url formatter.

I have the same issue with https://www.wikidata.org/wiki/Property:P11118. The hash-mark separator in the URL should not be encoded as %23 but as #.

For reference, https://www.wikidata.org/wiki/Template:Property_documentation seems to generate the URL correctly (see section "examples" in https://www.wikidata.org/wiki/Property_talk:P11118).

https://www.wikidata.org/wiki/Property:P12409 is affected as well. : is encoded as %3A.

@TheDJ sums up the situation well. Changing the way the encoding works at the moment would probably break more than it fixes.