Book management 2013/Technical notes

Similar extensions

I've been using some similar extensions as examples for some of the code:

• EventLogging, for an example of an extension using ContentHandler
• TemplateData, for an example of an extension that uses JSON content without ContentHandler

JSON

The JSON will be structured and validated using the ContentHandler facility. The JSON will be stored on wiki pages with the extension ".book", which will identify them as containing JSON content. The schema will be stored on-wiki, where it will be editable (see, for example Schema:AccountCreation). This presents somewhat of a localization challenge, but it should be manageable through Mediawiki: interface messages.

Forms

The forms will be auto-generated from the JSON schema using HTMLForm. If possible, BookManagerv2 will work together with the ProofreadPage extension, so that only one form is necessary for wikis that use both extensions (e.g., Wikisources). If ProofreadPage also uses HTMLForm, the form array can be edited to insert the new values. Wikis without ProofreadPage will just have a single, BookManagerv2-only form.

Page reordering

jQuery UI's sortable is lovely, but will require a fallback for users without JavaScript. This will ideally be in the form of textboxes, which will allow them to change section numbers and levels, which can be validated on send.

Questions

• Should this fully support users who don't have JavaScript?
  • Yes.
• How should the manager handle chapters of the book that consist of included Index pages? (example, source)
  • Box above the edit window in which page ranges could be added (although this wouldn't allow for additional page formatting)
  • Leave the system alone
• What will the manager need to make sure it will be compatible with the Visual Editor?
• How will a user indent/outdent sections in the editor?
• How will the editor handle long works (between 500 and 40,000+ chapters)
  • Technical: How it is processed?
  • UX: How the user will interact with that large number of pages consistently?

Integration with ProofreadPage

Wikis like the Wikisources will, hopefully, have BookManagerv2 installed in addition to ProofreadPage. Because of this, if BookManagerv2 is implemented as a form taking as inputs the values at Book management/JSON, there will be duplication with the Index pages created by ProofreadPage. To avoid duplication, and to avoid the user needing to submit two separate forms per work, there should be some interaction between the two extensions. Each should also be able to function without the other. Ideally, there will be an Index page for each scanned content. Each work (which can match up with a scan one-to-one, many-to-one, or one-to-many) will have a ns0 page and a BookManagerv2 page.

Forms

Possibilities:

• BookManagerv2 uses a separate form, regardless of whether ProofreadPage is installed
  • Easier to develop
  • No conflicts between the extensions
  • Two separate forms means more work/chances of confusion for the user
  • Two forms with some overlap in content have the potential for conflicting information
• BookManagerv2 injects additional fields into ProofreadPage's Index pages if it's installed, otherwise uses a distinct from
  • Harder to develop
  • Potential for conflict
  • Requires ProofreadPage and BookManagerv2 to have similar enough code to allow this (e.g., both using HTMLForm)
  • One form is easier for the user
  • No conflicting information or overlap

Questions

• How should we identify BookManagerv2 pages? Book: namespace? .book extension?
• Should we somehow integrate BookManagerv2's metadata pages and ProofreadPage's Index pages?
  • I believe we've reached an agreement we should
• Where should this data be introduced?
  • I think we all want the data to eventually be stored on Wikidata, but that is probably not within the scope of the BookManagerv2 or ProofreadPage GSoC projects.
• The book upload customization team is working on generating metadata forms from templates. Should this be integrated somehow?
• Scans can depict one work, depict several works, or be a part of a work. What should the mapping of scans, index pages, "main book pages" (the "landing page" of a book in ns0), and BookManagerv2 pages be?
  • Suggested that there be one Index page per scan, and one BookManagerv2 page and main book page per work.
• Should BookManagerv2 attempt to autogenerate the <pages index> tags? Would this perhaps be better-suited to a bot?
• What metadata should be stored by ProofreadPage in the Index namespace, and what should be stored in the BookManagerv2 pages?
  • Suggested that the BookManagerv2 page only contain metadata related to the work (author(s), title, subtitle, translator(s), etc.), while Index pages contain edition-related metadata (publisher, printer, date of printing, volume number, etc.).
  • Suggested that BookManagerv2 pages contain most of the edition information, with some exceptions: the volume number only makes sense on Index pages when a work is split into several scans. Sometimes two volumes of the same edition do not have the same printing date (for example we can have volume 1 printed in 1886, and volume 2 printed in 1887)... Other corner cases?