Wikibooks:Reading room/Proposals

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.

Now under construction: Wikibooks StacksEdit

As part of the infrastructure overhaul I've been doing for, at this writing, just over 23 months, and following from the previous discussion here in the ongoing series of threads (link), I'm now developing a replacement for the current subject hierarchy, in the form of a book called Wikibooks Stacks.

I'm not currently asking for help with this, tbh. Somewhat embarrassingly, given the collaborative nature of wikis, just atm I really need to do this carefully, step by step, myself, because there's still new design work involved at each step. But I do want to let everyone know what I'm doing, and perhaps folks here will offer advice (or point out that I'm making a huge mistake somewhere!).

When I'm all done, all our 3000-or-so books will be filed in both the "old" subject hierarchy and the "new" stacks, and I'll be able to do the equivalent of flipping one of those big high-voltage switches and suddenly the categories visible on each book main page will be shelves instead of subjects, and then I can start the process of carefully mothballing the old subject pages, one by one. Then it'll be time to start in earnest on the final(?) stage of this multi-year overhaul of our infrastructure, the introduction of topical categories that list pages as well as books, which will enable us to provide much better targets for incoming links from sister projects, including from Wikipedia.

Grouping all of this machinery in a book is more convenient, organizationally, than the Subject: namespace, as it happens. The new pages, equivalent to subjects, have name prefix Shelf: or, at the top level, Department:, which are not recognized by the wiki platform as namespace prefixes, so these pages are all technically in mainspace, as is the book. Our infrastructure templates such as {{BookCat}} and {{BOOKNAME}} know to associate these name prefixes with book Wikibooks Stacks, which is convenient because most of the pages involved don't have to have the name of the book built into them at all, they can just use markup {{BOOKNAME|Shelf:}} (which expands to Wikibooks Stacks). Shelves correspond to subjects that use {{subject page}}, departments to subjects that use {{root subject}}.

There are shelf categories, each with an associated allbooks category, just as there are subject categories with associated allbooks categories. When I set up the machinery of the subject hierarchy, I arranged that when any of the pages involved detected a problem, it would flag it out, and provide buttons to help a human operator implement likely actions to fix it. This time around, I've made some improvements to this semi-automation while I was about it.

