ArchivesWikibooks 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 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:27, 23 March 2020 (UTC)

Export to Pdf, Epub, Odt, LaTeX

Hi,

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 https://mediawiki2latex.wmflabs.org/ 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 (discuss • contribs) 15:28, 30 November 2019 (UTC)

Thanks, it's a bit slow but it could be worth it. JackPotte (discuss • contribs) 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)❤T☮C☺M☯ 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 (discuss • contribs) 06:12, 21 December 2019 (UTC)

This has also been deployed on the German Wikiversity and Wikisource. --Dirk Hünniger (discuss • contribs) 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 (discuss • contribs) 22:04, 6 January 2020 (UTC)

Hi,

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 (discuss • contribs) 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)

I'd like an .epub export facility for sure. I'm not sure about the paragraph break issue but it seems to work well on Wikisource .en / .la for me. JimKillock (discuss • contribs) 22:25, 24 February 2020 (UTC)

Using Wikisource, they seem to have a working ePub export, can that be applied here? JimKillock (discuss • contribs) 13:16, 29 February 2020 (UTC)

JimKillock you could use this link: https://mediawiki2latex.wmflabs.org/ . Remember to fill in the full url of the page (which should be a print version), and change the output format to EPUB. There is more info at Help:Print versions which may be helpful. --Jules (Mrjulesd) 16:46, 29 February 2020 (UTC)

too late. add export to text file too. it would be tough to handle, say math formulas, but should put less load than a optimized pdf. Retow324 (discuss • contribs) 01:14, 2 April 2020 (UTC)

Much runtime is spend on finding the proper list of contributors as well as the authors of the images, this would still be needed even if I did a plain text export and did the images as ascii art. But I doubt many users will be happy with that. --Dirk Hünniger (discuss • contribs) 15:04, 4 April 2020 (UTC)

Wikibooks:Maintenance

