Page MenuHomePhabricator

Create OOUI widget for Index page pagelists
Closed, ResolvedPublic

Description

The ProofreadPage pagelist creation process is difficult for new users, and not particularly fast for experienced users. This task adds a new editing widget for it, so it can be more easily edited without resorting to external programmes etc.

Aspects of the required user interface (which will appear in the existing Index page editing form as the 'Pages' field):

  • The standard (non-editing view) pagelist view of an inline list of page numbers, colour-coded by proofreading status.
  • The default view is the same as the <pagelist /> tag with no parameters, i.e. 1-n pages with normal numbering.
  • On clicking a number, a thumbnail pops up.
  • Under the thumbnail there is a select list of common text labels and a text-input box for numbering.
  • The text labels are e.g. 'title', 'ToC', etc. as well as 'roman' for starting roman numbering (returning to Arabic with 'arabic'). Localization of this will need to be figured out.
  • The displayed numbering is updated when the popup is closed (but it's not saved at this point).

The default initial state is the full pagelist of 1–n, but there is also the option of switching the widget the current text-entry mode. This is required for any Pages field that contains more than just a single pagelist element (e.g. multiple, for different parts of a work; or other wikitext).

Extra features:

  • Each thumbnail can be zoomed into (but doing so crops the image when enlarging, rather than making it take up more space on the page).

References:

This task is being considered for a GSoC project for 2020, being mentored by @Samwilson and @SGill. Good microtasks for this project can be found at https://phabricator.wikimedia.org/maniphest/query/vVwnF6GhEs8./#R

Event Timeline

Samwilson renamed this task from UI for creating a pagelist for an Index page to Create OOUI widget for Index page pagelists.Aug 17 2017, 9:06 AM
Samwilson triaged this task as Medium priority.
Samwilson updated the task description. (Show Details)
Samwilson added a subscriber: Tpt.

I've attempted to write this up from our various discussions, but if anyone can improve on it please feel free!

Samwilson updated the task description. (Show Details)

Very interesting, but consider too that the "hard work" is, to browse carefully the djvu file and to find djvu pages/ book pages ("name" or number) relationship; an opportunity too to find lacking/duobled/unordered scans. This is the hardwork that needs - if possible - both standardization among source projects and simplification (it would be great to standardize the name os special pages).

A very good pagelist is mandatory for next step - building a good book structure.

IMHO both steps could be implemented into Commons book template, just to get a draft Index page.

Perfection in rendering a Book design is a hard/impossible task, I think that a realistic goal could be to get a very simplified structure.

Samwilson updated the task description. (Show Details)
Samwilson updated the task description. (Show Details)
Samwilson added a subscriber: SGill.

I find that if there is a good {{book}} template that this is pretty easy with the gadget in place, though find that the triangle of WS <=> Commons <=> Wikidata could really be tightened in a push <-> pull data to make sure that each aligns. That is truly problematic when each does not have maximum data.

Page numbering is always an issue, but they are not easy ever with some works, though having an interface for adding a page number and having it do a visible auto-update in a listing would be handy without having to do a new preview.

@Billinghurst: I agree, and I think the wider topic of Index page's metadata and how it works with Wikidata etc. is going to take some greater thought. This task is specifically not looking at any of that, and focussing only on an easier way to create a <pagelist /> so that editors don't have to have multiple tabs and files open when doing so. Do you think the proposed system sounds good for this? i.e. viewing each page in a zoomable popup etc.

@Billinghurst: I agree, and I think the wider topic of Index page's metadata and how it works with Wikidata etc. is going to take some greater thought. This task is specifically not looking at any of that, and focussing only on an easier way to create a <pagelist /> so that editors don't have to have multiple tabs and files open when doing so. Do you think the proposed system sounds good for this? i.e. viewing each page in a zoomable popup etc.

Not certain that you are going to like my answer.

The purpose of pagelist is to get page numbers as display points/anchors, and to replicate the work when transcluded. The use of long or nonsensical labels simple doesn't work, and are unhelpful in the transclusion. Some I have seen have been quite fanciful. So ...

Keep it simple.

You need:

  1. a starting page for number, (page 1)
  2. the means to specify type (roman, or whatever)
  3. a means to skip numbering on a page and assign a neutral symbol (my preferred symbol is endash, hyphens are horrid as they can be too small to click upon) for all intervening material (either on index page, or on transcluded pages)
  4. the means to restart numbering, ie. say new page 1

That is it, everything is actually superfluous on page numbering.

[Skip the following if you don't want the reasoning, etc.]

<grumble>

Personally I have issues with people creating labels like ToC, title, etc. that are not that way in works. These page types are evident when displayed, and usually have page numbering, so don't need some creative explanatory override by whomever. (We shouldn't do it,)

I don't understand why people arrive at p. 62, the next page is a blank, and then p. 64 and those who wish to blank the page number. For goodness sake it is p. 63, it just doesn't have a number printed on it. (We shouldn't do it,)

I don't understand those who think that page numbering starts at "v" or "vii", did they just spring out of the ground? A page can have a number even though it is not displayed, and in all likelihood we don't transclude it anyway. I have seen a whole lot of trash introduced into works over the years, rather than maintain a standard approach as specified in our style guidance. (We shouldn't do it,)

Plates. their backing pages, or the tissue sheets that are occasionally scanned are perfectly okay marked with the symbol of choice. If they need an anchor we can do it internal to the page, it doesn't need a fat descriptive label. (We shouldn't do it,)

Advertising is okay marked with the symbol of choice if you don't want page numbering. We don't need [adv] or any variations. If truly necessary we can spawn a new <pagelist> (We shouldn't do it,)

As comment, I rarely have major issues with the page numbering, and work it out as I go along. or just wait to the end if it needs perfection. I get the initial pages done, I get the back pages done and see if we have a match. If there are issues in the middle early on, so what can fix it at the end when transcluding.

There are some works that have complex page numbering though they are the exceptions, not the rule. We shouldn't over engineer for some exceptions when we are going to need manual intervention pretty much anyway.

</grumble>

srishakatux subscribed.

Thank you @SGill and @Samwilson for willing to mentor this project! I've added it here https://www.mediawiki.org/wiki/Google_Summer_of_Code/2020#Develop_an_editing_widget_for_Proofread_Page_extension. Please review it once, and add any required skills to this task description as well.
As it is your first time mentoring in Google-Summer-of-Code, I would encourage you to read the Mentors' guide here: https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors :)

Hi, I'm interested in working on this feature during my upcoming summer break :) However, I'm a bit fuzzy about where this feature will get implemented. Like, will it be a part of the core OOUI widgets platform (like the demos page) or will it be integrated as part of the proofreading extension?

However, I'm a bit fuzzy about where this feature will get implemented. Like, will it be a part of the core OOUI widgets platform (like the demos page) or will it be integrated as part of the proofreading extension?

It will be a new widget, and live within the ProofreadPage extension. It's too specific to be a generic MediaWiki-wide widget, let alone an OOUI one.

@Samwilson That makes sense :) Also, could you recommend any resources relating to QUnit and PHPUnit to gain a better understanding of how they work? I've read up quite a lot of documentation on those topics; however, I still feel I haven't gained sufficient intuition as to how it is supposed to work.

I am interested in this task and would like to work as a part of GSoC participant in summer.

I am interested in this task and would like to work as a part of GSoC participant in summer.

Great! @Jayprakash12345 I hope you have checked out the microtasks? If you are yet to set up mediawiki, here is a guide, do install the ProofreadPage extension too

Also, could you recommend any resources relating to QUnit and PHPUnit to gain a better understanding of how they work? I've read up quite a lot of documentation on those topics; however, I still feel I haven't gained sufficient intuition as to how it is supposed to work.

A good thing to do would be to clone the OOUI repo and to explore its code: look at how it does tests, and get them working locally, compile the demos etc.

Sure, I'll look over that and try to figure it out :)

Change 577413 had a related patch set uploaded (by Prondubuisi; owner: Prondubuisi):
[mediawiki/extensions/ProofreadPage@master] PHPcs: T172953 fix PHPcs filename and classname mismatch error update relevent bootstrap files to reflect the change

https://gerrit.wikimedia.org/r/577413

@Prondubuisi You accidentally submitted it for the wrong task, it's T243932 😄

@Prondubuisi You accidentally submitted it for the wrong task, it's T243932 😄

Lol @Soda. I Guarantee that I don't make this type of mistake Often!😄😄

Hi , My name is Jenniline. I am interested in working on this project for Google Summer of code 2020. I will like to work on any of the microtasks available.
I will like to know if there is a mailing list or IRC channel I can ask questions on. Or anyone I can reach out to when I am in need of help.
Thanks

Hi Jenniline, welcome! There are some microtasks linked to in the description above, and more generally you should read through https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker (it also links to IRC, mailing lists, and other communication channels). My username in most of those places is 'samwilson', feel free to reach out with any questions.

Hello @Samwilson. I have been trying to understand how WikiSource works, and your videos on youtube have helped grasp most of it.

Inline with the project description, I need some clarifications;

  • From your explanation the new widget feature will enable Wikisource users click on book page numbers, automatically generated after a book has been uploaded and then have options to number or label them on the fly though thumbnail popups right?
  • If the above is the above is the case, Will editing the label or number of a page affect the number or label of the pages before and after the Just edited page? or will users have to readjust numbering manually page by page?
  • Also I need some help understanding this line The default initial state is the full pagelist of 1–n, but there is also the option of switching the widget the current text-entry mode. This is required for any Pages field that contains more than just a single pagelist element (e.g. multiple, for different parts of a work; or other wikitext).

Also you mentioned that each thumbnail can be zoomed into

  • Are you referring to the book page image here? will the page image be part of the popup thumbnail in addition to a textfield for numbering and a dropdown for labeling the page?

@Samwilson is it possible to try uploading books to a Mediawiki install after enabling the ProofreadPage extension, like is done with Wikisource, or are there extra steps needed to turn a mediawiki install into a wikisource platform?

Respected Mentors! I am interested in this Project. Continuing my flow of writing some few more words i want to ask while extracting the different meta-info as a params from other formats like pdf, or djvu is it possible to add these keys into the OOUI. As of now we need create a widget for Index Page Pagelist. I would like to contribute in creating a scalable OOUI widget which basically transluent from that Interface.

@Prondubuisi You basically need to install the ParserFunctions and Scribunto extensions and also download the djvu-libre, ghostscript and netpbm packages and modify your .htaccess file(based on the instructions at the extension page). After that import over MediaWiki:Proofreadpage_index_template and MediaWiki:Proofreadpage_index_data_config and the other templates used on the index_template from either Wikisource and you should be good to go... (that was my whole install process) :)

If you are using Vagrant, the djvu-libre, ghostscript and netpbm binaries are going to be automatically downloaded as well as the ParserFunctions and some other optional extensions are going to be enabled by the proofreadpage role. You just need to install the Scribunto modules and import the templates and your done...

@Prondubuisi You got it! The Project is all about extending the application inside the <pagelist /> that will have no params initially.
@Samwilson I've question about the default numbers which are invoked will initially refer to the Pages (1-n). Can we not create separate list of pages on the sidebar to pick the pages.?
And afterall on the basis of textlabel i can pick the pages and update their Index number.

I want to co-mentor this project. My role will be limited to suggestions and improvement of the widget. I will not involve in the evaluation of participants and the code review process but will take part as a community member.

Hi Suyash.dwivedi, thanks! It's unclear to me what "suggestions and improvement" is supposed to mean, as the scope of this task is already defined in the current task description. I'm also not sure if having mentors who are only available for some phases is a good idea...

Is everything in this project task planned for Google-Summer-of-Code (2020) completed? If yes, please consider closing this task as resolved. If bits and pieces are remaining, you could consider creating a new task and moving them there.

The widget has been created and it has been enabled on 19+ Wikisources till date.