Wikibooks:Reading room/Proposals

From Wikibooks, open books for an open world
Jump to: navigation, search
Replacement filing cabinet.svgArchivesWikibooks Discussion Rooms
Discussions Assistance Requests
General | Proposals | Projects | Featured books General | Technical | Administrative Deletion | Undeletion | Import | Permissions

Welcome to the Proposals reading room. On this page, Wikibookians are free to talk about suggestions for improving Wikibooks.

Coffee table books[edit]

I propose the scope of Wikibooks be extended to include coffee table books, by which I mean books oriented around images. Wikijunior already has many books in the image-per-page format, such as Wikijunior:Animal Alphabet. Allowing non-Wikijunior books in this format could attract contributors to Wikibooks who don't have the specific knowledge needed to write a textbook. A larger balance of types of books on Wikibooks would better justify this project's name. We are Wikibooks, not Wikitextbooks.
The main problem with allowing coffee table books is that we could be flooded with large amounts of what amount to no more than slide shows. There would definitely have to be a policy of some sort mandating that there be text as well as images on every page. Wikijunior has not had a problem with tons and tons picture books of kittens, even though it's conceivable that that could happen.
Coffee table books would probably need a better name, especially if it were given its own namespace. "Table:" might be a bit misleading, and "Coffeetable:" isn't very catchy. Anyway, what are everyone's thoughts on this? Liam987 talk 15:17, 28 March 2015 (UTC)

@Liam987: I agree that this runs a risk of books like Pictures of My Cat but first off, this project doesn't a lot of activity in the first place, so it's unlikely that many users will show up to make out-of-scope books and secondly, a coffeetable book about art history or of travel photos can certainly be educational (or high-res photos of place of worship, etc.) —Justin (koavf)TCM 15:22, 28 March 2015 (UTC)
I can agree with what User:Liam987 said . This is definitely an interesting idea , so instead of outright banning them , why not just moderate the type of books allowed under this format? That is , make a policy/guideline on that?
For instance , my Internet Explorer book has most of its sections primarily centered on images. --Leaderboard (discusscontribs) 15:36, 28 March 2015 (UTC)
  • It's an interesting idea.
If we're considering extending our scope in this direction —which would clearly call for a strong cosensus (following the preliminary discussion we're having now)— we need to be very clear on what we're adding to our scope. What makes a coffee table book? Why, exactly, is it different from a "pictures of my cat" book? When somebody does submit a book of pictures of their cat, we need to have a very clear rational basis for telling them why it isn't appropriate, and for discussing it at an RFD.
We'd want to ground the idea in the wikimedia educational mission. (In theory I understand that to be the theoretical justification for the "textbook" scope of Wikibooks, although I recall hearing, from those who were here well before I came, that there were suspicions of a dubious economic motive being involved too). --Pi zero (discusscontribs) 12:38, 3 April 2015 (UTC)
@Pi zero: Educational merit would have to be requirement, naturally. (Although, as you mention, Wikijunior seems to be a bit of an exception to the requirement. There was some sort of grant that started it. Wikibooks talk:What is Wikijunior has some very enlightening discussions from years ago on the subject.) The problem is, it's hard to quantify educational merit. A few ideas and thoughts:
 • Every page (or most pages in a book) could be required to have text as well as a picture. It is normal for print coffee table books, even photography books, to have large amounts of text.
 • There could be strict guidelines of what types of books would be allowed, and guidelines to define what those books include and don't include. For example, a defined type of coffee table book could be "Nature Photography". There would be a guideline page for books on nature photography, defining scope, requirements, and format, and all books of this type would have to follow it. Each coffee table book would have to, when created, declare which one of the approved types of books it is, or else propose a new type for community discussion.
 • Another problem I could see arising is, among photography books, how to define the scope of a book. What would happen if one editor created Images of London, and another created Photographs of London, but with a very different format and style of photographs and text. Would they be allowed to coexist? Or, would Animals be allowed, despite its very broad scope, and would The Lives and Habits of Albino Male Lions in the Serengeti During the Dry Season be allowed, despite its very narrow scope?
 • Books on photographic technique, or simply showcasing photographs, could be educational, as could travel books, as User:Koavf mentioned. However, there is the problem of a potential overlap with Commons and Wikivoyage. As far as I know, neither project has anything like this, but there is still the question of wether they might not fit better there than here.
