Thu, Sep 21
User:einstein95 have found the root cause of this issue: it's because TwoColConflict and ProofreadPage does competitive overriding of EditPage. I have updated the task description accordingly.
I do not manage to reproduce this issue with the 1.30mwf19 version of MediaWiki core and ProofreadPage. The root cause is maybe an other extension that also overrides this action for all content models or something related to the WM environment (content model lookup?).
Sep 13 2017
Sep 11 2017
An other approach to avoid this problem is maybe to stop doing the ePub to PDF conversion using the grid engine and migrate to a single Kubernetes container doing both the conversion and the web frontend. It would also avoid the need of using the shared file system to move data between nodes. @bd808 do you think it is a good idea? Is it possible to setup a container with the calibre Debian package installed?
Sep 8 2017
I have merged the change into master and created a cherry-pick for a SWAT deployment: https://gerrit.wikimedia.org/r/#/c/376667/
Sep 2 2017
Yes, it seems resolved. The change that should fix this error have been merged and deployed.
Sep 1 2017
There is the same problem on French Wikisource with Safari 10:
Aug 24 2017
Aug 18 2017
@thcipriani do you have the full stack trace (I do not have access to the production logs)? It would hopefully make solving this problem easier.
Aug 14 2017
@Florian Sadly I don't seem to be able to do that (the add button is disabled).
Aug 13 2017
Aug 12 2017
I support this request. I am not maintaining this extension anymore.
Aug 10 2017
Aug 9 2017
Should be done. I am not able to make sure it's actually live.
Aug 4 2017
The next problem is how someone could change proofread page in a non-breaking way to support this in future. Hmmm...
And how would this allow the sort of query I had in mind in my use case?
Hmm so the /* Problematic */ etc auto summaries become proper revision tags?
It's the goal :-).
We could use the revision tag system and add a tag for each revision giving the status or a tag for each status change. See: https://www.mediawiki.org/wiki/Manual:Tags
I believe that storing which user changed the status in the database is not useful because it could be easily retrieved from the revision table (especially if we choose to have specific tags for each status change)
Aug 3 2017
The pageprop mechanism seems a good way to allow such things (and will remove the need for the extension to rely on categories): https://www.mediawiki.org/wiki/Manual:Page_props_table
Aug 2 2017
This is not impossible but will need further investigation, finding the IDs of the Index: namespace on all Wikisources, changing the database structure and repopulating it, before finally deploying Cognate.
Jul 27 2017
Jul 19 2017
Jun 29 2017
It should work now (you should maybe purge pages to see the navigation bar be rendered again).
Jun 15 2017
@debt Thank you! The fix for this bug is just changing some lines in the Kartographer extension. So, it would just require a +2 without any work for deployment
@Jdforrester-WMF Do you know who to reach to get a review for the change solving this issue? A lot of users are complaining on French Wikipedia.
Jun 14 2017
The scan size was set to 1px, leading to 1px scan images. See: https://en.wikisource.org/w/index.php?title=Index%3ALibrary_Construction%2C_Architecture%2C_Fittings%2C_and_Furniture.djvu&type=revision&diff=6864285&oldid=6862841
Jun 10 2017
I have setup a cron task running daily that executes the following bash script:
I have just merged a change that removes the new "pagequality-admin" rights from the sysop group because this change that I thought not problematic seems to be. It should be deployed next week on Wikisource.
Jun 9 2017
@Ankry workflow looks great even if it has the disadvantage to add an other user group. Thank you for the idea! We could definitely implement that on some/all Wikisource. I have just proposed a change that removes the right from the sysop (admin) group from the default configuration. It could be a good idea to move back to the previous state before having discussion on which process should be used.
@Hrishikes we have added a new user right called "pagequality-admin" that is, by default, enabled only to admins and allow them to tag as validated all pages. It is useful when you want to re-create already validated pages. See task T51482 . I'm going to send an email to the mailing list about that.
Jun 6 2017
A fix for this issue have just been done and merged: https://gerrit.wikimedia.org/r/#/c/357423/
Jun 5 2017
No the syntax should not be tied to "current wiki", as this makes it of little use for Commons, Wikisource, etc. There should be alternative syntax mw.wikibase.getEntityIdForTitle( pageTitle, globalSiteId ) -> string|null with globalSiteId the same as in mw.wikibase.entity:getSitelink function.
To summary the current state of the work on this task:
Jun 3 2017
A good implementation of this feature could be to create a new 'pagequality-admin' right that is by default only available to admins and allows to override the page quality indicator.
See https://www.mediawiki.org/wiki/Manual:User_rights for an introduction to user rights
Sorry, the IndexContent class introduced in https://gerrit.wikimedia.org/r/#/c/328543/ is not used everywhere yet. https://gerrit.wikimedia.org/r/#/c/355883/ (review welcome) is using it in ProofreadIndexPage and should fix this issue.
May 26 2017
@amritsreekumar It's maybe a task to add to your GSoC project as it's related to OOui and makes the Page: pages display UI looks quite bad.
I belive this issue is now solved (with a big of cache purge required probably). @Billinghurst could you confirm?
May 25 2017
May 24 2017
The script fixed by Chad have been pushed on production and run on all wikis.
May 21 2017
possible to advertise and publish the determined namespace allocations ahead of time?
May 20 2017
May 19 2017
Should probably be implemented using OO.ui.RadioInputWidget
Seems to require an hook in the API action implementation in MediaWiki core
Apr 24 2017
Some issue again:
Apr 11 2017
Apr 8 2017
Thank you for the report. I subscribes Sam Wilson who has worked on this part of the tool.
Apr 5 2017
Apr 1 2017
I'm not sure what you mean by the CE being cluttered?
Mar 31 2017
Mar 29 2017
I've just written a change that should fix the error.
Does that mean this is now Resolved as all the old pages have expired?
Mar 27 2017
Please allow me a few extra days to give a closer look at the query
Ok! Thank you!
Seems to be done.
I've done a very quick check on https://en.wikisource.beta.wmflabs.org . The UI seems ok (no big issue).
Resolved by Ed's change( thank you!).
The biggest Wikisources have less than 20,000 Index: pages each. So on all wikis combined it is something around ~100,000 rows.
@DBA Change https://gerrit.wikimedia.org/r/#/c/328543/ contains a maintenance script to migrate old Index: pages to the new content model. Is it possible to get a code review for it? It will affect all wikis where ProofreadPage is deployed (i.e. all Wikisources).
Mar 26 2017
Ok, thank you!
Mar 22 2017
That is very unlikely to happen. K8s don't know grid and grid doesn't know k8s. If you must submit jobs you can either make the webservice run on grid, or submit the job to k8s.
Mar 3 2017
Can you provide more context of what it is missing
Feb 27 2017
Yes, I have added these transclusions in early January to resolve task T114318. Using template dependencies is imho the right way to go because as the Index pages displays the proofreading quality of each page it transcludes some data from it. The other way to go would be to implement an other dependency tracking system and I am not sure that it's something we want to do (see how much time it took to have arbitrary Wikidata entity access with much more human power and a much more important need).
This should work fine now. Could someone confirm?
Jan 31 2017
3.0.0 will then include oauth support. Probably going down the route of some sort of Authentication object.