I have long felt the usefulness of page Wikibooks:Maintenance is limited by the fact that, although it lists lots of kinds of tasks one might undertake, it doesn't actively tell you which of those sorts of tasks actually has a queue of items waiting to be taken care of; to find that out you'd have to check them all one-at-a-time. A different approach is used at en.wn, where a template called (for partly historical reasons) {{votings/sorted}} lists all the task-queues that are non-empty, and how long each queue is. (Actually it's more sophisticated than that: the queues are sorted into three sets listed on separate lines according to theme (news production, community discussions, admin tasks); most of the empty queues are also listed but moved to the end of the list and greyed out; and some of the queues when nonempty are shaded in various colors to draw attention to them.)

I'm thinking we might enhance the usefulness of Wikibooks:Maintenance by adding some such dynamic list up at/near the top. --Pi zero (discuss • contribs) 15:55, 4 February 2020 (UTC)

Hi Pi zero well yes that sounds like a definite improvement. I'd be interested to see what you could come up with. --Jules (Mrjulesd) 12:31, 5 February 2020 (UTC)

I've been thinking about how this might be done. Some queue sizes can be determined using magic word PAGESINCATEGORY, but others have no associated category. Such as Special:Uncategorizedpages. I was hoping to parse its contents using {{evalx}}, but the wiki platform does not allow these special pages to be transcluded. --Pi zero (discuss • contribs) 13:23, 5 February 2020 (UTC)

What about trying Extension:Translate?

Hello everybody!

Two years ago I discovered an interesting discussion about the creation of a multilingual version of Wikibooks opened in the 2007 (meta:Requests for new languages/Wikibooks Multilingual). I think that the idea was great, but to be honest I think that they were too in advance with the times and without the needed MediaWiki features, and so I understand how much scaring would be, with the risk of duplicating efforts without too much pratical differentiations between these editions. Anyway there is not enough interest in starting another "multilanguage" version of Wikibooks.

Anyway now we have seen the success stories of sites like the MediaWiki wiki after the adoption of the mw:Extension:Translate.

For those who don't know, the "Mediawiki wiki" hosts a vibrant community of users and developers who aim to provide a well-written documentation about MediaWiki, and MediaWiki-related software, providing this documentation in multiple languages. Without the extension Translate, this purpose would be so much complex. Why? Because MediaWiki is so rich of features and continuously evolving, and its difficult to keep the related documentation in sync with the changes.

Who love software documentation feel the pain of propagating an information in all the languages, without a tool like the Extension:Translate.

"Accessibility" and "internationalization" are somehow not much strictly related to the purpose of "cultural differentiations". I mean: it's great having 120+ Wikibooks editions with their own cultural freedom, but what about having a place where some kind of books can be just written in a language (maybe English?) and then made accessible in 303+ languages (and dialects, who knows?).

Now creating technical books and documentation is difficult and frustrating: Have I to start writing from the en.wikibooks and then translating it manually to it.wikibooks? or vice-versa? and after I will ever end, how to keep them in sync if people improve one or other? or start new translations? Keeping everything in sync is simple with the Extension:Translate, and we can try it here in en.wikibooks for a while.

TD;DR (too long; didn't read):

We have an extension (mw:Extension:Translate) that is activated in some wikis and could be activated here to try to start manuals, documentations, technical references, etc., where every information must be accessible as soon as possible. Try it out in "MediaWiki Wiki" on and see the status of the translations for every page (for example here: mw:Help:Navigation).

Do you have any question? Do you know this extension? Do you want to try this feature here? :) Thank you! --Valerio Bozzolan (discuss • contribs) 07:22, 19 February 2020 (UTC)

I wouldn't think so, no. This is a mono-lingual project - any translation would go on a sister project. There are so few editors here anyway, there's essentially no chance that translations would be produced particularly as translation of a book is significantly more challenging than translating, say, a site notice on Meta, which is the main use case for the tool. QuiteUnusual (discuss • contribs) 10:17, 19 February 2020 (UTC)

I'm also confused here. Translate is useful on c:, d:, incubator:, m:, mw:, species:, and s:mul: due to their nature but why would it be here on the English-language Wikibooks? —Justin (koavf)❤T☮C☺M☯ 10:56, 19 February 2020 (UTC)

@Koavf, QuiteUnusual: You are completely right, and this why in the 2018 I started a discussion in meta:Requests for new languages/Wikibooks Multilingual 2 without success. During the discussion @StevenJ81: suggested to first play with this extension here. --Valerio Bozzolan (discuss • contribs) 09:41, 20 February 2020 (UTC)

I really don't see any political will to do this or to have a multi-lingual book project, if for no other reason than how small an inactive Wikibooks is generally. —Justin (koavf)❤T☮C☺M☯ 11:23, 20 February 2020 (UTC)

I don't think book content, by its nature, is especially amenable to translation in general, though there may be a very few individual books that could be. (I'm actually, by coincidence, in the process of reading a dead-tree translated textbook, and despite being well-translated it's got pitfalls to watch out for; it's just not the same as a natively written presentation, and in general the notion of just shunting information back and forth between languages doesn't apply to the subtleties of textbooks.) Wikibooks is, by nature, not so much a single small-ish project as a confederation of thousands of mostly-ultra-tiny micro-projects (individual books) banded together to share a common administrative infrastructure. Almost none of those thousands of micro-projects would be interested in translation; hence, Wikibooks just isn't a likely place for a translation extension to take root. --Pi zero (discuss • contribs) 14:18, 20 February 2020 (UTC)

I just thought that an activation (even a trial one) of this well-known extension could be useful to someone, even just for one book. But maybe I'm wrong and I was just too enthusiast to have the opportunity to use it for my books. --Valerio Bozzolan (discuss • contribs) 18:31, 24 February 2020 (UTC)

I'm just having a hard time imagining when in principle a handbook, manual, guide, or textbook would be multilingual. Some source texts certainly are, and they are posted at s:mul: but a textbook in two languages...? That's in addition to the reality of how dead of a project this is. —Justin (koavf)❤T☮C☺M☯ 18:42, 24 February 2020 (UTC)

Can't honestly agree with the "dead" characterization. --Pi zero (discuss • contribs) 23:41, 24 February 2020 (UTC)

Side-note: en.Wikibooks get about 10 million page-views a month,; in comparison simple.Wikipedia gets about 20 million, and en.wp gets about 8 billion. So death may have been greatly exaggerated :)--Jules (Mrjulesd) 16:57, 29 February 2020 (UTC)

Getting .125% as much traffic is actually pretty compelling evidence that this project is "dead" in comparison. I realize that there are still edits here and it's obviously not really a closed or deleted project but by comparison to other WMF projects, Wikibooks is very inactive. And this is only discussing English. —Justin (koavf)❤T☮C☺M☯ 17:02, 29 February 2020 (UTC)

Still disagreeing, here. --Pi zero (discuss • contribs) 21:42, 29 February 2020 (UTC)