As you can see, I haven't thought this through completely. It definitely needs shaping and clarifying before it can become a serious proposal. Liam987 talk 21:12, 4 April 2015 (UTC)
@Liam987: First off, pardon me for lightly editing your comment above. Regarding redundancy, Wikipedia articles oftentimes include etymology, which might overlap Wiktionary. Wiktionary has attestations and citations as quotes, which overlaps Wikiquote. Wikiversity grew out of this project. There will be some overlap between all the sister projects and that's okay. I personally don't think that The Lives and Habits of Albino Male Lions in the Serengeti During the Dry Season would be a problem at all: if we have the content, why not display it? It's not like this is print and we have only so many pages or a bookshelf that holds only so many books (or an actual coffee table!) For what it's worth, nothing on Wikijunior strikes me as un-educational... —Justin (koavf)TCM 04:05, 5 April 2015 (UTC)
@Koavf: I agree with you. I wanted to bring up some potential problems/objections I could think of, but I agree that none of them would be major problems. Liam987 talk 22:32, 9 April 2015 (UTC)
I'm not convinced they are out-of-scope today... The implied "textbook" (as in "Wikitextbooks") is really about excluding fiction and things like biographies. A book of, for example, pictures taken by the Hubble space telescope with short captions is both educational and non-fiction. QuiteUnusual (discusscontribs) 10:25, 10 April 2015 (UTC)
Sounds reasonable to me. --Pi zero (discusscontribs) 11:11, 10 April 2015 (UTC)


I'd like to invite suggestions and opinions on an idea I attempted some years ago, and am thinking of trying again with an improved internal look-and-feel.

My idea was to have a single template that describes the organization of a whole book, called (in the current version) Template:name of book/Navlist, and then a suite of templates you can place on the pages of the book that automatically generate a table of contents, or a navigation box for the top or bottom of a page, or whatever other such thing is wanted. Using, of course, various formats for the TOC or the navboxes, depending on what is wanted for the particular book.

I implemented this, but at the time I had to rely entirely on wiki templates, and as a result, the format of the navlist was a bit odd-looking. (There were also some size limits because generating things from the navlist involved large numbers of template calls.) You can see the suite I created at {{Navlist}}, an example of a book using it at Conlang, and the navlist for that book at {{Conlang/Navlist}}.

I now have the means to rewrite the suite templates so that each book navlist uses a more readable format, and the suite templates parse the book navlist (which also drastically reduces the number of template calls involved).

So here are some questions, if anyone would like to offer their thoughts:

  • Is this a worthwhile idea to pursue?
  • What format should the navlist for each book use? Something based on wiki list notation, perhaps? Or something else?
  • What sorts of formats ought to be supported for tables of contents, top-boxes, bottom-boxes? What other kinds of things might be generated from the book's navlist?
  • (thrown in, gratis) Suggestions for other kinds of things that could benefit from being generated automatically, like this? I know of a Wikijunior book, for instance, that has a glossary, and then repeats items from the glossary on content pages here and there; I'm thinking a template could be set up so on the content page you can just say, basically, put the glossary definition of such-and-such here, and the template would go parse the glossary and snarf the appropriate definition from it. Or possibly one would have the glossary data in a template, and the glossary page itself would also be generated by extracting data from that template.

Miscellaneous notes:

I was worried, from the start, that the navlist would be vulnerable to mistakes, or vandalism, as a single-point-of-failure; however (unlike Wikidata which is outside the projects it affects), the navlist is grouped with the book. I have in mind, in the long run, we could build a tool for checking to detect dropped pages, and perhaps other kinds of anomalies.
I belive strongly that control of a project should rest in wiki markup, maximizing its accessibility to ordinary wiki users (even if in some cases it's fully protected; it's still more visible and understandable as wiki markup). So I've developed a device for implementing sophisticated stuff within wiki markup (not yet imported to Wikibooks, but I anticipate doing so; atm it's yonder). An example of using it for a navlist-like constomization device is n:Template:Infobox; that's a generic news infobox, where you can just name a category, like {{infobox|France}}, and it'll go look for a customization file for France; the customization file, if it exists, calls a template that sets up a wiki table containing the customizing parameters, so, and {{infobox}} parses the wiki table.

--Pi zero (discusscontribs) 14:20, 3 April 2015 (UTC)

