Wikibooks:Reading room/Archives/2020/April

Help search
No offense intended but I'm baffled by the Help search. For example, suppose I want to know the general syntax for the TextBox template. I click on Help in the left margin and get a Help search dialogue. I observe that Help is checked. I uncheck Wikibooks. In the search bar I type "TextBox syntax". Then click on Search. The response is "Did you mean: textbook syntax" and a list of references. Of course I don't mean "textbook syntax". None of the references pertain to the syntax of a TextBox. Next try a search for "TextBox template". The result is "Did you mean: textbook templates" and another list of references. Again no help. I know the template is defined somewhere but finding the syntax is almost impossible. I don't mean this to be a harangue. Rather a report from a hapless user hoping that progress is possible. Regards, ... PeterEasthope (discuss • contribs) 19:13, 30 March 2020 (UTC)


 * Well, I just tried searching for "TextBox", myself. The top match I got back was this thread.  The second match was the Wikibooks sandbox.  The third match, though, was a section of a general page, Templates/General. --Pi zero (discuss • contribs) 19:53, 30 March 2020 (UTC)
 * Screenshot of different results here. http://easthope.ca/TextBoxHelpSearch.png Odd. Ideally the search would find Template:TextBox. ...


 * Did you mean Template:TextBox? It gives the options in the text below. Its basically a css div box, and you can read about them at https://www.w3schools.com/css/css_boxmodel.asp . -- Jules (Mrjulesd) 22:23, 30 March 2020 (UTC)
 * Yes, Template:TextBox explains the syntax ... but the search didn't find it ... unless it was way down the list. Anyways, thanks, ... PeterEasthope (discuss • contribs) 23:41, 30 March 2020 (UTC)
 * Looking at your screenshot above: you searched in the help pages, and basically there isnt a help page to explain its use. Usually with templates, to explain their use, you need to look at their template documentation, which shows up when view the template page. Very often they aren't explained otherwise in the help page system. For example Template:Chapter navigation is explained in its documentation, but not on a help page. So if you search there it will not show up at all. -- Jules (Mrjulesd) 23:58, 30 March 2020 (UTC)
 * For searches like that it's generally advisable to include project space as well as help space. --Pi zero (discuss • contribs) 00:59, 31 March 2020 (UTC)
 * You mean I should leave the Wikibooks box checked in the Help search? OK but it still fails to report Template:TextBox. That is the best documentation to me. I just need to remember the URL https://en.wikibooks.org/wiki/Template: . (Probably wishful thinking.) I'm afraid WikiMedia is falling into a common peril for software: experts want to improve by adding features whereas more features are more difficulty for non-experts. Simplify wherever possible. Of course you can never satisfy every requirement. This won't be my last submission to the Reading Room. =8~) Thanks for the help, ... PeterEasthope (discuss • contribs) 13:59, 31 March 2020 (UTC)

I agree that it is difficult remembering about templates. In fact I think its one of the toughest challenges of contributing to wikis, from a technical point of view. But I will make a few points: -- Jules (Mrjulesd) 22:22, 31 March 2020 (UTC)
 * Firstly be aware of Templates. It is an index of common templates you can look up on. It's a useful resource, but isn't comprehensive; not all templates are listed. But still many are: for example for box type templates are listed at Templates/General. If that doesn't work, try looking in Category:Templates, they should all listed there if you can find them.
 * If you search for templates, tick the,  , but also the   namespaces, as template documentation is usually the best place to find info on templates.
 * You can always ask here for help if you get stuck! So continue asking stuff if you have any queries.
 * Good. I've made a few notes. Thanks, ... PeterEasthope (discuss • contribs) 02:13, 1 April 2020 (UTC)

