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


Fellow administrators, I plan to replace the current MassBlock gadget with this version imported from the Italian Wikipedia. Currently on this project, MassBlock only blocks IP addresses, which are no longer visible to the public and it's not ideal. Thoughts? Codename Noreste (discusscontribs) 23:27, 29 October 2025 (UTC)Reply

In principle, I have no problem with this, but I'm not as familiar with the technical aspects or potential limitations—I'd need other people to weigh in. Cheers —Kittycataclysm (discusscontribs) 16:07, 2 November 2025 (UTC)Reply
I've tested this, and there are some additional options to blank and/or protect user/user talk pages, but we should probably not use them unless absolutely necessary. Codename Noreste (discusscontribs) 15:28, 7 November 2025 (UTC)Reply
 Doing per lack of objection... Codename Noreste (discusscontribs) 01:00, 2 January 2026 (UTC)Reply
Apologies for the recent technical difficulties, the script wasn't working because some dependencies were not added... – it's fixed. Codename Noreste (discusscontribs) 20:28, 2 January 2026 (UTC)Reply

Recently, protected page-related system messages were replaced with {{protected page text}} or {{protected interface}}, modelled off of Wikipedia’s templates. Even before these templates were used to replace those MediaWiki messages, we still had system messages modelled after Wikipedia’s templates: {{no article text}}. I also wanted to have a go at encouraging reuse of code, and this would be a revamp of block-related system messages. We would also only have to write the code once, not multiple times—once for each system message (keep in mind, some of the system messages below have not yet been edited). The system messages that would have to be replaced are:

If you have any ideas for tweaks to {{Blocked text}}, your input would be much appreciated. Thanks, 2600 etc (discusscontribs) 23:49, 17 November 2025 (UTC)Reply

This seems reasonable. Codename Noreste (discusscontribs) 01:49, 31 December 2025 (UTC)Reply

I've noticed Using Wikibooks, and I'm a little concerned that it might be confusing to have a separate book instead of official pages in the Help: and Wikibooks: namespaces. To my mind, having a separate book introduces the following issues:

  • Confusion of the book with official project policy
  • Outdated information or other discrepancies if the official pages are updated and the book is not

The book does have a good amount of useful information, so I think it would make the most sense to merge it into official pages in the Wikibooks: and Help: namespaces. Thoughts? —Kittycataclysm (discusscontribs) 14:14, 26 November 2025 (UTC)Reply

How can we tell which pages (from that book) should either be in the Wikibooks or Help namespaces? Codename Noreste (discusscontribs) 15:44, 26 November 2025 (UTC)Reply
I think it's not necessarily a one-to-one. Rather, we'll need to find the best home(s) for the information on each page—it's something I'm happy to take point on! Is that what you were asking? —Kittycataclysm (discusscontribs) 23:57, 26 November 2025 (UTC)Reply
Probably. Codename Noreste (discusscontribs) 00:38, 27 November 2025 (UTC)Reply
I'll wait to see if anyone else has any comments about this; if there are no objections, I'll plan to migrate things as described. —Kittycataclysm (discusscontribs) 20:45, 2 December 2025 (UTC)Reply
@Codename Noreste and @Kittycataclysm: I do object to this change, for two reasons.
  1. Using Wikibooks is a featured book. By moving it to another namespace, it will no longer be a book, and thus no longer a featured book. Do we intend to delist it?
  2. Using Wikibooks is a book. It is written in the same style as other books in our project's mainspace. It's self-consistent and organized by page. I fear that dividing and conquering it among the Help and Project namespaces is likely to make its content harder to find.
JJPMaster (she/they) 01:15, 5 December 2025 (UTC)Reply
I changed my vote, I don't think we should migrate that book to pages in other namespaces. Codename Noreste (discusscontribs) 03:46, 5 December 2025 (UTC)Reply
That is an "official" book, which I think is OK to have in this case. I think some of the help pages actually recommend reading this book. Leaderboard (discusscontribs) 07:41, 1 January 2026 (UTC)Reply

After discussing with Izno off-wiki, I have some suggestions to improve the interface of this project's Main Page (e.g. to be portal-like) using some steps below:

