Last modified: 2011-08-24 17:23:45 UTC
The namespaces used with the Proofread Page extension aren't defined by canonical name or ID. This means that the names and IDs for the "Index" and "Page" namespaces are different for each wiki, making it nearly impossible to write tools for different Wikisources. From <http://en.wikisource.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces|namespacealiases>: <ns id="104" case="first-letter" canonical="Page" xml:space="preserve">Page</ns> <ns id="105" case="first-letter" canonical="Page talk" xml:space="preserve">Page talk</ns> <ns id="106" case="first-letter" canonical="Index" xml:space="preserve">Index</ns> <ns id="107" case="first-letter" canonical="Index talk" xml:space="preserve">Index talk</ns> From <http://pt.wikisource.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces|namespacealiases>: <ns id="104" case="first-letter" subpages="" canonical="Galeria" xml:space="preserve">Galeria</ns> <ns id="105" case="first-letter" subpages="" canonical="Galeria Discussão" xml:space="preserve">Galeria Discussão</ns> <ns id="106" case="first-letter" subpages="" canonical="Página" xml:space="preserve">Página</ns> <ns id="107" case="first-letter" subpages="" canonical="Página Discussão" xml:space="preserve">Página Discussão</ns> From <http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ProofreadPage/ProofreadPage_body.php?revision=87777&view=markup>: /* Namespaces */ $this->page_namespace = preg_quote( wfMsgForContent( 'proofreadpage_namespace' ), '/' ); $this->index_namespace = preg_quote( wfMsgForContent( 'proofreadpage_index_namespace' ), '/' ); This is... bad. This bug is not about fixing the Proofread Page logic, though. This bug is about providing an interface to select the appropriate Proofread Page-related namespaces without having to use the "allmessages" API module (<http://pt.wikisource.org/w/api.php?action=query&meta=allmessages&ammessages=proofreadpage_namespace|proofreadpage_index_namespace>), which is an awful, awful hack. Related bugs: bug 28893 and bug 28894
Created attachment 8952 [details] Patch to add meta=proofreadinfo Sample output: <?xml version="1.0"?> <api xmlns="http://www.mediawiki.org/xml/api/"> <query> <proofreadnamespaces> <index id="102" /> <page id="100" /> </proofreadnamespaces> <proofreadqualitylevels> <level id="0" category="Bez treści" /> <level id="1" category="Nieskorygowana" /> <level id="2" category="Problemy" /> <level id="3" category="Skorygowana" /> <level id="4" category="Uwierzytelniona" /> </proofreadqualitylevels> </query> </api>
Really proofread page should do namespaces itself in the same way that liquidThreads makes its own thread namespace (imho)... Also, having namespace configuration inside the mediawiki namespace is really icky, it should be a $wgGlobalVariable (That has nothing to do with your patch, I'm just saying...)
Patch applied in r95351. A few notes though > + if ($namespace != null) { Our coding conventions prefer spaces (http://www.mediawiki.org/wiki/Coding_convention#Spaces) inside of parentheses. Also, when checking if a value is null you should use an identical comparison operator, just to be safe (http://www.mediawiki.org/wiki/Coding_convention#PHP_pitfalls) I also swapped out the foreach+switch statement in the api module for a simpler if statement. > + ApiBase::dieDebug( __METHOD__, "Unknown prop=$p" ); You don't have to worry about these things, the API will throw a warning about it and remove it from the array :) Also in the append functions I removed the $property argument, because it was unused. Very good patch though Beau, thank you for taking the time to do this. :)
(In reply to comment #2) > Really proofread page should do namespaces itself in the same way that > liquidThreads makes its own thread namespace (imho)... > > Also, having namespace configuration inside the mediawiki namespace is really > icky, it should be a $wgGlobalVariable (That has nothing to do with your patch, > I'm just saying...) It makes writing bots/scripts which would work on more than one project a pain. I have already thought about fixing that using LiquidThreads approach at some point, however I prefer to solve all trivial bugs first ;-).
