Extension talk:BookManager/Improve support for book structures

Initial thoughts
This looks great. It's clear you've put a lot of thought into drafting this and I'm impressed with the quality of the writing.

Related to the general idea of books (or collections of pages) is that MediaWiki has, for a long time, worked on a model of subject-space page&harr;talk page. This works decently for Wikipedia, but for other projects such as Wiktionary, with its Citations namespace, this model doesn't work as well. I'm not sure how much of the work you're doing with the BookManager extension will encounter this issue, but it's something to consider, I think.

The proposal mentions Wikisource and Wikibooks and seems geared toward Wikimedia wikis. Is the intention to have the BookManager extension eventually installed on a Wikimedia wiki (or family of wikis)? If so, I think the sooner the extension can be deployed to a test wiki (on Wikimedia Labs or even test.wikipedia.org), the better. There's also writing an extension for deployment to read and digest, of course.

Regarding the schema changes ("make any necessary changes to the core database..."), do you have an idea of what will be involved here (i.e., which tables you'll want to change or add)? This the one part of the proposal that worries me, as (proposed) schema changes can be difficult for a variety of reasons. --MZMcBride (talk) 21:35, 11 April 2013 (UTC)


 * Thanks for the feedback!


 * I'm not quite sure I follow your first point, regarding the Citations namespace and the mainspace/talk namespace model. Both Wikisource and Wikibooks organize their content by collecting a table of contents/index/main landing page for the book on the main namespace page (for example, Haskell or A Jewish State). Then each chapter is located on a subpage of that main page (for example, Haskell/Lists and tuples or A Jewish State/Introduction). The entire work is discussed at the talk page of the main page, and each chapter can be discussed at the subpage talk page. These subpages are all linked together in a somewhat arbitrary way. Wikisource sometimes uses header templates to link chapters together (of which there are several:,  ,  , etc.) and sometimes uses other ways of navigating (see Science). Sometimes even when the header templates are used, they're not used in the normal way, where the next parameter is the next chapter/volume in a chronological order (see Popular Science Monthly). This project won't affect the way the main pages/subpages are organized; it will, however, replace the content of the main page with a easily-navigable structure that is more standard.


 * Yes, the intention is to install the BookManager extension on at least Wikisource and Wikibooks. I agree that it should be installed on a test wiki, and will look into how to make that happen.


 * User:Tpt suggested using JSON to store the book structure and metadata, in a comment on the wikitech-l discussion. I really like this idea, and I think this approach can be used instead of schema changes. Do you agree? GorillaWarfare (talk) 12:31, 12 April 2013 (UTC)

Aims
Hello, thanks for this interesting proposal. However, despite agreeing with its premises, I'm lost right after them and I don't quite understand what you're trying to achieve here.

How did you choose BookManager? I don't know exactly what that extension does because docs are sparse, but the features mentioned there are useless for Wikibooks and Wikisource: The two main reasons we need MediaWiki to know about a "book concept" are the following: The WMF has already worked with PediaPress on the Collection extension (ask User:Tfinc) and volunteers have invested on the Proofread Page extension (Tpt already offered his help): you should probably try and build upon them. This is just my impression and opinion, of course; please advertise your proposal widely on, other Wikisources, Wikisource-l, textbook-l and the various Wikibooks. Regards, Nemo 08:10, 12 April 2013 (UTC)
 * "Automatic navigation" is already achieved by templates or Proofread Page,
 * "Automatic print version" is done by the Collection extension.
 * one-click export of an entire book via Collection extension to PDF, ods, ZIM and ePub format (requests or  to which PediaPress preferred  or b:User:Pediapress/CollectionParser),
 * concept of license and other metadata for the entire book.
 * Indeed we have in the past. There is no current work being done on this but if I can help guide you in any direction then do let know. Tfinc (talk) 20:53, 16 April 2013 (UTC)


 * Automatic navigation is approximated, but I would not go so far as to say it's achieved. Various Wikisource projects use different approaches to try to ease navigation, with varying degrees of success (see my above reply to MZMcBride). Because the navigation systems are so different, we really can't rely on every project, say, using the  template, and even those that do use it will often use it in very different ways.


 * As for the automatic print version, the Collection extension has not managed this yet. For example, if I wanted to print the Pentagon Papers, I would have to go to each page and manually add it to the book. Many users would expect to be able to click "Create a book" or "Download as PDF" in the sidebar of that main page and export the whole project, but they would be disappointed to see that doing so gives them a 2-page file that only includes the title, the header template, the short description, and some licensing information. They can't even get the full index without manually adding Pentagon-Papers-Index.djvu/9 and Pentagon-Papers-Index.djvu/10 to the book. They can't get the full project without manually adding some 7,000 pages. This is an extreme example because of the particular project's size, but even a 20-page project would be tiring to print because of the need to add each individual page to the book. Tpt's WSexport tool does a better job of handling the book structures, but as of yet it can only export to EPUB2, or several other in-development formats (EPUB3, XHTML, and ODT). It also relies on microformat, so projects like Science that don't use a header template are out of luck.


 * Although one-click export and license/metadata are very important, they are by no means the only two reasons to create a book structure (see and the bugs it blocks). Matthew Walker has also contacted me to tell me that this project would be useful for an in-browser book rendering project he was working on. GorillaWarfare (talk) 12:59, 12 April 2013 (UTC)
 * Nemo,
 * 1. The BookManger automatic navigation uses that list and the Proofread Page is done with this. ;)
 * 2.BookManager aims to provide a printable version like [ this] (which for the whole book), and collection does not do it.
 * Regards.-Raylton P. Sousa (talk) 03:14, 15 April 2013 (UTC)
 * And I'm pt.wikibooks administrator and assure that it is not useless... But I agree that the docs are sparse - Raylton P. Sousa (talk) 03:23, 15 April 2013 (UTC)
 * Unfortunately I am unable to get my head fully around the proposal at this point of time. I would say that the Collections extension in its current form is not an efficient tool to generate PDF output of a work with subpages (interepret that as it is a right PITA to use). If there is the means to develop an architecture that will allow means of easy production of other forms than html output, that is a high value feature, especially if new export formats can be easily plugged in. A sequential, minimal click tool is what is required. Extensions that better allows us to simply manage and integrate meta data and navigation are desired, especially where integrating intrawiki and interwiki organisation and data management. — billinghurst  sDrewth  00:32, 17 April 2013 (UTC)