Details of format and style
Hello again, here are more questions for the experts. The old document for the Oberon-2 language is linked in this footnote. https://en.wikibooks.org/wiki/Oberon#cite_note-5 My current editing is in my sandbox. Here are some questions. In case you are interested to edit the sandbox, that's OK by me. Assuming you don't make it worse of course. Thanks! ... PeterEasthope (discuss • contribs) 16:56, 31 March 2020 (UTC)
 * 1) In the sandbox the section numbers should remain as they are in the Contents. Can they be included on the section headings throughout the document?
 * 2) I've used table markup to mimic the format under "Vocabulary and representation". Can the whole table be indented as in the original document?
 * 3) Can style="vertical-align:top; border:none" be specified more efficiently?  Ie. specified once rather than on every cell of the table.
 * 4) In the original document, "$ ident ..." and "x  scan ..." are in monospaced font; probably Courier. How can this be invoked in the MediaWiki representation?
 * Without access to the Mediawiki namespace this is tricky. But I have experimented a bit with templatestyles, and I believe now this is possible. My I edit your sandbox to add the necessary code, as it is a bit complicated to describe?
 * Indenting tables is easy. If you add colons before the open table markup, it will indent. e.g. use the code  to indent the table twice.
 * Without ready access to style sheets it is simplest just to repeat the inline css as necessary.
 * Try using the css font-family: monospace, monospace;, e.g.  will produce  Example . Or else the  property; if this is removed they go away.
 * But a better solution is to add the overflow:hidden; property, e.g. like . They then seem to disappear.
 * I think its some sort of Chrome or Mediwiki bug, can't see why non-functional scroll bars would appear. Tested it on Wikipedia and you get the same thing. But anyway my last point seems to be a workaround that can be used. -- Jules (Mrjulesd) 09:24, 13 April 2020 (UTC). Another comment: they seem to appear dependent on the level of zoom on the page, they otherwise disappear. -- Jules  (Mrjulesd) 09:38, 13 April 2020 (UTC)
 * I saw them last night in Firefox, but don't see them anymore now. --Pi zero (discuss • contribs) 16:23, 13 April 2020 (UTC)
 * Oh that's interesting. But you can't see them in the sandbox now the code has been changed. But the previous code was like:
 * Oh that's interesting. But you can't see them in the sandbox now the code has been changed. But the previous code was like:

 $ number  =  integer | real. $ integer  =  digit {digit} | digit {hexDigit} "H". $ real  =  digit {digit} "." {digit} [ScaleFactor]. $ ScaleFactor  =  ("E" | "D") ["+" | "-"] digit {digit}. $ hexDigit  =  digit | "A" | "B" | "C" | "D" | "E" | "F". $ digit  =  "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9".
 * I can't see them in firefox at all, whatever zoom level I have. But still on Chrome at certain zoom levels. Very odd, but there you go. -- Jules (Mrjulesd) 18:16, 13 April 2020 (UTC)

Technical problems encountered by Edit filter/URL requests
following on from the technical problems you're encountering at Edit filter/URL requests. Basically they're very curious and I no real understanding of what's going on here. But I would like to ask some questions.

Are you autoconfirmed? You can tell by going to Special:Preferences; under "Member of groups:" does it state "Autoconfirmed users"? See Autoconfirmed users for an explanation.

The reason I'm asking is that Ive looked at your account at https://xtools.wmflabs.org/ec/en.wikibooks.org/MarkJFernandes, and I've seem a curious thing; according to the log you were "2020-04-15 14:42 	autoconfirmed user Automatic". But looking at your "User groups" field it is blank. That shouldn't be the case; e.g. look at my one at https://xtools.wmflabs.org/ec/en.wikibooks.org/Mrjulesd.

Now I really don't understand why these should contradict each other, an I feel there may be a technical problem with your account. -- Jules (Mrjulesd) 12:54, 15 April 2020 (UTC)


 * thanks for looking into this in some detail. So I am not in the autoconfirmed group—I'm only in the Users group. I'm exceptionally new to Wikibooks, so perhaps `there are some hoops I need to jump through` before things start running more smoothly for me?
 * --MarkJFernandes (discuss • contribs) 13:33, 15 April 2020 (UTC)


 * OK thanks. I've been trying to work out the meaning of the xtools page. What it could mean is that you are going to be autoconfirmed at 14:42 GMT today (it is currently 13:52). Now if you get autoconfirmed it could mean that problems will decrease, as most edit filters don't apply to autoconfirmed users. So it might be worth waiting a while and see if you get autoconfirmed; if so you may find that it solves your problems.
 * Now I'm not saying that this will happen, but I think it would fit in with your en.wikibooks account, that was registered 14:42, 11 April 2020. Since it takes 4 days for autoconfirmed status, it all makes logic to me. -- Jules (Mrjulesd) 13:58, 15 April 2020 (UTC)

