Wikibooks:Reading room/Proposals

From Wikibooks, open books for an open world
Jump to navigation Jump to search
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 Stacks[edit]

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:33, 25 May 2020 (UTC)

Export to Pdf, Epub, Odt, LaTeX[edit]

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 (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)

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 (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)
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 (discusscontribs) 22:25, 24 February 2020 (UTC)
Using Wikisource, they seem to have a working ePub export, can that be applied here? JimKillock (discusscontribs) 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 (discusscontribs) 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 (discusscontribs) 15:04, 4 April 2020 (UTC)

So not much has happend here for a month. Is there any process to come to a decision on this point? --Dirk Hünniger (discusscontribs) 12:00, 3 May 2020 (UTC)

I made some suggestions about how this might be handled below. JimKillock (discusscontribs) 22:09, 3 May 2020 (UTC)

Wikibooks:Maintenance[edit]

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 (discusscontribs) 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 (discusscontribs) 13:23, 5 February 2020 (UTC)

What about trying Extension:Translate?[edit]

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 (discusscontribs) 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 (discusscontribs) 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)TCM 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 (discusscontribs) 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)TCM 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 (discusscontribs) 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 (discusscontribs) 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)TCM 18:42, 24 February 2020 (UTC)
Can't honestly agree with the "dead" characterization. --Pi zero (discusscontribs) 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)TCM 17:02, 29 February 2020 (UTC)
Still disagreeing, here. --Pi zero (discusscontribs) 21:42, 29 February 2020 (UTC)
Symbol strong support vote.svg Strong support. It can be tried, if no can appear another project to do it. And thtis is not a good idea. Free translated books in a lot of languages. Seems good. In any case, the "Translate tool" would be activated in the Language links in every page. BoldLuis (discusscontribs) 11:56, 18 May 2020 (UTC)

Proposal: add features that support ebook writers better[edit]

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 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 (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)

Proposal to release content on GitHub[edit]

I think if the content on this website was released to GitHub then the books on here would get a lot more traction. It seems to me that you could convert the books to markdown using Pandoc and host them on GitHub. There are many more users on GitHub than there are on this platform and they are generally open-source minded on the platform. Hosting on GitHub will also provide a lot of free infrastructure. You can manage additions to the text however you want by setting up teams with various permissions. Anyone can contribute. 136.33.252.210 (discuss) 01:40, 29 April 2020 (UTC)