Really interesting ideas. The stub template on the French Wikipedia, w:fr:Modèle:Ébauche, works like the kind of template you're describing (I think). {{Ébauche|France}} calls on {{Ébauche/paramètres France}} for image, portal to link to, category, and so forth. As regards the Navlist, it seems like a good and very useful idea. I am concerned, though, that it is confusing for an editor unfamiliar with the workings of wikicode to add or edit the table of contents at a page like Template:Conlang/Navlist. Is there a way to hide more of the code from a casual editor? Liam987 talk 20:21, 4 April 2015 (UTC)
@Liam987: The scary notation of {{Conlang/Navlist}} was always one of the things that bothered me about it, even though I was pretty excited I got the suite to work. It's now possible to use almost any (wiki-based) syntax we want, which presents a different kind of problem in that, with no constraints to force us to do things a certain way, we have to decide what we think would be most useful — most readable and most writeable, presumably. It may turn out that there are practical constraints after all, when I get into the coding, but meanwhile, I'm interested in any thoughts on what others think might work well. --Pi zero (discusscontribs) 23:03, 4 April 2015 (UTC)
@Pi zero: I've added a Navlist using your template on Breton, which I've been restructuring around imported Wikiversity material. It works very well, although one comment I have is that it would be useful to be able to have multiple levels of navigation in the {{Navlist/Top}} template. For example, the Breton books is structured into six levels and multiple lessons for level. I would like to be able to have the Navbox at the top of each page to link both to the next level and also to the next lesson, so that Breton/Level 2/Lesson 2 would link to Breton/Level 2/Lesson 1 and Breton/Level 2/Lesson 3, and then below that also to Breton/Level 1 and to Breton/Level 2. Also, more customizability as to which order pages are linked to, and maybe the ability to add pages to the Navbox list but not have them automatically included in the sequence for {{Navlist/Top}} and {{Navlist/Bottom}}, for optional subpages that are outside the main sequence of the book. Overall, though, these templates are great and I compliment you on them. Liam987 talk 20:59, 8 May 2015 (UTC)
@Liam987: Do you have suggestions on the question of navlist format? Since you've actually used it. I'm thinking the current format is extremely heavy on braces and pipes (wiki template-call notation), and since I think I need a more efficient and simpler internal implementation anyway, I can use pretty much any format I want. There's a bewildering range of possibilities, whereas when I first implemented the template suite I had such technical constraints I barely came up with one way it could work. At that time I thought about more complicated navbox formats and basically gave up because the implementation would be too hairy; now I could tackle more more elaborate navbox formats once I overhaul the internals, but I need to get the navlist format issue settled before I overhaul the internals. --Pi zero (discusscontribs) 10:20, 11 July 2015 (UTC)
@Pi zero: That's very interesting indeed, and the Wikilisp thing is just beautiful. In the Haskell book we have our own intricate web of templates, far less sophisticated than yours, that allows us to change the TOC and have it reflected everywhere with (almost) just one change − and I'm really glad it exists. The more books can benefit from similar features through a generic implementation the better. Two extra comments:
  • One feature you might find worthy to implement is grouping. In the Haskell book, the TOC is subdivided in groups of 8-12 pages, and the navigation templates allow you to switch to a page within the same group without having to return to the index, as well as moving to the start of a different group. That can make navigation a lot smoother in large books.
  • Perhaps I'm not thinking straight right now, but by "Or possibly one would have the glossary data in a template, and the glossary page itself would also be generated by extracting data from that template" do you really mean it is feasible to build something like a glossary by doing reverse lookups across a book? The use case I have in mind is a back-of-the-book index of terms. Several times already I have been tempted to create one for Haskell, but the maintenance burden for a large book might become unmanageable. Automated generation would definitely make it feasible, even if, say, it turns out that we would have to request updates manually for technical reasons.
Duplode (discusscontribs) 19:54, 13 July 2015 (UTC)
@Duplode: If there's some sort of "navlist" that lists all the pages in the book, it ought to be possible to go through that list of pages, extract glossary-item definitions from each of them, sort those entries in whatever way one wants, and produce a glossary page. I can think of two possible problems with that. One problem is that for a large book it might exceed some transclusion limits of the wiki software (which is also a potential problem with building a "print version" page; I can maybe see a tolerably doable way around that, eventually). A probably-lesser problem is that if the glossary is really dependent on all the other pages of the book, then the glossary will have to be recomputed every time any page of the book is edited. --Pi zero (discusscontribs) 02:57, 14 July 2015 (UTC)

Annotated Jurassic World Wikibook. Good idea?[edit]

I'm sure you're all aware that the summer blockbuster Jurassic World has just been released. Wikibooks's annotated texts policy states that works annotations for movies can be created here, and the featured status of the Muggles' Guide to Harry Potter suggests that these sorts of companion pieces to copyrighted works are acceptable here, so I was wondering if a book-length scene by scene breakdown of the scientific accuracy, effects, screenwriting, cinematography, etc of Jurassic World, like a movie version of Cliffs or Spark Notes, would be a viable project here. I posted this at the general reading room but it only got commented on by one (admittedly unenthusiastic) editor and I hoped posting it here too would attract some more eyes and comments. Abyssal (discusscontribs) 17:18, 15 June 2015 (UTC)

