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) – 06:18, 5 November 2019 (UTC)

Raising rollback limitEdit

Hi all, as raised at Wikibooks:Reading room/Assistance#Rollback, it seems that Mrjulesd and I occasionally run into the rate limit when using rollback. As the vandals go page hopping instead of sticking to a single page, using mass rollback is the easiest way (for me) to revert their nonsense after they are blocked. However, the rate limit forbids us to rollback after a number of edits, probably 10 edits within a 1 minute time frame. As such, I would like to propose that the rollback limit be increased from 10/min to 60/min (1 rollback/second). If the concern is that some editors might misuse rollback with a bot (as mentioned by Mrjulesd), the second best option is granting the account creator right to a use at the discretion of the admin. (Talk/留言/토론/Discussion) 06:54, 6 October 2019 (UTC)

I would support, but I took a look at the configs and you should already be at 90/min... --DannyS712 (discusscontribs) 07:05, 6 October 2019 (UTC)
@DannyS712: Unless WB isn't using the default values, I believe that is for edits only, not rollback. (Talk/留言/토론/Discussion) 07:53, 6 October 2019 (UTC)
 // Page edits
 'edit' => [
   'ip' => [ 8, 60 ],
   'newbie' => [ 8, 60 ],
   'user' => [ 90, 60 ],

... ...

 // Page rollbacks
 'rollback' => [
   'user' => [ 10, 60 ],
   'newbie' => [ 5, 120 ]
Well, I was wrong; the number I gave was for edits; the number for rollback is 100/min as a result of phab:T228708 - where are you looking for those configs? I'm in InitialiseSettings --DannyS712 (discusscontribs) 07:55, 6 October 2019 (UTC)
@DannyS712: From mw:Manual:$wgRateLimits. (Talk/留言/토론/Discussion) 07:56, 6 October 2019 (UTC)
That is the default for unconfigured mediawiki installations. On wmf sites, the defaults are --DannyS712 (discusscontribs) 07:59, 6 October 2019 (UTC)
// For expanded rollback permissions...
'rollback' => [
	'user' => [ 100, 60 ], // T228708
	'newbie' => [ 5, 120 ],
Then I can't seem to find any reason why rollback can't be used sometimes. (Talk/留言/토론/Discussion) 08:00, 6 October 2019 (UTC)
*Another approaches to solve rollbacks
If the rollback settings are limited for now, how about edit the configurations so that each IP or new user (not auto-confirmed user) edits are allowed only 1 edit per 1 minute. The root cause of this problem are due to new user/IP edits are abusing the current edit limits (which I believed are unlimited ). I believed this approach will greatly reduce the vandalism. As from what I seen so far, IP edits and also the new user edits are so far vandalizing the pages way more than constructive edits.
Also, I believed that there are no way that new user will need to edit multiple pages in one minute except perhaps for vandalism.Remember the monkey pics vandal, repeating contents vandal, blanking vandals, and now the nonsense content vandal....
Adding my two cents thought by Encik Tekateki (discusscontribs) 08:12, 6 October 2019 (UTC)
@DannyS712: Will the notice message help you out? (Talk/留言/토론/Discussion) 08:22, 6 October 2019 (UTC)
Yes, probably --DannyS712 (discusscontribs) 08:22, 6 October 2019 (UTC)
Then if possible, slot an edit into User:大诺史/sandbox‎ (Talk/留言/토론/Discussion) 08:24, 6 October 2019 (UTC)


@DannyS712:, seems to be "The action you have requested is limited to users in the group: Administrators." + sometimes, the rollback button doesn't appear. (Talk/留言/토론/Discussion) 08:38, 6 October 2019 (UTC)
@大诺史: Is there any other user group listed? --DannyS712 (discusscontribs) 08:42, 6 October 2019 (UTC)
@DannyS712: Nope. (Talk/留言/토론/Discussion) 08:43, 6 October 2019 (UTC)
Where you clicking rollback from a dif or the history page? --DannyS712 (discusscontribs) 08:45, 6 October 2019 (UTC)
@DannyS712: both + RC. (Talk/留言/토론/Discussion) 08:47, 6 October 2019 (UTC)
The problem is bigger than just rollback. See phab:T234744 and parent task --DannyS712 (discusscontribs) 09:03, 6 October 2019 (UTC)
Thanks for your input @DannyS712, 大诺史:. What I strongly suspect is that the $wgRateLimits hasn't been updated to the new WMF defaults per T228708, i.e. we are using here the old default values for $wgRateLimits as listed at mw:Manual:$wgRateLimits.
It very much feels like rollback is ratelimited here; and as only admins have the "noratelimit" right, it makes sense that admins are not affected by this "bug" (may actually be a feature) as suggested by their comments at the previous thread. To fix phab:T234744 all that may be needed is an update to LocalSettings.php to bring $wgRateLimits to the new WMF defaults.
Hopefully a sys admin will opine at phabricator, for as far as I know LocalSettings.php can't be viewed on the web interface, so we have no way of knowing for sure that this is the cause of the problem. But I am fairly certain by my editing that some sort of rate limit is being applied to my use of rollback, as if I wait for a period of time the rollback becomes operational again. --Jules (Mrjulesd) 10:53, 6 October 2019 (UTC)


@DannyS712: Based on my observation, the autopromotion might have some issues too. Encik Tekateki & Hasley should have been auto promoted by now. + I had to request reviewer rights from Pi zero, and Mrjulesd was manually promoted by QuiteUnusual too.

However, I suspect that this has little to do with any software issues but rather having this criteria "5 or more edits are in recent changes at the time automatic reviewer promotion is checked." which delays the auto promotion due to the spam. (Talk/留言/토론/Discussion) 14:01, 6 October 2019 (UTC)
Well its not perfect how autopromotion works. But its not much of an issue as rights can be requested or given instead. Encik Tekateki & Hasley should request the right if they fulfill the criteria (I haven't checked myself) and want it. --Jules (Mrjulesd) 20:01, 6 October 2019 (UTC)

Export to Pdf, Epub, Odt, LaTeXEdit


I think Wikibooks needs a function to export the the formats Pdf, Epub, Odt and LaTeX.

I suggest to add a new link to the toolbar on the left in the in the section Tools. It shall be labeled Multi format export. I shall link to and fill the form field URL on the page with the current page viewed by the user on the wiki.

You may try this out yourself just now by copying User:Dirk_Hünniger/common.js to common.js in your user namespace.

If this proposal get generally approved I would ask an admin to edit MediaWiki:Common.js accordingly, so that the link will appear for everyone automatically.

I am not sure if the servers on wmflabs will be able to stand the load, if MediaWiki:Common.js get modified, but we will see by then.

Yours --Dirk Hünniger (discusscontribs) 15:28, 30 November 2019 (UTC)

Thanks, it's a bit slow but it could be worth it. JackPotte (discusscontribs) 19:23, 30 November 2019 (UTC)
@Dirk Hünniger, JackPotte: This is a good thing to list at m:Community Wishlist Survey 2020/Wikibooks. Note that m:Community Wishlist Survey 2020/Wikibooks/EPUB generation exists. —Justin (koavf)TCM 20:32, 30 November 2019 (UTC)

This has been deployed on the German Wikibooks now. See b:de:Hauptseite links "Multi Format Export" in the sidebar on the left. Just let me know, if you are interested in deploying it on the English Wikibooks as well. --Dirk Hünniger (discusscontribs) 06:12, 21 December 2019 (UTC)

This has also been deployed on the German Wikiversity and Wikisource. --Dirk Hünniger (discusscontribs) 18:15, 5 January 2020 (UTC)

  Comment I've got no particular view on this being added. But I do have a couple of queries about its usage:
  1. Although I've added the code to my common.js, the addition of the "Multi format export" sidebar link seems very inconsistent. For example, I get the link on this very page (i.e. Wikibooks:Reading room/Proposals). But if I go to e.g. Algorithms/Print version or Anatomy and Physiology of Animals/Print version the link fails to materialize. I don't know if this is an issue with my system at all. Addendum: actually I have got it to come up on Algorithms/Print version now through reloading at least sometimes. But if fails on the other book. So its seems a bit inconsistent for some reason. But perhaps my system. --Jules (Mrjulesd) 21:06, 5 January 2020 (UTC)
  2. I have attempted to use the tool, and I have a continual problem with it: paragraph breaks repeatedly fail to render. I don't know if it is me doing something wrong, but nevertheless it is a repeating problem for me, which is a shame as otherwise the output seems to be of very high quality.
Any comments on either of these issues? --Jules (Mrjulesd) 20:59, 5 January 2020 (UTC)

I think concening issue 1 you got a browser cache problem. Your browser show an old version of the sidebar from your hard drive. In Firefox you may need to click "reload button" while holding down the SHIFT button on the keyboard (second to left of backwards button). You will need to do this once for every page. On 2) Yes paragraph breaks are omitted. I am not sure if I will implement it since it might have unwanted effects on other parts cause "there is no line here to end" errors in LaTeX. You could possibly work around that by inserting br html tags in the wiki code of the page you wish to render. --Dirk Hünniger (discusscontribs) 22:04, 6 January 2020 (UTC)


I deployed something to resolve issue 2 on the server I tryed with Anatomy and Physiology of Animals/The Skin and could see that in worked look at section "The Dermis"

Yours --Dirk Hünniger (discusscontribs) 23:01, 6 January 2020 (UTC)

Hi Dirk Hünniger thanks for your replies.
  1. Yes that did help to bring it up. What's weird though is that I then reloaded the page again and it failed to materialize! But if I do shift reload each time it comes up, but if I just reload it doesn't. But I expect it might be connected with the MediaWiki installation here, I've noticed a few strange things going on here and there, so I wasn't too surprised. Maybe also my browser.
  2. Thanks for looking into that, it makes it a far more useful tool if it renders paragraph breaks. I will experiment with it later on and get back to you if I have any further problems.
Thanks again, --Jules (Mrjulesd) 02:12, 7 January 2020 (UTC)