.page-Main_Page #deleteconfirm,
.page-Main_Page #t-cite,
.page-Main_Page #footer-info-lastmod,
.action-view.page-Main_Page #contentSub,
.action-view.page-Main_Page #contentSub2 {
	display: none !important;
}
.page-Main_Page #deleteconfirm,
.page-Main_Page #t-cite,
.page-Main_Page #lastmod,
.action-view.page-Main_Page #contentSub {
	display: none !important;
}
.page-Main_Page #deleteconfirm,
.page-Main_Page #t-cite,
.page-Main_Page #footer-info-lastmod,
.action-view.page-Main_Page #contentSub {
	display: none !important;
}

Let me know if you have comments, questions, or concerns. Codename Noreste (discusscontribs) 18:04, 2 December 2025 (UTC)Reply

Is there a "demo" version previewing what effects these changes will have? JCrue (discusscontribs) 15:05, 4 December 2025 (UTC)Reply
This will basically remove the Main Page title and the gray line below it (but above the page tabs) in most appearance skins. You might want to see this user talk page thread on English Wiktionary for context. Codename Noreste (discusscontribs) 15:35, 4 December 2025 (UTC)Reply
 Doing per lack of objection... Codename Noreste (discusscontribs) 02:28, 31 December 2025 (UTC)Reply
Done. Codename Noreste (discusscontribs) 02:53, 31 December 2025 (UTC)Reply

The list of new books is overflowing. It lists them in alphabetical order, not the order in which they were made. Currently, only books that start with punctuation (.NET Development Foundation) up to Conphilosophy are covered. Under the Want to help? section it states, "If this list gets too large, such as having over 25 books on it, categorize some of the books on the end of the list and remove the {\{new book}} template." We would either need to have people stay on task for this page, change it so it updates by creation date versus the first title character, or delete it entirely. Otherwise this page is useless or will encourage odd naming choices. ValWinter (discusscontribs) 03:46, 25 December 2025 (UTC)Reply

Thank you for the flag! The information on this page actually seems to be deprecated, and I don't think the page is necessary to keep. The new book template actually adds pages to Category:New books, and many of the books listed on the page actually do not feature the new book template. I think it may make sense to delete this page. —Kittycataclysm (discusscontribs) 01:20, 26 December 2025 (UTC)Reply
Ok yes, deleting would be best in this case. Thank you for looking into this page! ValWinter (discusscontribs) 02:31, 26 December 2025 (UTC)Reply

{{Deleted page}} is a template that was used back in the day before salting (page creation protection) existed. Back then, if an admin wanted to prevent a page from being recreated, they would delete it and then recreate it with just that template, before fully protecting it. This method is completely unnecessary now that we can directly create-protect pages, and no new page has been added to Category:Protected deleted pages in nearly eight years.

Furthermore, I would like to propose that all the pages that currently have {{Naming policy notice}} be deleted and added to the title blacklist. In the title blacklist, the error message should be set to an interface message that transcludes {{Naming policy notice}}. Since this is an editor-facing template, only would-be editors should be able to see it. JJPMaster (she/they) 22:55, 31 December 2025 (UTC)Reply

Do you think we should delete {{Deleted page}} via RfD, but keep {{Naming policy notice}}? Codename Noreste (discusscontribs) 23:04, 31 December 2025 (UTC)Reply
@Codename Noreste: Yes. {{Deleted page}} should be deleted, and {{Naming policy notice}} should be fully protected and transcluded in a MediaWiki namespace message. JJPMaster (she/they) 23:16, 31 December 2025 (UTC)Reply
Considering there were no objections to this proposal here,  I am doing this... Codename Noreste (discusscontribs) 01:44, 30 March 2026 (UTC)Reply
All done, but the discussion about {{Deleted page}} is awaiting to be closed (since I initiated it). Codename Noreste (discusscontribs) 02:37, 30 March 2026 (UTC)Reply
JJPMaster, I filed a request at Wikibooks:Requests for deletion#Template:Deleted page to discuss whether to delete this template (and the categories used). Codename Noreste (discusscontribs) 15:38, 29 January 2026 (UTC)Reply

I would like to propose the following below:

