In T305314#11015939, @Samwilson wrote:

The latest comment on T244135: Publish current version of QRpedia code in a public code repository suggests that the source code in Gerrit is still not actually being used for the qrpedia.org service, and without knowing a) what source code repository to work on and b) how to get changes deployed, I'm not sure there's much that can be done. :-(

This is fact. Without knowledge of the current code and how to edit and implement it, there will be no improvement. Then QRpedia is dead!

It looks like this is a case of [T405897].
Reason: The source code from qrwp.org shown in the description proves that the Polish article was recognised. An (encoding) error in the URL would have prevented this.

The last code in Gerrit was ten years ago

This means that Gerrit does NOT contain the currently running code.
The question remains: Where is the current code?

Yes, this task can be closed.
But it would be better if QRpedia would be resistant to such problems caused by non-ANSI URL characters in the future. It would also be better if QRpedia codes permanently point to their article. I made a suggestion for this in February and offered the appropriate code adaptations, but they are based on the outdated rGQRP. I would also adapt the current code if I get read access.
Please have a look at T245907.

Maybe I should ping a few people who are part of the WMUK staff (or contractors)? They could certainly point out this proposal at WMUK.
@Kelson, @ErrantX please take a look at this.

In T245907#5914527, @Samwilson wrote:

How would this work for resolving to different languages? At the moment, a QRpedia code for e.g. enwiki:Apple will go to frwiki:Pomme if a user's device is set to French. For linking to a specific page ID, it sounds like it might be better to just create a QR code for the URL itself (or, rather, the UrlShortener version of it, to keep the QR code size smaller). Personally, I think basing QRpedia on Wikidata IDs is much more useful.

Apparently, the doubly urlencoded addresses are now processed correctly again.
Many thanks to all who have worked on this!

In T210050#5793272, @Pigsonthewing wrote:

Thank you. I haven't forgotten that; indeed, I've been lobbying to get this resolved. Have you perhaps mistaken me for someone else?

In T210050#5792831, @Pigsonthewing wrote:

Yes; en.Wikipedia has:

• [[50% & 50%]] : https://en.wikipedia.org/wiki/50%25_%26_50%25
• [[The 50% Rule]] : https://en.wikipedia.org/wiki/The_50%25_Rule
• [[10%: What Makes a Hero?]] : https://en.wikipedia.org/wiki/10%25:_What_Makes_a_Hero%3F

and others. The first of those is also in hu. and ja. Wikipedias.

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?

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
-> Bremer_Cottonb%25C3%25B6rse
The % became %25. The address stored in the QR code is
http://de.qrwp.org/Bremer_Baumwollb%25C3%25B6rse
and results in an error message: Der angeforderte Seitentitel enthält ungültige Zeichen: „%C3“.
More broken URLs generated by qrpedia.org:
http://de.qrwp.org/Sch%25C3%25BCtting_%2528Bremen%2529
http://de.qrwp.org/Ratscaf%25C3%A9e/Deutsches_Haus
http://fr.qrwp.org/H%25C3%25B4tel_de_ville_de_Br%25C3%25AAme

In T210050#5699460, @Jkbr wrote:

The patch failed some of our manual tests on the punctuation-encoding edge cases. To go forward we are developing a test suite and adding some basic READMEs etc. so functionality can be agreed and fixes tested.

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?

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:

In T210050#5315880, @Samwilson wrote:

Firstly, I've made changes on our server so that URLs with wrongly encoded apostrophes and parentheses as in the 37 Toodyay URLs are now handled and redirected.

Because I am told that I wrote at a wrong place, I try once more and paste it here:

In T209019#5235945, @Quarz wrote:

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.

b) Incorrect URL resolution for articles with non-letter character:
The issue already existed once in 2014, but was quickly fixed by a simple method at qrwp.org: With the incoming URL, do a regex_replace or string_replace, find '%25' replace with '%'.
https://en.wikipedia.org/w/index.php?title=User_talk:Victuallers&oldid=592634542#QRpedia_bug_-_Apostrophes._HELP!
I would like to know why the fix was undone.

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.

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.