< Wikibooks:Reading room
ArchivesWikibooks Discussion Rooms
DiscussionsAssistanceRequests
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 Stacks

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 (discuss • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 04:03, 11 October 2018 (UTC)
I think I've got the department featured books problem fixed. --Pi zero (discuss • contribs) 06:43, 12 October 2018 (UTC)
I've improved both of those displays on the departments page. --Pi zero (discuss • contribs) 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 (discuss • contribs) 13:28, 22 January 2019 (UTC)
Still mired. --Pi zero (discuss • contribs) 21:14, 8 April 2019 (UTC) – 14:33, 5 January 2021 (UTC)

Proposal: add features that support ebook writers better

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 (discuss • contribs) 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)❤T☮C☺M☯ 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 (discuss • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 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)❤T☮C☺M☯ 19:37, 22 April 2020 (UTC)
Thank you Justin, that is very helpful. JimKillock (discuss • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 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 www.mediawiki.org 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 "MediaWiki.org 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 (discuss • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 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 (talk • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 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 (discuss • contribs) 12:16, 9 August 2020 (UTC)
/me hopes to take a close look at this tomorrow. --Pi zero (discuss • contribs) 00:34, 10 August 2020 (UTC)
@Pi zero: quick mention in case you have time to take another look! JimKillock (discuss • contribs) 06:55, 22 October 2020 (UTC)

Suppress redirect feature

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

Repost: add features that support ebook writers better

@Koavf: @Pi zero: I am reposting this proposal as the discussion got very long. It was to use Wikisource templating with:

  • 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

I have added the details to:

  • User:JimKillock/Migrating ebook features

Where I will try to pull out the main points later.

I am very willing to have a go at some of this, if it is mostly migration of content as opposed to figuring out too much. With that in mind, I also had an idea to try this on Latin Wikibooks, as the content I want to create is mostly Latin-English texts. That could be simpler also as the project looks relatively undeveloped. JimKillock (discuss • contribs) 08:56, 2 November 2020 (UTC)

For what it's worth, I don't have access to the tools to import templates, etc. here on Wikibooks. I do support the idea of having better control of print-worthy copies of our material here but there's not a lot that I can do to actualize it. —Justin (koavf)❤T☮C☺M☯ 09:05, 2 November 2020 (UTC)
Thank you! I am not sure how Latin wikibooks works with admin requests, but I imagine that whoever has the admin rights would be ok with us running through what is required there, so long as whoever is implementing it has sufficient technical skill. Perhaps a few of us could be granted rights and run through the process to get more familiar with it? JimKillock (discuss • contribs) 10:23, 2 November 2020 (UTC)
The situation at Latin wikibooks seems to be that there are currently no admins, so it is quite a moribund project. I can apply for adminship, but I wonder if this might be best done by someone here, or with somebody else's help? I will certainly need help to try all this out. @Koavf: @Pi zero: would either of you be willing to help me get this going? JimKillock (discuss • contribs) 19:54, 3 November 2020 (UTC)
@JimKillock: You may want to ask a steward (which I am not). —Justin (koavf)❤T☮C☺M☯ 20:14, 3 November 2020 (UTC)
@Koavf: Thanks, yes I can do that. Still it feels a bit wrong for me to take this on without help or admin experience. JimKillock (discuss • contribs) 21:43, 3 November 2020 (UTC)
@Koavf: @Pi zero: I was asked on la:Vicilibri:Porta_communis#Administrator_request by UV whether asking Wikimedia to implement the Wikisource features as a MediaWiki Extension would make sense. Can you let me know your thoughts, and if it is worthwhile, perhaps we can raise it (in whatever the relevant forum is). JimKillock (discuss • contribs) 10:11, 8 November 2020 (UTC)
I think that could make sense. —Justin (koavf)❤T☮C☺M☯ 21:40, 8 November 2020 (UTC)
@Koavf: @Pi zero: So the advice so far from Wikisource is that the templates are easy enough, but what gets complicated are the multiple layouts, which are done via Javascripts. They say the way to implement this is via creating a "gadget" with the relevant scripts, pulled out of their existing JS and CSS. If that is right, then it ought to be fairly simple to implement on Wikibooks? As I mentioned with a bit of help I would be very willing to help trial this on la.wikibooks if that helps also. JimKillock (discuss • contribs) 13:51, 14 November 2020 (UTC)
Gadgets are more complicated but I think that using la.wb as a kind of proving ground is a good strategy. —Justin (koavf)❤T☮C☺M☯ 19:02, 14 November 2020 (UTC)
Further point: it has been pointed out to me by UV@la.wikibooks that if page layouts are editor chosen, then the whole JS issue goes away, and the pages layout changes can be applied via a template. if that is the case, then this should all be a lot simpler, @Pi zero:? JimKillock (discuss • contribs) 11:50, 15 November 2020 (UTC)
here is another use case for these features. Someone on this Wiki wants to annotate a Wikisource book, has copied it across to Economic Sophisms, porting the content, and thereby wants the templating features. JimKillock (discuss • contribs) 16:06, 18 November 2020 (UTC)

OK, now we are getting somewhere, albeit you may have a suggestion of a better way to do this. I have two templates, to open and close the divs which make the column, and a style sheet attached to the first.

The styles don't seem to be working out the serif fonts yet, but it is a while since I did CSS so I may be able to fix this.

The main question I have is: is there a better way to open and close the wrapper divs than using two separate templates, one to open them, and the other to close them? JimKillock (discuss • contribs) 15:05, 21 November 2020 (UTC)

@Koavf: @Pi zero: I have the narrow columns plus text size templates working at Economic Sophisms and also at la:Usor:JimKillock/Formulae. I'll enquire about using the ebook exports (WSExport) next.
I am not happy about using two templates, one to open divs at Template:NarrowColumn and the other at Template:NarrowColumnEnd to close them. Do either of you have a better way to do this? JimKillock (discuss • contribs) 18:36, 26 November 2020 (UTC)
@JimKillock: The only other approach that occurs to me atm is to have a single template call that takes as a parameter all the stuff that goes between the start and end of the div. That way, the simple template can generate start and end and all between. The wiki syntax for that isn't wonderful, but then, the wiki syntax for using two separate templates was already not entirely pleasing either. --Pi zero (discuss • contribs) 19:11, 26 November 2020 (UTC)
Thanks @Pi zero: I have got that to work copying from another simple template. JimKillock (discuss • contribs) 20:23, 26 November 2020 (UTC)

You know what I just remembered: the Community Wishlist Survey 2021 recently opened. This is an opportunity for you to present an idea to the community to vote on the priorities of the developers. —Justin (koavf)❤T☮C☺M☯ 20:49, 26 November 2020 (UTC)

Proposal to remove WSExport support for ebook export from Wikibooks

There is a ticket on Phabricator to remove Wikibooks ebook export from WSExport. I can see why this has been raised – most Wikibooks are probably not easily exported to ebooks and the formatting could work very badly in many cases. I've suggested that it may be better to enable (or disable) export per book, depending on whether the Wikibook is going to export well or not. But I though best to mention. JimKillock (discuss • contribs) 22:14, 27 November 2020 (UTC)

Automatically credit images.

"Note that many "free" images require an attribution to their authors. In online wikibooks this requirement is fulfilled by the link from each image to its description page. In printed books, however, you have to add an explicit attribution for these images." - Help:Print versions

Is it possible to automate this process in the footer/references section? This would really help with maintainability of print versions.

Mbrickn (discuss • contribs) 07:43, 5 December 2020 (UTC)

Do we really need FlaggedRevs?

I know that's kind of a "central" part of Wikibooks, but for mainspace articles, I'm seeing it as unnecessary. The reason is that by default, we set mainpage articles to show the latest revision by default, which means that there isn't any benefit for the average user. The exception is for the Wikijunior namespace, where we set the default version as the last reviewed one, and I think FlaggedRevs is useful there.

My proposal would hence be to discontinue use of FlaggedRevs on the mainspace - I don't see it as a particularly useful benefit here and personally only causes unnecessary overhead. Leaderboard (discuss • contribs) 11:24, 23 January 2021 (UTC)

Keeping it is highly desirable imho, yes. There's a vast amount of sorting-out-of-what-isn't-vandalism contained in the revision state of pages. The information expressed by a review of a single revision of a page would be difficult to reproduce (the judgments involved are highly context-dependent, so one has to immerse oneself in the specific situation-as-was to figure one what was going on), and when you multiply that by the number of pages involved the cumulative value is staggering. --Pi zero (discuss • contribs) 14:11, 23 January 2021 (UTC)

Help:Contents update

Hi, I've made a major update to Help:Contents. I've been bold and updated the page already, but if I get any strong objections I'll revert pending discussions.

Anyway its like creating a "one stop shop" on help and project pages, as it contains a good many. It also should contain all the basics on using Wikibooks, whether you want to read books or contributed.

Technical details: although the content is my own, the design is based upon wikipedia:Help:Contents. It uses CSS for two columns; it also uses CSS flexbox, which means it should render as a single column on low resolution screens such as smartphones. On obsolete browsers not supporting flexbox it will still render, although it could be a single column.

Anyway, any feedback would be nice. --Jules (Mrjulesd) 22:29, 29 January 2021 (UTC)

Great work! I don't see any issues with it and it does look more appealing than previous versions. —Atcovi (Talk - Contribs) 23:15, 29 January 2021 (UTC)
I concur, this is a nice update from before. Didn't even know that this page existed. Leaderboard (discuss • contribs) 07:59, 30 January 2021 (UTC)
This article is issued from Wikibooks. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.