We split off Wikibooks:Requests for adminship as a separate page for requesting adminship, bureaucrat, checkuser and suppressor (oversight) permissions. All other permissions, except the former mentioned permissions, would still be requested at Wikibooks:Requests for permissions (this is also the case for requesting interface administrator permissions, for admins).

Given the low activity on this project, I propose that we must notify the community about ongoing RFAs, which could be either MediaWiki:Sitenotice or adding a notification at Wikibooks:Reading room/General. A general rule is that the notification must be written in a neutral fashion.

Feel free to comment, ask, or anything else. Thanks. Codename Noreste (discusscontribs) 02:31, 1 January 2026 (UTC)Reply

1. I don't see WB:RFP being clogged to justify creating a fork just for advanced permissions.
2. That is already something we do occasionally on a case-by-case basis. Leaderboard (discusscontribs) 07:40, 1 January 2026 (UTC)Reply
My thoughts below:
  1. I agree with @Leaderboard and don't really see a need for splitting off Wikibooks:Requests for adminship as a separate page, since there are generally not so many requests.
  2. I do think it could potentially be useful to notify the community about requests for adminship using MediaWiki:Sitenotice—it's not something I've seen us do before. @Codename Noreste are you proposing specifically that we codify it in policy?
Kittycataclysm (discusscontribs) 16:59, 1 January 2026 (UTC)Reply
After considering, I've crossed out proposal 1, and regarding proposal 2, I would still think it should be in a guideline, not a policy. Codename Noreste (discusscontribs) 18:22, 1 January 2026 (UTC)Reply
Proposal 2 seems reasonable to me. It could help people find requests if they are not watching RFP. Ternera (discusscontribs) 15:01, 2 January 2026 (UTC)Reply
I've been thinking about proposal 2, and it seems like it would be a good idea to create a template for this purpose that we could just pop into MediaWiki:Sitenotice. What about creating Template:RFA notice, which could take as parameters the requestor and the path to the discussion? —Kittycataclysm (discusscontribs) 15:35, 24 January 2026 (UTC)Reply
I agree. Codename Noreste (discusscontribs) 17:12, 27 January 2026 (UTC)Reply

The following discussion has concluded. Please open a new discussion for any further comments.

The Phabricator task has been resolved, and VE is enabled on the proposed namespaces as of today. Codename Noreste (discusscontribs) 17:06, 27 January 2026 (UTC)

See the original discussion for reference.

Currently, the visual editor is implemented on the following namespaces:

  • Main
  • User
  • Help
  • Category
  • Cookbook
  • Wikijunior

I am proposing that we implement the visual editor on the following namespaces:

I use the source editor and the visual editor for different purposes. One of my primary uses of the visual editor is for text-heavy pages, where I use it for writing content and proofreading/copyediting. In contrast, I use the source editor for more complex and technical edits. I find it very difficult to parse text in the source editor, especially when there are many templates, tables, links, etc, and it is a pretty significant accessibility issue for me—I imagine that it could be so for other users as well.

The Wikibooks and Transwiki namespaces are both namespaces that contain text- and content-heavy pages (e.g. policies, guidelines, essays), and I know I would benefit from the visual editor here—for example, I am currently working on the unstable branch of a policy, and it is proving to be kind of a pain to do without having the visual editor as an adjunct tool.

The main challenge I see is that the Wikibooks namespace contains some talk pages (i.e. the reading room), and the visual editor is not intended for talk pages. However, there is precedent for implementing the visual editor in namespaces that contain talk pages as long as it is understood that the visual editor is not intended for these talk pages. Overall, it looks technically feasible.

Kittycataclysm (discusscontribs) 16:40, 11 January 2026 (UTC)

Kicking off the discussion here! —Kittycataclysm (discusscontribs) 15:37, 24 January 2026 (UTC)

