Last modified: 2011-02-19 20:19:16 UTC
tags <pagelist > accepted parameters of the form 1to10=roman to specify attribute value applying to a range of page, some change in attribute name sanitizing break this feature, see #17031. While 17031 state it increase the possible attribute names, it also decrease them in some case. As extension tag are not valid xml anyway, I don't see why we would apply such restriction to extension attribute name.
the problem seems to come from here: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/70849
So it seems. <pagelist > tag is provided by ProofreadPage extension. The attributes passed to tags are obtanied with Sanitizer::decodeTagAttributes() which in turn uses the regex modified by r70849. I think we can modify the regex to also accept attributes beginning with digits. It seems used just for wiktiext processing, so we can be more liberal than HTML.
Would be a simple fix.. just add "0-9" inside the brackets in the $attribFirst variable if we want to allow that. Alternatively, we could just set $attribFirst = $attrib for now and let anarchy reign ;) It's nice right now to have a spec that the rules conform to, but Platonides makes an interesting point that this is wikitext, not HTML. Alternatively, I could see the argument that since we basically took the syntax for parser-tags from XHTML syntax, that we should just use that standard as much as possible. I'm not sure which is best. If we want to leave it xml compliant, it shouldn't be hard to rename that parameter in <pagelist> and have a bot replace all instances of the old param with a new, valid name. Both fixes are pretty easy. Anyone else have opinions?
XML compliance is a great idea, but it should have been decided right from the beginning. Here we have a major regression that affects thousands of pages, I think it should be fixed asap; we do not have time to organize a debate on XML compliance. I suggest that for now, we go for your first suggestion (add "0-9"). If it later turns out that we need to comply with XML syntax, we will have to fix the wikitext of thousands of pages simultaneously, and educate users about the new syntax; a pretty heavy process, since Wikisource users have been using this syntax for years.
I'm convinced. Committed r82475 to phase3. Will that get released to production automatically or is there a branch I should merge this to?
It needs to be tagged as 1.17wmf1 (and probably 1.17 too). But I wouldn't have added . and - to begin an attribute. I will remove them if you don't mind.
Done in r82480