I also very much want to arrange for dialog-based assistants to replace the older-style editing buttons (with the older-style buttons reappearing if the dialog tools are not detected — thus, graceful degradation when things aren't working right). This would be very cutting-edge use of the dialog tools, and I very much want to learn as much as I can from the experience, about how to make effective use of the dialog tools. Which is actually part of what's holding me up just atm: I could be marching forward with setting up shelves, but then I'd be missing out on this major opportunity to gain experience with dialog. --Pi zero (discusscontribs) 19:51, 3 June 2018 (UTC)

Progress report: All our books have been shelved; they're also all listed in subjects. The shelf categories are hidden, the subject categories are visible; but I'm now in a position to switch that, so the shelf categories are visible and the subject categories hidden. Then I can start shutting down the subjects, which also has to be done manually. Strangely, I've got a discrepancy between the number of shelves and the number of subjects, whose cause should eventually come out during the manual shutdown. I'm not sure what to do about possible incoming links to subject pages that are now going to be either nonexistant or redirects. --Pi zero (discusscontribs) 02:26, 29 September 2018 (UTC)
Cheers for all the work you have made already. I noticed two things which I'm not sure whether they are glitches or not: 1) Departments do not list any featured books. 2) Under Wikibooks Stacks/Departments the Wikijunior department correctly lists the Wikijunior shelf, but the Help department does not list the Help shelf. -- Vito F. (discuss) 23:46, 10 October 2018 (UTC)
On the second point, actually the link provided is to the help shelf, rather than to the help department. I'm unsure whether that should be treated differently, or if instead the wikijunior department should be treated differently. --Pi zero (discusscontribs) 04:03, 11 October 2018 (UTC)
I think I've got the department featured books problem fixed. --Pi zero (discusscontribs) 06:43, 12 October 2018 (UTC)
I've improved both of those displays on the departments page. --Pi zero (discusscontribs) 12:44, 13 October 2018 (UTC)
Update: My progress on this is currently mired in the various pages associated with quality as assigned by various "WikiProjects". That part of our infrastructure was imported by Adrignola and adapted for Wikibooks —mainly by adding support for Subject pages— back in 2010; it isn't heavily used, but wants updating to support the rearrangement; except that frankly I find its internal design largely indecipherable. How Adrignola figured it out to make changes then, I find hard to imagine, and it's worse now with existing use of the Subject-based version to accommodate. --Pi zero (discusscontribs) 13:28, 22 January 2019 (UTC)
Still mired. --Pi zero (discusscontribs) 21:14, 8 April 2019 (UTC) – 11:25, 7 September 2020 (UTC)

Proposal: add features that support ebook writers betterEdit

Hi there, on the general discussion yesterday I mentioned that I would find it useful to have many of the features of Wikisource available here. This would allow creation of books that feel like books, and export well to epub / mobi formats. Specifically we could support:

  • optional narrow single column formats;
  • optional serif fonts for body text
  • Differing styles for headings and so on (not always underlines)
  • easy navigation bars (last page, next page)
  • optional export links to common ebook formats

Wikisource has developed all of this to support replicating books. Most ebooks have copied this formula more or less as they are produced with print editions. Wikibooks could offer these features as a option for book developers who believe their audience is primarily offline rather than online.

I suspect the work involved is not too great, as the code should already exist. But I can't say for sure, some things like layout options might break some pages and need to be enabled case by case therefore. Similarly many Wikibooks won't export well to epub due to the way tables are not properly supported by many readers.

I think this could open Wikibooks usage to a lot more use cases. I am certainly missing being able to do things along these lines for some book ideas I have, like sample language readers and dual language readers for learners. These don't suit Wikisource as they're incomplete extracts, potentially with editing or simplification, but don't work too well here because the destination format is not currently well supported. JimKillock (discusscontribs) 07:57, 22 April 2020 (UTC)

Jim, s:en: has a lot more templates for formatting text. Have you poked around there to see what our sister project has for formatting in a MediaWiki context? —Justin (koavf)TCM 08:25, 22 April 2020 (UTC)
Yes absolutely, I have been doing a chunk of work there and that is what prompted me to make these suggestions. Is it just a question of me going ahead and copying templates over? or should I suggest which might be brought over and why? (That said I've not investigated the way the page formatting templates work, perhaps these are also imply traditional templates.) JimKillock (discusscontribs) 17:14, 22 April 2020 (UTC)
I am active in Persian Wikibooks and there these two issues are on rise, too: Author rights and issuing books. I believe that writers and editors in Wikibooks differ with writers and editors of Wikipedia. In Wikibooks authors are eager to register their names (or usernames as nicknames) on a separate page inside the book, e.g. Wikijunior:The Elements/Authors and Wikijunior:Ancient Civilizations/Authors. Considering practices for issuing knowledge, Wikibooks is different from Wikipedia, too. Print version is a feature more important for Wikibooks than Wikipedia as the content of Wikibooks is supposed to be used by learners (better called readers) who may prefer an offline version of the book. In my opinion, PDF version is good enough as it can be converted to epub just by one click using softwares even available online. --Doostdar (discusscontribs) 18:11, 22 April 2020 (UTC)
I don't personally agree that pdf » epub conversion is a great idea (epub is basically html so Wiki to epub is natural where PDF’s basis in postscript does not convert so well back to html); but luckily we don't have to choose; Wikimedia already has the tools. The question then is how to make exports easy for readers who are more likely to want that as you say.
I really like the way Italian Wikisource have enabled exports for instance, see this example I was recently shown. JimKillock (discusscontribs) 19:16, 22 April 2020 (UTC)
We certainly can copy templates: they are all freely licensed. It's usually better to have someone with the appropriate user rights to do this via Special:Import. I brought up Wikisource only because you may be able to identify existing solutions to some of these problems you raise. —Justin (koavf)TCM 19:37, 22 April 2020 (UTC)
Thank you Justin, that is very helpful. JimKillock (discusscontribs) 21:42, 22 April 2020 (UTC)
@JimKillock: There are some differences between the provisions for css on different projects, which probably should be kept in mind when contemplating introducing advanced formatting from another project. This may both complicate things and allow some interesting new techniques. (Alas, I have some awareness of the Wikibooks infrastructure, and more about the Wikinews infrastructure, but no past experience with the Wikisource infrastructure.)
  • Different projects may have very different approaches to their customized css. Wikisource appears to have a very small, simple common.css; either there must be some additional css, perhaps induced somewhere by javascript, or perhaps it's all done using javascript instead of css. Wikibooks does a lot more in its common.css, a lot of it arranged modularly in subpages. (For contrast, the Wikinews common.css is all on the one page, which makes it considerably harder to read.)
  • Wikibooks has book-specific css pages: our common.js checks for the existence of a subpage for the book, and imports it if found. (Then again, Wikinews has page-specific css pages, also checked for and imported by its common.js.)
  • The javascript infrastructures are also different between projects. Wikibooks common.js provides for both book-specific and page-specific javascript pages, and its common.js is largely modular. The page-specific javascript, btw, is key to the dialog tools, and was adapted from Wikinews — changing the naming-convention for the page-specific javascript pages, because the Wikinews convention conflicted with the modularity naming-convention of Wikibooks. (Yes, the Wikinews common.js is all on one page, yes that makes it very hard to read, and yes I have considered modularizing it.)
--Pi zero (discusscontribs) 01:31, 23 April 2020 (UTC)

Interesting post Pi zero, but some comments on it:

  • I believe that the bulk of the Wikisource site-css is at MediaWiki:Gadget-Site.css. For some reason some mediawiki wikis use this file rather than the common.css used by others; see mw:Manual:CSS.
  • Custom CSS is now rather easy due to TemplateStyles: see mw:Extension:TemplateStyles. The chief advantage over perbook css is that you don't need admin access to edit, making it easier for most users; also it can be added to any page without the need for it to correspond to a particular book. Despite the name, TemplateStyles can be applied to non-template namespaces, and I have created Template:TemplateStyles/Oberon/styles.css to do so.
  • But if custom JS is needed it still needs to be done through perbook JS. --Jules (Mrjulesd) 12:48, 23 April 2020 (UTC)
I'm interested to hear where the css might be hiding in the Wikisource infrastructure. (Yes, I'm familiar with this sort of use of gadgets.) --Pi zero (discusscontribs) 18:03, 23 April 2020 (UTC)
Well it does actually hide in MediaWiki:Gadget-Site.css; despite its name it actually contains the bulk of the site-wide CSS. A similar situation is with the site; if you look at mw:MediaWiki:Common.css its empty, and its site-wide CSS is actually held at mw:MediaWiki:Gadget-site.css. The reason given for this is that " controls site CSS with the Gadgets extension, so MediaWiki:Gadget-site.css is used in place of MediaWiki:Common.css. This results in a slightly different load URL." --Jules (Mrjulesd) 18:29, 23 April 2020 (UTC)
What is the right thing for me to do to move this forward? Should I make a list of templates I would like to have moved over? JimKillock (discusscontribs) 10:17, 25 April 2020 (UTC)
That could help to make it all more concrete; we've probably taken the purely abstract discussion of project infrastructures about as far as it can go. --Pi zero (discusscontribs) 12:09, 25 April 2020 (UTC)
OK, so here we go, these would be the things I would suggest as a start:
Yikes. That does look rather... involved. It appears, at first blush, also to have some assumptions built into it about uniformity across the project, that are true for Wikisource but wouldn't be for all of Wikibooks. I hope I'll have a chance to take a closer look sometime in the nearish future... --Pi zero (discusscontribs) 16:05, 25 April 2020 (UTC)
Thanks, I guess it is the layout system that looks complex. If there is a simpler way of achieving the goal of a narrow column plus serif fonts, maybe we could consider that?
The other templates ought to be quite simple (I could be wrong). — Preceding unsigned comment added by JimKillock (talkcontribs) 18:23, 25 April 2020 (UTC)
@Pi zero: Thought I would flag that it'd be good to think of a simpler way to get the desired result – I don't want to make this stall! If I can help in any way, please let me know. I can bodge around CSS a bit. JimKillock (discusscontribs) 08:08, 29 April 2020 (UTC)
@Dirk Hünniger: See the list above, but especially s:la:Formula:Titulus; now in active use, eg s:la:Ólim JimKillock (discusscontribs) 22:13, 3 May 2020 (UTC)

Hi @Pi zero:; I thought I would ask as it has been a month since we last spoke whether you'd been able to think about the practicalities of doing this a bit more? JimKillock (discusscontribs) 07:49, 3 June 2020 (UTC)

Hey @Pi zero:, did you have time to think about this a bit more? I have a bunch of projects I feel would only work with something along these lines which I am holding off while we decide what to do.
If the answer is that it is too difficult given how Wikibooks is set up, then I think we need to know, perhaps for instance to consider a clone of Wikisource for ebook production. EWikibooks? JimKillock (discusscontribs) 11:40, 2 July 2020 (UTC)
Very much hoping someone can help / respond. I have a couple of projects where I want to combine English and Latin for e-book export. These fall outside of the Wikisource criteria - they would either reprocess / correct / add accentation, add new translations, link to musical content, etc.
If I can't do this on Wikibooks, then I cannot see how to develop these projects on a Wikimedia platform. Yet surely this is exactly what Wikibooks is for. So I am at a loss and now a little disappointed that we are unable to come a clear answer - even a firm "no" after three months. JimKillock (discusscontribs) 12:16, 9 August 2020 (UTC)
/me hopes to take a close look at this tomorrow. --Pi zero (discusscontribs) 00:34, 10 August 2020 (UTC)
@Pi zero: quick mention in case you have time to take another look! JimKillock (discusscontribs) 06:55, 22 October 2020 (UTC)

Suppress redirect featureEdit

Hello folks, so I just came up with a thought. Yesterday I was performing some botched moved and damn they were many. The redirects which were created were unnecessary therefore I had to tag them all for speedy deletion. This is really tedious and sometimes causes a lot of inconveniences in editing especially when no admin is online. I hereby propose the following:

  • Proposal one A creation of a user group similar to the “page movers” user group on Wikipedia. The user right should make an editor:
  1. Be able to suppress redirects when making a move
  2. Move a page/books and its subpages with an increased limit of 100 pages/minute
  3. Note Requests for this permission to be made at RFP similar to other permissions and only granted to users with experience in page moves
  • Proposal two The suppress redirect feature and 100 pages/minute feature be introduced into the reviewer toolset.


  •   Support: Proposal two --Synoman Barris (discusscontribs) 11:23, 14 September 2020 (UTC)
  • While I appreciate your frustration in this case, honestly I'm inclined to   Oppose extending the suppress-redirects priv. Some various thoughts:
  • Renaming pages always has the capacity to get things tangled up, but suppressing redirects has the potential to make this even worse, by losing track of various associated tasks that need to be untangled as part of the larger operation. When drawing down the list of requested speedy-deletions just now, there was a bunch of untangling to do that would have been significantly harder if redirects had been suppressed. When things get significantly snarled (a rare occurrence, but something I've seen happen a few times), it typically would have been worse without redirects, and, seems to me, usually the user who got tangled up learns from the incident more elegant ways to handle similar situations thereafter.
  • When a whole book has to be moved, please ask an admin to do it. Admins can move a page and all of its subpages in a single action, and can suppress redirects and handle other associated subtasks at the same time.
--Pi zero (discusscontribs) 14:00, 14 September 2020 (UTC)

  Comment : On the English Wikipedia, when I move a page, I see a checkbox labeled "Leave a redirect behind" that is selected by default. I could swear this feature existed before I became a Wikipedia admin, although I was a reviewer and don't know if this feature was part of a reviewer's toolset. I would support making this feature available the same way it is made available on Wikipedia. Anachronist (discusscontribs) 14:03, 14 September 2020 (UTC)

  Support proposal one, weak   Oppose proposal two. I'm not hugely active here, but the page mover right works quite well on the English Wikipedia. I'm not exactly comfortable with granting reviewers too many additional rights though, because then they would become sysops without sysop functionality, especially since this right should be granted automatically. However, on Wikidata, autoconfirmed users automatically have the ability to patrol pages, move pages without leaving redirects, and have their pages marked as autopatrolled. Then again, maybe it's because there isn't much demand for rights there, and most users need just autoconfirmed access to use one of Magnus Manske's semi-automated tools, so most (autoconfirmed) users can be trusted with these flags. Maybe it's also because the rules there are more tolerant and lenient. Reviewers are selected to clean up vandalism, not clean up page moves and other adminny stuff. Otherwise they'd be called "subadmins" or something of the like. Prahlad balaji (discusscontribs) 04:38, 15 September 2020 (UTC)
  Oppose proposal 1 because that would just clutter the permissions toolkit (and I am not a big fan of the demarcation of permissions that Wikipedia does).   Weak support proposal 2 because while I can see Pi zero's opposition, on the other hand we currently have to give reviewer permission manually, so I don't see adding two permissions as a big problem, given that reviewers by default are supposed to have a degree of experience already. Leaderboard (discusscontribs) 15:06, 14 September 2020 (UTC)
@Leaderboard: requesting reviewer at rfp is only a temporary solution. Would you support proposal one and/or oppose proposal two if the bug fixed itself? Thank you. Regards, Prahlad balaji (discusscontribs) 04:39, 15 September 2020 (UTC)
@Prahlad balaji: I'll stay opposed to the first one, and probably be neutral for the second - because I don't see a mistake with it, just a bit risky. After all, those who are automatically granted reviewer do have some experience, similar through less rigorous than Wikipedia's Extended Confirmed permission. Leaderboard (discusscontribs) 13:33, 15 September 2020 (UTC)
@Leaderboard: ok, thanks for the explanation. --Prahlad balaji (discusscontribs) 14:42, 15 September 2020 (UTC)
@Leaderboard: autopromotion has started working again. --Prahlad balaji (T / C) 02:28, 19 September 2020 (UTC)
  • Alt proposal, leave them. Redirects are cheap, so cheap that it really isn't worth wasting time over them unless they are pejorative or misleading. So rather than make it easier to delete or not create redirects, I would suggest just accepting that there are going to be lots of redirects from typos of names. OK each individual typo may be so rare that in some cases they won't recur. But across thousands of redirects there is a real value in keeping them, even if only hundreds are ever used by someone making the same typo, while there is zero gain in deleting them, and time spent reviewing them and deciding which are likely to be of some value and which should be kept is bound to be more valuable than any possible gain from deleting them. WereSpielChequers (discusscontribs) 15:11, 14 September 2020 (UTC)
@WereSpielChequers:It’s not just about redirects, you realize that only an admin can move subpages and pages in a book at a go. For a normal user, we have to move them one by one. It really becomes tedious --Synoman Barris (discusscontribs) 15:18, 14 September 2020 (UTC)
It's not something to do casually, though, and when occasionally needed an admin can help. --Pi zero (discusscontribs) 15:49, 14 September 2020 (UTC)
WikiBooks started with a dozen administrators. There are now only 8. Rather than create a new usergroup why not appoint some more admins? MrJulesd below is quite correct to note that unbundling on EN WP has led to fewer RFAs, if you appoint more trusted users as admins it spreads the load more evenly. another way of thinking of it is to ask yourself, are there people here who you would trust to move pages but not trust with the block button? WereSpielChequers (discusscontribs) 19:21, 14 September 2020 (UTC)
It's not that we get a lot of applications to begin with... Leaderboard (discusscontribs) 13:33, 15 September 2020 (UTC)
If adminship were bundled I'd be happy to learn the ropes and help out with admin work here, as I do already on en-wiki. I'm just not inclined to endure another RFA. One was enough. Anachronist (discusscontribs) 22:17, 15 September 2020 (UTC)
Wikibooks' RFA is significantly less gruesome than Wikipedia's (in fact, one could argue that being a steward is easier). Leaderboard (discusscontribs) 07:51, 16 September 2020 (UTC)
I can concur with Leaderboard. Our RFAs aren't as bad as the RFAs up at WP. I've seen the RFAs there, it's quite long and exhausting. —Atcovi (Talk - Contribs) 17:09, 8 October 2020 (UTC)
  •   Oppose I think the big problem with unbundling is that, every time you do it, you create yet another reason to oppose at RFA. Now I haven't actually seen an RFA during my time here, but I think it's obvious that it would be beneficial if it happened more often. Now at en.wp, RfA has more or less dried up, despite the huge number of editors there. And I think unbundling is one of the major contributors to that, as most tasks can now be performed by non-admins. If this did pass I would prefer option 2, and I feel it is unlikely that it would create many problems, but I can't support it at this time per my comments.--Jules (Mrjulesd) 15:58, 14 September 2020 (UTC)
  •   Support proposal two. I think that reviewers are mature enough to handle suppressing redirects, especially when they're adopting books. --Prahlad balaji (T / C) 17:41, 18 September 2020 (UTC)
  •   Support #2. Sensible. —Justin (koavf)TCM 23:42, 5 October 2020 (UTC)
  • Oppose proposal 1 - Not an entirely big fan of "copying" rights from Wikipedia, especially with proposal 2 being put on the line, which I support proposal 2. Although I understand Pi zero's input, I believe that reviewers are experienced enough to perform an action like this. On another note, we could increase the requirements if this new permission becomes an issue in the future. The frustration from the OP is evident. —Atcovi (Talk - Contribs) 17:09, 8 October 2020 (UTC)