It all depends on the "educational" content, in general blockbuster movies are not worth speaking much about in regards to creative writing or even the cinematography. This one in particular, Jurassic World, is a very poor example of movie art, its full of cliches and the logic of the script goes out of the window about 30m in. In general it would be better to go about it like we go about biographies, avoid covering contemporaneous subjects since they bring about a lot of emotional baggage... --Panic (discusscontribs) 09:50, 15 June 2015 (UTC)
I'm reposting the above since it got "deleted" without notice even if I got it back from my contribution history it did not appear on this pages edit history... If you made a significant contribution check it out since it may have been a hiccup on the project's servers.--Panic (discusscontribs) 17:49, 15 June 2015 (UTC)
@Panic2k4:. It's because Abyssal posted the question twice. Your original comments are over at Wikibooks:Reading room/General. QuiteUnusual (discusscontribs) 07:31, 18 June 2015 (UTC)

Restructuring Linguistics[edit]

I have proposed a restructuring of the Linguistics book at Talk:Linguistics#Restructuring. Over the years, the book has seen many additions to its contents, and it seems that each additional module was added to the end of the book, in a way similar to the stack data structure. As such, I feel it is more appropriate to restructure the book now. I also plan to add chapters previously suggested by another user on the talk page. The only action that will require admin interference is the deletion of Linguistics/Computational Linguistics, which I think is a topic not possible to introduce in an introductory book on ling. Kayau (talk · contribs) 15:30, 22 June 2015 (UTC)

Redirecting recipes[edit]

Would it be possible to redirect Spanish Omelet and other recipes to the corresponding Cookbook:Spanish Omelet and such?-- (discuss) 23:56, 11 July 2015 (UTC)

Personally, I'm not too fond of this idea because we could have an entire textbook called Spanish Omelet about the history, etc. of Spanish omelets. I think an alternative method would be for the Special:Search to list Cookbook (and Wikijunior) pages by default in the search results. (As it currently stands, only the mainspace, Wikibooks: and Subject: are included). An admin should be able to change that setting. Kayau (talk · contribs) 09:36, 12 July 2015 (UTC)
Like you, I thought default search included mainspace, project space, and subject space. By empirical testing, though, it seems that under some circumstances it's only mainspace.
I don't know of a hook for admins to chance this; afaik it's part of our project configuration. So we'd need to get a community consensus and file a request at phabricator (we did this within the past year or so at en.wn, and it went fairly smoothly except that even the most experienced of us had trouble figuring out phabricator). --Pi zero (discusscontribs) 10:23, 12 July 2015 (UTC)
This? mw:Manual:$wgNamespacesToBeSearchedDefault I don't know enough about the MW software to know if this can be set by admins though. Is Phabricator the new Bugzilla? Kayau (talk · contribs) 14:54, 13 July 2015 (UTC)
Yeah, that's the variable. It's in php, beyond the reach of admins. Phabricator is now used for what previously used bugzilla. The "ph" somehow reminds me of the word "phony". --Pi zero (discusscontribs) 16:12, 13 July 2015 (UTC)
Maybe because of the word 'fabricate' (as in 'fabricate truths'). :P Kayau (talk · contribs) 05:41, 15 July 2015 (UTC)
I agree with the original poster that typing "Spanish Omelet" in the search bar at the top should either include Cookbook:Spanish Omelet in the list of results, or go directly to that page. I agree with Kayau that adding "Cookbook" to the list of default search namespaces is a better way of accomplishing that goal than setting up a bunch of redirects.
What's the next step towards adding "Cookbook" to the list of default search namespaces? --DavidCary (discusscontribs) 14:03, 17 July 2015 (UTC)
I think we are all in agreement. In fact after adding the extra namespaces to the default search function it would be great to permit to toggle in and out the appearance of redirect pages from the search results, this would solve issues with having people create them in the first place (even working as a patch if the first is not possible). --Panic (discusscontribs) 03:48, 18 July 2015 (UTC)

Allowing reviewers to move pages while deleting the original page?[edit]

If you've ever patrolled recent changes while I was very active (i.e. 2009, 2010, 2013 or 2015), you've probably noticed that I move pages a lot when I write. I split pages, merge pages and rename pages a lot as I write, since I often come to the realisation, while writing, that this chapter will eventually grow too long or that chapter is too short to be independent. I think allowing reviewers to move pages while deleting the original page would lessen the workload on admins a bit and eliminate the minor and harmless (but annoying) inconvenience of waiting for an admin to delete the page. Kayau (talk · contribs) 08:10, 23 July 2015 (UTC)

I ran into a similar scenario the other day − I messed up a few page moves and left a mess of {{speedy}} requests for the admins to deal with so that I could undo the moves. However, I feel the change you propose is risky, as it effectively would give all reviewers a loophole to delete any page.--Duplode (discusscontribs) 21:20, 25 July 2015 (UTC)
Aye, there's the rub. Move-without-leaving-a-redirect is essentially a limited form of deletion; the power to delete is a big deal; and we hand out the review priv to users here on a fairly relaxed basis. --Pi zero (discusscontribs) 01:26, 26 July 2015 (UTC)