Editing news 2020 #1 – Discussion tools
Read this in another language • Subscription list for this multilingual newsletter



The Editing team has been working on the talk pages project. The goal of the talk pages project is to help contributors communicate on wiki more easily. This project is the result of the Talk pages consultation 2019.



The team is building a new tool for replying to comments now. This early version can sign and indent comments automatically. Please test the new Reply tool.


 * On 31 March 2020, the new tool was offered as a Beta Feature editors at four Wikipedias:  Arabic, Dutch, French, and Hungarian.  If your community also wants early access to the new tool, contact User:Whatamidoing (WMF).
 * The team is planning some upcoming changes. Please review the proposed design and share your thoughts on the talk page.  The team will test features such as:
 * an easy way to mention another editor ("pinging"),
 * a rich-text visual editing option, and
 * other features identified through user testing or recommended by editors.

To hear more about Editing Team updates, please add your name to the "Get involved"  section of the project page. You can also watch these pages: the main project page, Updates, Replying, and User testing.

– PPelberg (WMF) (talk) & Whatamidoing (WMF) (talk) 19:28, 8 April 2020 (UTC)

How to tag words and phrases in a book, such that Wikibooks can then automatically generate an index using such tags?
If you read the text at https://en.wikibooks.org/wiki/Help:Local_manuals_of_style#Navigation, you'll see that Wikibooks says that a navigation template can be used to create an index. However, after clicking the related hyperlink, I can't seem to find information about how to do this. Can someone point me in the right direction?