Sounds interesting. Go for it. If you do, please ping me with <nowiki>@Koavf:</ping>. Thanks. —Justin (koavf)TCM 02:53, 29 April 2020 (UTC)
This may be true and there's permission from a legal POV, but some thought about divergence should be considered – are books being developed on both platforms together, or simply forked? If the latter, the advantages aren't so clear. Also GitHub may well be a better place for books relating to technology and programming, but may not be so helpful for language learners, for instance. Essentially I would apply some care and thought about what is cloned / copied / forked and why. JimKillock (discusscontribs) 07:29, 29 April 2020 (UTC)
OP here. My view is that the books may diverge but it shouldn't be too bad to maintain a wiki markup version of the document (converting via pandoc). People that are working on this website can pull from it whenever they want. I reckon pandoc would solve some problems people have been having with converting to formats like epub. This is part of a nonprofit I am working on for test preparation so I am focusing on topics with AP exams or on ACT mathematics. For now the focus is just AP calculus and ACT math. I could imagine extending to all AP exams if we pick up steam. I built some software to help wikibooks crowd source problems as I desired more problems from the calculus book. People can build custom quizzes and share them with their friends. ActuarialAnalyst (discusscontribs) 12:09, 29 April 2020 (UTC)
Some links to these examples would help us understand what you're after doing. Exams and maths sound quite good specific things that might work better on GitHub. The food recipe books on Wikibooks, or the children's books, maybe less so, for instance.
I guess the question feels like: do you have some people who want to do some things on GitHub? If so, great, of course you should go ahead. There is a second point about whether Wikis are the right tool for open learning respources; I am of the opinion that Wikimedia should gradually widen its' available formats over time – as it has with Wikidata and Wikisource – providing more consumer / user focused tolls like easy to set up learning games, course structures etc; (keeping to open licencing all the time). Meanwhile some things will be better done elsewhere, and Github could be a place for some of that. But I don't think moving content will move the authors necessarily. I'm unlikely to use GitHub as I only use it for bug reports and development tasks, I don't submit code and revisions. The majority of people don't use Wikis or repositories, even when they want to create content. Far more find Google docs to be the 'right' default solution – but that doesn't mean we should move all the books to Google Docs either.
As for epub creation, Wikimedia have good tools for that, (see an example here, they just need implementing here (this is trivial but there is thinking for people to decide how to present links).
In the end tho Wikimedia Foundation isn't (I imagine) going to start hosting content on other people's platforms, so moving content to GitHub is a decision for you rather than for the community here per se I would suggest.
NB: you don't need permission for what you want to do, as I am sure you know! JimKillock (discusscontribs) 16:25, 29 April 2020 (UTC)
Right, well I suppose I will have to see if I can find help on GitHub. I had hoped somehow I could garner support from administrators on wiki but that is probably too much to hope for. Here is my website to crowd source math problems. I converted the Calculus I and II wiki markup to markdown with pandoc today. Still requires a lot of cleaning. I can't post links in this freaking place ugggh, otherwise I would post my website. edit: I think I'll just not use the wiki content and license the GitHub content under CC0. 136.33.252.210 (discuss) 19:59, 29 April 2020 (UTC)
For external links, see for instance w:Help:Wikitext#External_links. JimKillock (discusscontribs) 21:29, 29 April 2020 (UTC)
JimKillock, it's interesting to me to hear you suggesting the Foundation should branch out to non-wiki-markup formats, because I have a kind of diametriclally opposite view: I think the Foundation has been making a staggeringly huge mistake by trying to deprecate wiki markup pretty much since the Foundation went into full operational mode (what, is it 12 years and change ago, now?) and thereby slow-poisoning the sisterhood that they're supposed to be nurturing, because wiki markup is their greatest asset and should be strengthened and used for everything (rather than marginalized while tasks are offloaded into other languages such as Lua and Javascript, the afaict-entity-relationship database model of Wikidata, whatever). --Pi zero (discusscontribs) 02:41, 30 April 2020 (UTC)
I hear what you are saying … I think my concern with the wiki format is that it is just a format; and the goal of the foundation ought to be promotion of collaborative production of open knowledge and learning. When I look at how learning is developing on the net in general, I see many innovations like Duolingo and Memrise, that look like this model but are locking up community-produced content into very specific and potentially short run ventures. I conclude therefore that some quite targeted but evolving tools may be needed that aren't a Wiki model, if we want to leverage free and open for learning. An open competitor to Duolingo / Memrise (like an online Anki) would be possible and a good idea; it would need to have user accounts to track progress at a minimum, and easy ways for people to contribute and build courses. Wiki markup or not I am more agnostic on, but ease of creation and use seems to be the issue. WikiMedia got the idea of working together in the open exactly right; the question to me is why the open learning model is missing so much of the user / creator space at this point. JimKillock (discusscontribs) 07:51, 30 April 2020 (UTC)
I think a major long-term obstacle to a flourishing wikimedia sisterhood —it was flourishing when the Foundation kicked into high gear, and has been slowly wilting ever since— has been that the Foundation views the 'educational mission' as their mission, for which they get free labor by the volunteer community, rather than the volunteer community's mission that the Foundation should be catalyzing. I remember this was one of the things I noticed in that Wikimania keynote by Lila Tretikov that, at the time, I mentally summarized as 'the Ministry has decided to interfere at Hogwarts'. (I have never blamed Lila personally, btw; afaict she was set up for it, handpicked and programmed with all the bad ideas that were packed into that keynote; and I don't really think much has changed since then, with the ultimate sources of those bad ideas deeply entrenched.)

In fairness, pursuing wiki markup is a tricky thing; for example, the markup would not be improved by indiscriminately piling on features, which would only give it a worse case of featuritis that it already has. What's needed is some vision on how to add just the right primitives, simple and powerful, to empower and encourage the volunteer community to grow the specific tools needed as part of the wiki, in somewhat the way the volunteer community grows the document-content of the wiki. I've a notion that dialog tools plus {{evalx}} (plus a very few miscellaneous bits like Module:TScope) plus dialog-based semi-automated assistants might do... and it's admittedly a long slog getting there. (A couple of essays I've cobbled together: on Wikibooks, User:Pi zero/essays/Wikiness; on Wikinews, n:User:Pi zero/essays/vision/sisters.) --Pi zero (discusscontribs) 11:55, 30 April 2020 (UTC)

