Mon, Dec 11
To summary, currently mw.wikibase.getEntityIdForTitle allows to retrieve the id of the item connected to a page of the current wiki from its title as a string.
Sat, Dec 9
I just did to Mediawiki:proofreadpage_index_template the change suggested by @Ankry and it seems to have fixed the problem: https://mr.wikisource.org/w/index.php?title=%E0%A4%AE%E0%A4%BF%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A5%80%3AProofreadpage_index_template&type=revision&diff=21431&oldid=627
Sun, Dec 3
Duplicate of T181944
Change merged! Thank you for the bug report and the fix.
Sat, Dec 2
It's rEPRP57e8b49becad27d3ce3eb3f994c131c206efd62c that merges duplicated code, removing the implementation with the bug fixed but keeping the one with the bug.
Wed, Nov 29
The configuration for Index: and Page: namespaces is not properly done on cywikisource. The change https://gerrit.wikimedia.org/r/394189 to the configuration should solve this problem.
The correction for this change is now deployed. It seems to work now.
Thu, Nov 23
Tue, Nov 21
@Bodhisattwa I just did a null edit on the index page and it fixed the error. The correction of this bug is sadly going to roll out not this week because of Thanksgiving in the US but the week after (i.e. November 28th).
Fri, Nov 17
A possible idea of root cause: the Index: page is maybe rendered at the same time as the category table from Page: pages (re)rendering. In this configuration the page status is maybe not available in the database.
Thu, Nov 16
Wed, Nov 15
It seems to me that is problem is now solved.
That's definitely a good idea! Let's add it to the TODO list.
Nov 14 2017
I'm fine with doing this and I believe it should be done in the same way as Commons so we have consistency.
Nov 12 2017
Nov 4 2017
Great! Let's close this task
Oct 30 2017
Oct 29 2017
A hacky way to do it is maybe to create fake "sites" per languages. We would for example have amiincubatorwiki would be a fake site that could be used for sitelink that have exactly the same configuration as the one of incubatorwiki
Oct 27 2017
Oct 26 2017
Oct 25 2017
I am not sure of what is the root cause of this error.
To help to investigate, which MediaWiki version are you using? Are you using the latest code of ProofreadPage?
Due to workload constraint (this extension is maintained only on volunteer time) we do not take careful care of compatibility with MediaWiki stable versions.
Oct 24 2017
It seems that the ProofreadPage extension is not properly loaded when you run scripts. Are you sure that the scripts or your maintainance directory are loading the right LocalSettings.php?
Oct 23 2017
Thank you for having a look at it. Sadly it is still not working.
What is throwing that error message: Jsub or xvfb-run?
Sep 21 2017
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?