Pinging people who were part of the original discussion thread: @Leaderboard @Codename Noreste @SHB2000.
Also pinging some other active administrators: @JJPMaster @MarcGarver @Atcovi @Xania @JackPotte @TunnelESON. Thanks! —Kittycataclysm (discusscontribs) 15:48, 24 January 2026 (UTC)
No objections. JJPMaster (she/they) 16:30, 24 January 2026 (UTC)
I'm fine as well. Leaderboard (discusscontribs) 17:04, 24 January 2026 (UTC)
Ditto. --SHB2000 (discusscontribs) 22:49, 24 January 2026 (UTC)
All good on my end. —Atcovi (Talk - Contribs) 17:09, 25 January 2026 (UTC)
Phab ticket has been created at T415595! —Kittycataclysm (discusscontribs) 21:49, 26 January 2026 (UTC)

Hi. I would like to propose that we redefine the inactivity policy for administrators (superseding the current procedure), and to create a local inactivity policy for bots.

  • For administrators that have made zero edits and zero logged actions for over a year, they will be listed under the removal section of Wikibooks:Requests for permissions (and notified on their user talk pages), where they are given a specific timeframe to respond so that they can retain their access, unless they specify otherwise. If they do not respond after that timeframe, a request will be forwarded to the removal section of m:SRP. Should the timeframe last at least one week, two weeks, or one month?
  • For bots, the process is slightly different. Bots that are inactive (made no edits/logged actions) for over two years will be listed under the removal section of RfP (in the same manner as inactive administrators), but their operators must be notified first, and a week is given for the operators to respond. After the timeframe passes and an operator does not respond to the inactive bot removal request (for example), a request will be forwarded to the removal section of m:SRB. Bot users that do not have the bot user group might be exempt, unless the discussion proposes otherwise.

Thanks. Codename Noreste (discusscontribs) 20:34, 18 January 2026 (UTC)Reply

Sounds fine to me. Leaderboard (discusscontribs) 06:58, 21 January 2026 (UTC)Reply
Agreed here. --SHB2000 (discusscontribs) 00:36, 25 January 2026 (UTC)Reply
I have no problem with this. Regarding the timeframe for administrators, one months seems reasonable. Thanks! —Kittycataclysm (discusscontribs) 15:29, 24 January 2026 (UTC)Reply
I think one month might be excessive IMO, but one week might not be enough for a timeframe, especially given the lack of discussion activity. Let’s compromise by choosing two weeks instead, if that's okay.
Also, the reason I made this is because the inactivity policy on Wikibooks:Administrators seems vague. Codename Noreste (discusscontribs) 16:15, 24 January 2026 (UTC)Reply
@Kittycataclysm, what timeframe would be feasible, two weeks, or one month? I'll be ready to implement this today. Codename Noreste (discusscontribs) 16:20, 30 January 2026 (UTC)Reply
Two weeks should probably be fine unless anyone else has thoughts! —Kittycataclysm (discusscontribs) 02:55, 31 January 2026 (UTC)Reply
Kittycataclysm, I am reconsidering the current timeframe. I think we should revise by lowering the timeframe to one week for administrator inactivity removal, similar to how we currently do this for bots. Codename Noreste (discusscontribs) 17:17, 10 February 2026 (UTC)Reply
I think we should check to see what other people think here —Kittycataclysm (discusscontribs) 17:49, 10 February 2026 (UTC)Reply
I'm afraid I don't fully understand the procedure you're proposing for administrators. When someone is listed to be removed on RFP, is there a vote? Or is the poster just waiting for the inactive admin to reply? JJPMaster (she/they) 16:31, 24 January 2026 (UTC)Reply
In my new proposal, there will be no votes for removal, but inactive admins will be notified and given a timeframe to respond if they wish to retain their rights, unless they specify otherwise. Codename Noreste (discusscontribs) 17:42, 24 January 2026 (UTC)Reply
Implemented. Codename Noreste (discusscontribs) 20:51, 31 January 2026 (UTC)Reply
Should I reduce the timeframe from two weeks down to one week? Codename Noreste (discusscontribs) 04:55, 22 February 2026 (UTC)Reply

I am new to Wikibooks, if this already exists let me know....

If there was a Wikibook "file" that contained all the templates and "parts" that are used to create a properly structured book, it might be easier and quicker to create and contribute books here. This would have to include text that would explain the purpose of each of the sections and templates and offer advice for making changes that customize the example.

