Feb 29 2020
Feb 25 2020
Feb 22 2020
Feb 5 2020
Feb 3 2020
Jan 11 2020
Apparently, the doubly urlencoded addresses are now processed correctly again.
Many thanks to all who have worked on this!
Jan 10 2020
Jan 9 2020
Again more than a month has passed without any noticeable progress in the matter.
What is the intention of WMUK?
What are the abilities of WMUK?
Is QRpedia going to be fixed in the near future?
Nov 28 2019
It's always the same thing with all characters. Therefore you should not look for a separate solution for every single letter.
The string was urlencoded:
Bremer_Baumwollbörse -> Bremer_Baumwollb%C3%B6rse
ok, but then urlencoded again
The % became %25. The address stored in the QR code is
and results in an error message: Der angeforderte Seitentitel enthält ungültige Zeichen: „%C3“.
More broken URLs generated by qrpedia.org:
Nov 11 2019
A patch was uploaded three months ago. I'm curious how it will go on. Is it accepted that many QRpedia codes worldwide have no function - so they are garbage? Or does WMUK still want to repair the software - when?
We just have the situation in Bremen that 70 codes on public information boards are affected by the bug. Due to a faulty QRpedia generator, do we now have to look for a sponsor for the renewal of the codes?
Jul 18 2019
The problem with the double slashes is fixed, very good! Now many QRpedia codes work stable again. But unfortunately the issue with the double urlencoded addresses persists, although the solution is not difficult at all.
Above it was pointed out that the code is on rGQRP. Apparently index.php is the important file here.
In line 47 the page title is loaded:
Jul 9 2019
Jun 7 2019
Because I am told that I wrote at a wrong place, I try once more and paste it here:
Jun 5 2019
The issues still persist:
a) Double slashes in de.Wikipedia: https://de.qrwp.org/Berlin
The solution should be known at WMUK, because the bug has been fixed for other language versions.
Sep 23 2015
Please don't change any bit at this lists before getting contact at Wikipedia Diskussion:WikiProjekt Bremen (lang. de prefered). We don't want to lose any functionality and usability.