┌─────────────────────────────────┘
I can't comment on the relationship between WikiMedia foundation and community. I sympathise with the perception that learning Wiki markup is a barrier to entry, but it does open up the composition powers for users of these projects for sure. For me the biggest problem with public interest projects is aligning activity with user needs, as in general their mission has a more abstract purpose, such as codifying knowledge, making it available, etc. This problem is seen through open source models as well as library-like projects; there is a tendency towards completism (all features need to be available) rather than UX (features need to be easy to use and actually used). We have a further problem in the 'open' world, which is that innovation, while permissionless, can sometimes be harder to deliver because of factors like backwards compatibility, lack of investment, or community considerations. I believe in open approaches because they are fairer and spread benefits more widely, but that only works in the open knowledge space if content is used and / or built on. In language learning – my current personal interest, so to speak – much public domain material is used and reused on closed projects; there is little understanding of the benefits of sharing; very few projects take a specifically open approach; there is no sense of a strategy to enable an open learning model to flourish. I am sure this spreads to many other fields, because, after all, why should a strategy exist? So I feel WikiMedia Foundation, Creative Commons and others may want to consider how to build a more strategic approach to specific sectors, and think about what infrastructure, tools, data, ought to be collated, made available, etc, to make the open approach at least as compelling as the closed. That's my broad take on all this. But I've got very off topic! JimKillock (discusscontribs) 06:56, 1 May 2020 (UTC)

Computing viruses[edit]

It would be interesting a book dedicated only to computing viruses and virus documentation (to documentate the types, names...). From a computer user's point of view (this also include tablets and phones). BoldLuis (discusscontribs) 11:48, 18 May 2020 (UTC)

Angel Inspiration Cards?[edit]

Hey WIKIBOOKIANS! Although I seem to have lots of energy, I do not, nor do I have a lot of time because I have already started two new projects: Create Vampires and Create Ghost. Hello, I am new to Wikibooks, and I am baffled yet oddly inspired by the work other people have shared. Part of me wants to work on the "bookless" wikibooks called Create Vampires and Create Ghost, although I now see some problems in creating a "text-book" that can be edited by anyone, with unbound pages. Because I am unsure, I thought outside of the box, or rather, about what goes inside the taro box. Although taro / tarot / and motivational cards are NOT considered academic texts, they can be instructional, dependent on the person, or group of people and illustrators, creating the game. Most taro cards are labeled under "U.S GAMES" FOR CLARIFYING REASONS.

The important aspect: a collection of pages that mimic cards, with Art images and useful information, and inspirational quotes. There are dozens of taro cards, they range from dream-analysis linked with introduction to Psychology / Sai-Co-Lo-Gy to cards that introduce STAR TREK crew as "mental functions." I myself prefer inspiration cards, yet I have noticed a lot of motivational material online.

Ideally, a group of interested people would research various taro cards [within reason, exercising precaution because some cards are associated with active cults], then create a resource-book for people to familiarize themselves with the wide range of card decks that are listed, and known generally as taro / tarot cards.

If people like the information, and guidelines, they can then decide to create a category for known taro cards, or design new taro decks. The structure of taro cards maybe what may work for wikibooks, or, this type of taro structure may work for another project, or may work to help develop fictional plot-lines. I share this because I am uncertain of how to structure bookless "books." Maybe Angel inspirational cards could lead to sacred geometry cards / deck, with useful illustrations, sharing helpful math questions, design to get the student to think about problems using their math knowledge, or think about limits because we represent shapes using 2D [sometimes 3d] drawings. Thanks. Peyton09 (discusscontribs) 00:03, 19 May 2020 (UTC)

3D Slicer[edit]

I suggest a book about 3D Slicer, open and free source, used in medicine.BoldLuis (discusscontribs) 04:05, 20 May 2020 (UTC)