May 17 2019
May 3 2019
I guess you fixed only this example? I can perhaps produce more. I have a list of suspect items, though I don't know how to formulate a query to check all labels of one or more items. And then there are probably other bad labels sourced from other wikis and other problematic characters like the zero-width space...
Why not use 320px for thumb sizes ≤320px and let the browser do the scaling? I normally work at a browser zoom level of 110% or 125% depending on location.
Indeed! Could you provide a link to the change(s)?
Apr 26 2019
Apr 18 2019
Since collation is non-identical, I would have expected some kind of stringprep-like transformation to prevent these kinds of problems, with the added benefit of cleaner input.
Apr 16 2019
Feb 15 2019
Another false positive:
Dec 16 2018
Jul 24 2018
Jul 23 2018
May 2 2018
Mar 5 2018
A week ago I suggested for nlwiki to move to Remex. No objections so far, so please go ahead!
Nov 14 2017
Found some more nested tables on other wikis, this one didn't disappear after a purge:
Nov 12 2017
Nov 10 2017
Nov 4 2017
Nov 2 2017
Oct 15 2017
I thought this was not a parser issue as I saw no differences in the parsermigration tool. Could someone please explain this for my understanding?
Aug 8 2017
Sure it's badly configured. Writing software would be so much easier if everybody would just adhere to the standards. ;)
There's no need to "sanitize" the plus signs, they are valid. The only requirement from the Wikipedia side of things is that the server accepts the URL verbatim, which it does. When I enter the URL in archive.org, it gets turned into http://web.archive.org/web/*/www.musicvf.com/Buck+Owens+%252526+Ringo+Starr.art.
Aug 7 2017
As I stated here (in Dutch) I already reported it. What made you think that it wasn't reported yet?
Aug 5 2017
Not dead on my side and still not in DB! We're talking about the same URL, I hope? http://www.musicvf.com/Buck+Owens+%2526+Ringo+Starr.art