Page MenuHomePhabricator

Proofread Page extension needs an API module to set or change page status
Open, MediumPublicFeature

Description

The Proofread Page extension (http://www.mediawiki.org/wiki/Extension:Proofread_Page) needs an API module to allow users to set or change page status (without text, problematic, etc.).

This is related to bug 28893.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=41369

Details

Reference
bz28894

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:25 PM
bzimport added a project: ProofreadPage.
bzimport set Reference to bz28894.
bzimport added a subscriber: Unknown Object (MLST).

beau wrote:

I wonder if it is really needed. You can always change page status using action=edit. Proofreading does not only involve changing status, but also correcting mistakes. In such cases you will have to edit page anyway.

The only pitfall here is that earlier versions of the extension used PageQuality template. You can replace them by extension tag just by nullediting all pages.

With the addition of the API, it means we can more easily process files based on API data rather than having to do extra processing on the actual of the file. With regard to the tag vs the template is a typical example of why, with the API, we can quickly get files of a certain time/period/whatever and process them using a bot rather than having to jump on every file to check its needs.

beau wrote:

Andrew, I don't how your comment is related to this feature request. You can obtain the proofread status of a page via api.

I would like the proofread status of a page to be a Flagged Rev Tag.
https://www.mediawiki.org/wiki/Help:FlaggedRevs

This allows the existing API to be used
https://www.mediawiki.org/wiki/Flagged_Revisions#API

It also provides some other benefits

  • separation of the proofreading UI (textbox + image side by side) from the proofreading quality system.
  • multiple quality indicators (often the text is perfect but the style is poor quality)
  • customisation of the quality workflows, including customisation of access control to the quality levels (some projects may want three phase verification, one project demanded that anons be allowed to change quality levels - see bug 20812 comment 28)

"I would like the proofread status of a page to be a Flagged Rev Tag": a lot of wikis doesn't use (and doesn't want to use) FlaggedRevs. So we can't make ProofreadPage dependant of FlaggedRevs.

Add: its need to fix another option of API to Action=edit, Header Footer, Page body separately to resolved our one issue of Google OCR Script.

For that you could use something like https://en.wikisource.org/wiki/Special:ApiSandbox#action=query&format=json&prop=info&list=&titles=Page%3ATricotrin%2C+by+'Ouida'.djvu%2F323&inprop=preload that returns the preloaded Wikitext of the Page: page.

Here, it's the Wikitext serialization that current follows the pattern (warning: it may change in the future!):

"<noinclude><pagequality level="PROOFREADING_LEVEL" user="PROOFREADING_USER" /><div class="pagetext">HEADER\n\n\n</noinclude>BODY<noinclude>FOOTER</div></noinclude>"

I made a script to easily change the status by manually editing the pagequality tag - see https://en.wikisource.org/wiki/User:DannyS712/Change_status.js
Would it make sense to create a new API that just provides a wrapper for the edit API? If so, I'll work on this

eprodromou subscribed.

We think this makes sense; we'll need to have code review before it merges but otherwise fine.

I made a script to easily change the status by manually editing the pagequality tag - see https://en.wikisource.org/wiki/User:DannyS712/Change_status.js
Would it make sense to create a new API that just provides a wrapper for the edit API? If so, I'll work on this

We think this makes sense; we'll need to have code review before it merges but otherwise fine.

I guess I should have clarified - my intention was to create a javascript wrapper for the Javascript interface by adding something similar to mw.Api.plugin.edit - would that be okay, or would it be preferable to create a full api module?

I made a script to easily change the status by manually editing the pagequality tag - see https://en.wikisource.org/wiki/User:DannyS712/Change_status.js
Would it make sense to create a new API that just provides a wrapper for the edit API? If so, I'll work on this

We think this makes sense; we'll need to have code review before it merges but otherwise fine.

I guess I should have clarified - my intention was to create a javascript wrapper for the Javascript interface by adding something similar to mw.Api.plugin.edit - would that be okay, or would it be preferable to create a full api module?

{{ping}} core platform team and @eprodromou - should this be a js wrapper or a full api module?

...
{{ping}} core platform team and @eprodromou - should this be a js wrapper or a full api module?

{{ping}}

DannyS712 removed a project: User-DannyS712.

unlicking

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:24 PM