--MarkJFernandes (discuss • contribs) 17:37, 17 April 2020 (UTC)


 * My best guess &mdash;which of course could be quite wrong&mdash; is that the reference you're asking about, where it says a navigation template can be used to create an index, doesn't mean there's any way to automatically create an index, it just means that if you do want to create an index, you can use a navigation template as a way of making it available throughout the book. I have put some thought into this sort of thing myself, and have lately developed an extensive glossary for the Conlang wikibook (Conlang/Appendix/Glossary), but I'm continually thinking about ways to improve it.  Part of my idea there is that, since we don't really like to have links in the middle of a book that go out of the book altogether, all the "outward" links in the body of the book could go to the glossary, and then only at the end of each glossary entry would there be links out of the book.  (Likely at some point I'll construct some sort of semi-automated assistant to help with that glossary, based on the dialog tools, and perhaps then I can generalize that... but that's not all going to happen tomorrow.) --Pi zero (discuss • contribs) 19:13, 17 April 2020 (UTC)


 * thanks for your reply. Not sure whether I agree that external links should only be in the glossary. I'm quite happy for external links to be in the main body of the work.
 * Coming back to the idea of tagging key words and phrases for automatic index generation, I think such a facility would be great. When using online reading resources, I often use any indexes in such resources. I have some coding skills&mdash;just wondering whether I could code the template for such a facility. Perhaps someone could point me in the right direction for creating such a template?


 * --MarkJFernandes (discuss • contribs) 07:34, 18 April 2020 (UTC)


 * Two miscellaneous thoughts.
 * As an alternative to an index as-such, you might consider book search (you can see it used on the main page of Conlang, at the top of the right-hand panel).
 * Minimizing (but not completely eliminating) links outgoing from a book is just usual in Wikibooks culture, as part of the coherence of a book (part of what makes a book a book). Avoiding outgoing links entirely in the book body is something I'm experimenting with, partly because the Conlang book has so many outgoing links.  It allows providing commentary on each outgoing link, that will be encountered by each reader following that link as they pass through its glossary entry, provided some effort is put into offering brief-but-valuable perspective in each glossary entry.
 * --Pi zero (discuss • contribs) 11:32, 18 April 2020 (UTC)


 * thanks for some useful advice/guidance. In regard to the search box, I did think about whether indexes were really needed given that you can just use a search box to search for specific words/phrases. It should be noted that many modern online reading resources (such as manuals) still do include indexes perhaps pointing to them adding value over simply having a search box. Indexes give a good overview of different important elements found in the narrative of a book, beyond what you get with just a table of contents. Because semantic relations in language often are alphabetical (such as for example 'computer software' coming just after 'computer platform' with both being associated [because both are about computers]), alphabetical indexes can be extra helpful. To be honest, adding an index isn't essential for my book, but it is on the wish list.


 * I'm very much new to Wikibooks, so I may make a few mistakes in my thinking related to Wikibooks books. However, the book I'm working on has very many external links mostly to Wikipedia articles, and I feel that this is the right thing to do. The idea is to provide users with an easy way to learn about highlighted terms and phrases. It's just about extra information that I believe shouldn't be in the book, but is usefully linked-to, to provide extra and sometimes essential explanations about things. In respect to book coherence, my opinion is that if I put the linked-to material in the book, the book would lose its coherence, because it would become over-bloated and also because it would be out-of-date due to the otherwise linked-to material being updated more frequently than the book. I'll concede that including a glossary is perhaps another good way to provide such extra information, but then you still have the issue about material becoming quickly out-of-date.


 * --MarkJFernandes (discuss • contribs) 13:41, 18 April 2020 (UTC)


 * While we're on the subject(s),
 * I'm a big believer in manually processed indices and glossaries and such, rather than mere automatic searches. Yes, automatic searches can be a useful tool.  I learned my way around libraries pre-internet, though, when they had physical card catalogs, thousands upon thousands of index cards all carefully crafted with individual thought; and when those were replaced by on-line catalogs, at most (not all) libraries the quality of searches went down by quite a lot.  Turns out the software for those on-line catalogs allowed all the nuanced information from the old physical cards to be put in, and if you did that you could produce a really awesome on-line search system, which a few libraries actually did with excellent results; but most libraries just had somebody type in the minimal information, and almost all the deep information in the old cards was just thrown away.  So, like I said, I really favor indices and glossaries with a lot of customized thought gone into them.  This also means that if an index were to be generated, I would favor some means of guaranteeing that hand-crafted information goes into it, both when it is first set up, and in however it is maintained.  As an example to think about, we have on Wikibooks a hierarchical arrangement of "shelves", starting at Wikibooks Stacks/Departments; all the sorting and listing is handed semi-automatically, but human beings decide how to hierarchically order the shelves, and human beings decide, for each book, what shelves it should be placed on.  Thus, the individual decisions that go into forming the shelves are distributed to where the users are who have the knowledge to inform those decisions.
 * Regarding links out of a book. Part of what makes a book a book is that it is, to a significant extent, self-contained.  Usually there is a particular order in which the modules are meant to be read; a relatively few books aren't exactly linear in that sense, but then the modules within them are generally of a specialized sort (like Wikijunior:Solar System, or Wikijunior:The Elements).  Links going out of the book are less intensive than, say, the cross-links between articles on Wikipedia.  There is also a difference between the projects in depth: a wikibook can go very much further into the details of its subject than a Wikipedia article would.  There is, in effect, a hierarchy of how a book module is linked:  we're most casual about linking to elsewhere in the same book, a bit more reluctant to link to (or into) another wikibook, a bit more hesitant still to link to a page on another project in the wikimedia sisterhood (such as Wikipedia), and decidedly more cautious about "external links", i.e. links to outside the wikimedia sisterhood, since that involves a definite drop in trust/privacy of the server.  (All of the wikimedia sisterhood prefers to set off external links so readers are especially aware before clicking one of those.) Which said, although it's clearly desirable to minimize links out of a book, it's not always clear how best to go about it.  What sort of measures make sense depends on the character of each individual book.  I'm hoping, with the thing I'm trying for the Conlang glossary, to add to our vocabulary of techniques for this sort of thing.  It seems to work quite well for that particular book, but I only offer it as food for thought, as the circumstances of your particular book are unlikely to exactly duplicate those of Conlang.
 * --Pi zero (discuss • contribs) 15:58, 18 April 2020 (UTC)

👍🏽  👤 

Book search that lists more than one result per page
I've tried out the book search and the search box templates on the book on which I'm working. They work as they were intended. However, for my book, I would like for more than one result found in a page to be returned, when more than one match is found in a page. As far as I can tell, these templates, and the standard Wiki search functionality across the Wiki Foundation sites, do not have this functionality.