One might copy it to their sandbox, follow the directions and make the updates that create the framework for their book. Then the work would be to fill in the text. I suppose the downside is that books would be categorized and shelved that are in progress. Abandoned books would need to be deleted or some template might need to be developed that might indicate that the book is incomplete. This would be removed when the book is ready for prime-time. — Preceding unsigned comment added by Rchaswms01 (talkcontribs) 01:32, 3 February 2026 (UTC)Reply

Hello, everyone. I would like to propose allowing all users to view not just edit filters and their log, but also detailed edit filter log entries. In addition to that, I am also proposing that we set $wgAbuseFilterNotifications to true by removing $wgAbuseFilterNotifications = false;.

We would like to enable the AbuseFilter extension (see below) with custom permissions. Please *add*:

$wgGroupPermissions['*']['abusefilter-view'] = false;
$wgGroupPermissions['*']['abusefilter-log'] = false;
$wgGroupPermissions['autoconfirmed']['abusefilter-view'] = true;
$wgGroupPermissions['autoconfirmed']['abusefilter-log'] = true;
I'm sorry for yet another reply, but the user rights for the abuse filter need to be tweaked to match the request.

abusefilter-view should be for autoconfirmed/confirmed only and not for all users.

abusefilter-log should be for autoconfirmed/confirmed only and not for all users.

The logic behind this was to prevent casual vandals from gaming the system.

Thank you for your efforts.
case 'enwikibooks':
	$wgGroupPermissions['*']['abusefilter-view'] = false;
	$wgGroupPermissions['*']['abusefilter-log'] = false;
	$wgAbuseFilterNotifications = false;
	$wgGroupPermissions['autoconfirmed']['abusefilter-view'] = true;
	$wgGroupPermissions['autoconfirmed']['abusefilter-log'] = true;
	$wgGroupPermissions['autoconfirmed']['abusefilter-log-detail'] = true; // T383332
	$wgGroupPermissions['sysop']['abusefilter-revert'] = true; // T411828
	$wgAbuseFilterActions['block'] = true; // T273864
	break;
case 'enwikibooks':
	$wgGroupPermissions['*']['abusefilter-log-detail'] = true;
	$wgGroupPermissions['sysop']['abusefilter-revert'] = true; // T411828
	$wgAbuseFilterActions['block'] = true; // T273864
	break;

Thoughts? Codename Noreste (discusscontribs) 18:55, 2 April 2026 (UTC)Reply

See also: Wikibooks:Reading room/Proposals/2025/January § Reforming the edit filter. JJPMaster (she/they) 22:50, 2 April 2026 (UTC)Reply

I would like to propose that we introduce speedy deletion criteria to Wikibooks, such as G1: [reason]. I suggest that we adapt from the English Wikipedia's CSD criteria (w:Wikipedia:Speedy deletion) but utilize our existing deletion reasons, and even include G for general, R for redirects, and so on.

Speedy deletion reasons are already included in the deletion policy, but should this proposal pass, the new speedy deletion criteria can be split out to a separate policy page, if needed (e.g. Wikibooks:Speedy deletion).

Thoughts? Codename Noreste (discusscontribs) 14:39, 7 April 2026 (UTC)Reply

On the whole, that seems like it could be useful to expand out our CSD in a more detailed way. Why don't you go ahead and create Wikibooks:Speedy deletion as a draft, write out your initial proposal, and then we can workshop it together? —Kittycataclysm (discusscontribs) 15:33, 10 April 2026 (UTC)Reply
@Codename Noreste: How can this proposal avoid accusations of instruction creep? JJPMaster (she/they) 23:21, 14 April 2026 (UTC)Reply
How does instruction creep have anything to do with this? Codename Noreste (discusscontribs) 23:31, 14 April 2026 (UTC)Reply
Well, in that case, we might keep the descriptions simple, not overly detailed. Codename Noreste (discusscontribs) 02:30, 17 April 2026 (UTC)Reply
In that case, we may need to introduce that motion. – RestoreAccess111 Talk! Watch! 04:38, 17 April 2026 (UTC)Reply
We already have speedy deletion though so I don't understand this proposal. Leaderboard (discusscontribs) 15:56, 24 April 2026 (UTC)Reply