@Ladsgroup Thank you! I've made a change that should fix this problem. https://gerrit.wikimedia.org/r/371649

@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.

@Florian Sadly I don't seem to be able to do that (the add button is disabled).

I support this request. I am not maintaining this extension anymore.

Should be done. I am not able to make sure it's actually live.

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)

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

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.

Done

It should work now (you should maybe purge pages to see the navigation bar be rendered again).

@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.

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

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.

@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.

A fix for this issue have just been done and merged: https://gerrit.wikimedia.org/r/#/c/357423/

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:

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.

@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?

The script fixed by Chad have been pushed on production and run on all wikis.

possible to advertise and publish the determined namespace allocations ahead of time?

Should probably be implemented using OO.ui.RadioInputWidget

Seems to require an hook in the API action implementation in MediaWiki core

Some issue again:

Thank you for the report. I subscribes Sam Wilson who has worked on this part of the tool.

I'm not sure what you mean by the CE being cluttered?

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?

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).

Ok, thank you!

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.

Can you provide more context of what it is missing

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?

3.0.0 will then include oauth support. Probably going down the route of some sort of Authentication object.

In T155682#2952041, @Legoktm wrote:

In T155682#2951903, @Billinghurst wrote:

Question. Is there a test in the system to create an index page as part of the testing of a mediawiki release? It would be useful, and to have that within the system if it doesn't exist.

No, that's something the ProofreadPage maintainers would need to add tests for it.

Should this be backported and deployed today? We missed the wmf.8 branch cut, but I could schedule it for a SWAT deployment later today.

It seems that it's broken since September and the issue has been reported 3 month later. So, I believe the correcting change could wait a few days.

EditFilterMergedContent hook is now fired by Special:ChangeContentModel (see task T145489). And the implementation of this hook in ProofreadPage does not handle well content conversion. I'm working on that.

I have created a narrower task about loading getter thumbnail while zooming in the scan image: T153124