I would like more than one result to be returned, because each chapter (some of which are quite long) is contained each on its own page. I feel this is better than splitting the chapter up into several web pages&mdash;it makes browser searches (, etc.) easier and also makes following the narrative that runs through any one chapter easier (IMHO).

Can anyone give me any pointers on how I can satisfactorily resolve these issues?

My thoughts on a solution:
 * 1) create a directory/folder for each sub-section of the chapters;
 * 2) proceed to create one wiki page for each subsection (in the directory), that on-the-fly extracts (via something like an 'includes' statement) the subsection from its source chapter page;
 * 3) on each of these subsection pages, have a link that links back to the subsection as present on the corresponding chapter page;
 * 4) now when book search is performed, each of these sub-section pages can return a hit, potentially resulting in more than one result per chapter, which whilst not always providing a perfect correspondence to matches, perhaps is acceptable at least for my particular book.

The above solution seems okay but I don't know how to implement the 'includes' functionality&mdash;anyone have any ideas?

--MarkJFernandes (discuss • contribs) 08:54, 28 April 2020 (UTC)


 * ADDENDUM NOTE: it appears that the Wiki transclusion functionality can probably implement the 'includes' functionality mentioned (see Transclusion). --MarkJFernandes (discuss • contribs) 06:34, 29 April 2020 (UTC)


 * Some thoughts. Well, okay, I've ended up writing rather a lot, below; it's all reasonably brief and to-the-point until I start talking about dialog; well... half-sorry about that, but it is relevant.
 * The essential problem is that the wiki-search feature provided by the wiki platform is, conceptually, separate from the string-search provided by the user's web-browser. They don't actually complement each other as one might hope they would; it's more like, they awkwardly divide up the task into separate domains, and each of them insists on handling only one half of the task, while the user is obliged to switch from one mode to the other halfway through their search.  That is, the on-wiki search imitates internet search engines (and probably uses one), which have pages as their end targets; while the browser string-search locates occurrences of that string on the particular page that is being viewed.  If these are the tools available to you, and you want to find all the occurrences of a string on all the various pages of the book where the string occurs, you have to use the two successively, finding the pages with the first tool and then using string search on each page.  A compounding problem is that both these tools are blind to semantics: they search for a string mechanically, without regard to the actual meaning of things.  Taking meaning into account is the function of a humanly-constructed index.  Sometimes one will see a really sophisticated index in a book, under a particular keyword, distinguish somehow between one or more primary/major references to the keyword, and a bunch of secondary/minor allusions.
 * If you had a really good index, what would you like to be its targets?
 * Btw: The standard terminology set out for Wikibooks long ago calls the content pages of a book "modules"; it never really caught on, perhaps because it's neither standard enough to come naturally to users as they arrive at the project, nor gets used heavily enough once the user arrives to make an impression on them. As an illustration of the latter, on Wikinews the term "lede" is so ubiquitous that pretty much everyone ends up knowing what it means.
 * Would it be satisfactory for an index to target section-headings within modules? This is what I did with the Conlang glossary, though rarely have I wanted to link a single keyword to more than one section within the same module.
 * The problem is then how to assemble such an index. There are some devices I think could be useful for this, some of which are more ready-for-prime-time than others.
 * There may be ways to accomplish a great deal without relying too heavily on the parts that are less developed atm. For instance, the Wikibooks Stacks get along, more or less, with less tooling than I would imagine eventually bringing to bear on them.  An index-building device might work from embedded meta-information in each section of each module, specifying what index entries ought to target that section.  One would then want to extract this meta-information from each module and collate it all to generate an index; and there are a range of different levels of semi-automation that might be employed for that.
 * I should perhaps explain about the overall plan that surrounds the "dialog tools", because this has to do with what the parts are, how they are meant to be used together, and which parts are more ready-for-prime-time that others. (And this, alas, is where the length of this comment gets away from me...)
 * It all starts with the notion that wikis could become vastly more powerful, wholly transforming the nature of the medium, if only they could have interactive elements freely placed on them: imagine a wiki page with a variety of text input fields (along with perhaps occasional drop-down menus and checkboxes), and a bunch of buttons one could click each of which would take data from the input fields and send it somewhere to have something done with it.  With a small number of simple templates that would allow specifying elements of these kinds, so they could be placed on the wiki page via wiki markup (things like, say, dialog/text, dialog/checkbox, dialog/button, etc.).  The good news is, that can be done, and I basically have done that and it's available on Wikibooks now.  But there are some caveats.  To make these simple primitive elements practical to use, you need about three additional things.  (I'd always figured that, once you had the primitive elements, there'd be a long process of learning idioms for how to use them, details of which would be inherently impossible to anticipate before one had the tools available to actually work with.)  You can read about the simple primitive elements, btw (I mentioned this once earlier, I see), at Help:Dialog.
 * You need a way to organize sets of pages into coherent "semi-automated assistants"; these assistants are, more-or-less, "wizards" for performing particular tasks. I've set up a way of grouping the pages of an assistant together that's inspired by the way Wikibooks groups the pages of a book together.  (The primitive-tool development, btw, is happening on Wikinews, because the license there is more permissive than other sisters, so the tools can be exported from there to, say, Wikibooks.  The latest version of things hasn't been ported over to Wikibooks yet; I'm waiting for the latest improvements to be just a bit more stable before tangling with that.)
 * The main example of an assistant that I already have working is Breadboard. (Basically, it lets you write wiki markup that depends on template-parameters and test it by specifying what the values of the template-parameters should be; actually those aren't template parameters, they're dialog parameters, but, close enough for most purposes.)
 * You need some peripheral tools to help with doing, e.g., complicated transformations on the contents of web pages that the wiki platform isn't good at but that you also do not want to have to build into the dialog tools (because it's logically separate from the native function of the dialog tools). I explicitly want users to specify everything in wiki markup, which I consider essential to the reason wikis are a successful concept (I'm actually rather passionate about this); I believe the Wikimedia Foundation has been shooting itself in the foot, for many years now, by trying to migrate away from wiki markup to other languages, like Lua.  I only use Lua, or even javascript, to build tools whose purpose is to help users not have to use anything but wiki markup.
 * The primary peripheral tool I've created is evalx (mostly an interface, as it happens, for Lua Module:Wikilisp). And evalx I've found immensely useful.  It should be able to do things like combing through a module of a wikibook to extract meta-information from it that specifies how to build index entries targeting sections of that module, or using that extracted information to update an index page.  With... some careful thought about how best to arrange those things.  And perhaps a bit of dialog to direct the input to, and output from, the evalx template.
 * Ideally, ordinary users would contribute to assistants in the same way they contribute to ordinary wiki documents (such as wikibooks), and so assistants would be "grown" by crowdsourcing. Likely this ideal should be striven for but won't ever be perfectly achieved.  But, whenever a wiki task is performed over and over and is tedious or tricky requiring some expertise, it's a good candidate for an assistant.  And here's the thing: building and maintaining assistants is a task that's tedious and tricky requiring some expertise.  So it's an obvious choice to build an assistant for building-and-maintaining assistants; a "meta-assistant".  This would probably go a very long way toward making assistants more practical.  Can that even be done?  I think so, yes; but I expect it to be fiendishly tricky to tease out just how to do it.  I'm working on it; but right now that's the number-one cause of slow development of the whole dialog-based-assistant concept, and it's nothing to shake a stick at.
 * --Pi zero (discuss • contribs) 14:28, 28 April 2020 (UTC)

👍🏽  👤 

Book-like features Wikibooks could use
Hi there,

I'd like to use some of the features of Wikisource here, if people thought it appropriate. For instance:


 * Layouts that feel like pages (narrow columns, serif fonts, titles without underlines)
 * Automatic epub exports (available by default as a link at Wikisource)

This would let people build books here that are aimed at export to epub and use on devices. This doesn't have to be every book of course, but would certainly provide some opportunities for me that I am currently cautious about attempting here.

Does this seem practical or does it seem like too much to try to do? JimKillock (discuss • contribs) 12:17, 20 April 2020 (UTC)
 * JackPotte (discuss • contribs) 19:59, 20 April 2020 (UTC)