Wikibooks:Reading room/Proposals

From Wikibooks, open books for an open world
Jump to: navigation, 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.


I'd like to invite suggestions and opinions on an idea I attempted some years ago, and am thinking of trying again with an improved internal look-and-feel.

My idea was to have a single template that describes the organization of a whole book, called (in the current version) Template:name of book/Navlist, and then a suite of templates you can place on the pages of the book that automatically generate a table of contents, or a navigation box for the top or bottom of a page, or whatever other such thing is wanted. Using, of course, various formats for the TOC or the navboxes, depending on what is wanted for the particular book.

I implemented this, but at the time I had to rely entirely on wiki templates, and as a result, the format of the navlist was a bit odd-looking. (There were also some size limits because generating things from the navlist involved large numbers of template calls.) You can see the suite I created at {{Navlist}}, an example of a book using it at Conlang, and the navlist for that book at {{Conlang/Navlist}}.

I now have the means to rewrite the suite templates so that each book navlist uses a more readable format, and the suite templates parse the book navlist (which also drastically reduces the number of template calls involved).

So here are some questions, if anyone would like to offer their thoughts:

  • Is this a worthwhile idea to pursue?
  • What format should the navlist for each book use? Something based on wiki list notation, perhaps? Or something else?
  • What sorts of formats ought to be supported for tables of contents, top-boxes, bottom-boxes? What other kinds of things might be generated from the book's navlist?
  • (thrown in, gratis) Suggestions for other kinds of things that could benefit from being generated automatically, like this? I know of a Wikijunior book, for instance, that has a glossary, and then repeats items from the glossary on content pages here and there; I'm thinking a template could be set up so on the content page you can just say, basically, put the glossary definition of such-and-such here, and the template would go parse the glossary and snarf the appropriate definition from it. Or possibly one would have the glossary data in a template, and the glossary page itself would also be generated by extracting data from that template.

Miscellaneous notes:

I was worried, from the start, that the navlist would be vulnerable to mistakes, or vandalism, as a single-point-of-failure; however (unlike Wikidata which is outside the projects it affects), the navlist is grouped with the book. I have in mind, in the long run, we could build a tool for checking to detect dropped pages, and perhaps other kinds of anomalies.
I belive strongly that control of a project should rest in wiki markup, maximizing its accessibility to ordinary wiki users (even if in some cases it's fully protected; it's still more visible and understandable as wiki markup). So I've developed a device for implementing sophisticated stuff within wiki markup (not yet imported to Wikibooks, but I anticipate doing so; atm it's yonder). An example of using it for a navlist-like constomization device is n:Template:Infobox; that's a generic news infobox, where you can just name a category, like {{infobox|France}}, and it'll go look for a customization file for France; the customization file, if it exists, calls a template that sets up a wiki table containing the customizing parameters, so, and {{infobox}} parses the wiki table.

--Pi zero (discusscontribs) 14:20, 3 April 2015 (UTC)

Really interesting ideas. The stub template on the French Wikipedia, w:fr:Modèle:Ébauche, works like the kind of template you're describing (I think). {{Ébauche|France}} calls on {{Ébauche/paramètres France}} for image, portal to link to, category, and so forth. As regards the Navlist, it seems like a good and very useful idea. I am concerned, though, that it is confusing for an editor unfamiliar with the workings of wikicode to add or edit the table of contents at a page like Template:Conlang/Navlist. Is there a way to hide more of the code from a casual editor? Liam987 talk 20:21, 4 April 2015 (UTC)
@Liam987: The scary notation of {{Conlang/Navlist}} was always one of the things that bothered me about it, even though I was pretty excited I got the suite to work. It's now possible to use almost any (wiki-based) syntax we want, which presents a different kind of problem in that, with no constraints to force us to do things a certain way, we have to decide what we think would be most useful — most readable and most writeable, presumably. It may turn out that there are practical constraints after all, when I get into the coding, but meanwhile, I'm interested in any thoughts on what others think might work well. --Pi zero (discusscontribs) 23:03, 4 April 2015 (UTC)
@Pi zero: I've added a Navlist using your template on Breton, which I've been restructuring around imported Wikiversity material. It works very well, although one comment I have is that it would be useful to be able to have multiple levels of navigation in the {{Navlist/Top}} template. For example, the Breton books is structured into six levels and multiple lessons for level. I would like to be able to have the Navbox at the top of each page to link both to the next level and also to the next lesson, so that Breton/Level 2/Lesson 2 would link to Breton/Level 2/Lesson 1 and Breton/Level 2/Lesson 3, and then below that also to Breton/Level 1 and to Breton/Level 2. Also, more customizability as to which order pages are linked to, and maybe the ability to add pages to the Navbox list but not have them automatically included in the sequence for {{Navlist/Top}} and {{Navlist/Bottom}}, for optional subpages that are outside the main sequence of the book. Overall, though, these templates are great and I compliment you on them. Liam987 talk 20:59, 8 May 2015 (UTC)
@Liam987: Do you have suggestions on the question of navlist format? Since you've actually used it. I'm thinking the current format is extremely heavy on braces and pipes (wiki template-call notation), and since I think I need a more efficient and simpler internal implementation anyway, I can use pretty much any format I want. There's a bewildering range of possibilities, whereas when I first implemented the template suite I had such technical constraints I barely came up with one way it could work. At that time I thought about more complicated navbox formats and basically gave up because the implementation would be too hairy; now I could tackle more more elaborate navbox formats once I overhaul the internals, but I need to get the navlist format issue settled before I overhaul the internals. --Pi zero (discusscontribs) 10:20, 11 July 2015 (UTC)
@Pi zero: That's very interesting indeed, and the Wikilisp thing is just beautiful. In the Haskell book we have our own intricate web of templates, far less sophisticated than yours, that allows us to change the TOC and have it reflected everywhere with (almost) just one change − and I'm really glad it exists. The more books can benefit from similar features through a generic implementation the better. Two extra comments:
  • One feature you might find worthy to implement is grouping. In the Haskell book, the TOC is subdivided in groups of 8-12 pages, and the navigation templates allow you to switch to a page within the same group without having to return to the index, as well as moving to the start of a different group. That can make navigation a lot smoother in large books.
  • Perhaps I'm not thinking straight right now, but by "Or possibly one would have the glossary data in a template, and the glossary page itself would also be generated by extracting data from that template" do you really mean it is feasible to build something like a glossary by doing reverse lookups across a book? The use case I have in mind is a back-of-the-book index of terms. Several times already I have been tempted to create one for Haskell, but the maintenance burden for a large book might become unmanageable. Automated generation would definitely make it feasible, even if, say, it turns out that we would have to request updates manually for technical reasons.
Duplode (discusscontribs) 19:54, 13 July 2015 (UTC)
@Duplode: If there's some sort of "navlist" that lists all the pages in the book, it ought to be possible to go through that list of pages, extract glossary-item definitions from each of them, sort those entries in whatever way one wants, and produce a glossary page. I can think of two possible problems with that. One problem is that for a large book it might exceed some transclusion limits of the wiki software (which is also a potential problem with building a "print version" page; I can maybe see a tolerably doable way around that, eventually). A probably-lesser problem is that if the glossary is really dependent on all the other pages of the book, then the glossary will have to be recomputed every time any page of the book is edited. --Pi zero (discusscontribs) 02:57, 14 July 2015 (UTC)

Status note: I perceive this is a hefty item clearly worth tackling. For scheduling perspective, here are some other items on my "short list".

  • Atm I'm working on adding error-handling robustness features to the wikidialog tools. I see this as a prerequisite to importing wikidialog to en.wb for serious use here.
  • I also feel that, before importing wikidialog here, we should upgrade our common.js file by shifting imported scripts to gadgets (as discussed in a thread further down on this page (here)).
  • We have a major problem on en.wb with the design of our category hierarchy, something that was raised a couple of months ago on QU's user talk (here). I feel like I should probably try to address that problem before getting immersed in the deep design challenges of upgrading the navlist facility.

--Pi zero (discusscontribs) 16:03, 10 September 2015 (UTC)

Annotated Jurassic World Wikibook. Good idea?[edit]

I'm sure you're all aware that the summer blockbuster Jurassic World has just been released. Wikibooks's annotated texts policy states that works annotations for movies can be created here, and the featured status of the Muggles' Guide to Harry Potter suggests that these sorts of companion pieces to copyrighted works are acceptable here, so I was wondering if a book-length scene by scene breakdown of the scientific accuracy, effects, screenwriting, cinematography, etc of Jurassic World, like a movie version of Cliffs or Spark Notes, would be a viable project here. I posted this at the general reading room but it only got commented on by one (admittedly unenthusiastic) editor and I hoped posting it here too would attract some more eyes and comments. Abyssal (discusscontribs) 17:18, 15 June 2015 (UTC)

It all depends on the "educational" content, in general blockbuster movies are not worth speaking much about in regards to creative writing or even the cinematography. This one in particular, Jurassic World, is a very poor example of movie art, its full of cliches and the logic of the script goes out of the window about 30m in. In general it would be better to go about it like we go about biographies, avoid covering contemporaneous subjects since they bring about a lot of emotional baggage... --Panic (discusscontribs) 09:50, 15 June 2015 (UTC)
I'm reposting the above since it got "deleted" without notice even if I got it back from my contribution history it did not appear on this pages edit history... If you made a significant contribution check it out since it may have been a hiccup on the project's servers.--Panic (discusscontribs) 17:49, 15 June 2015 (UTC)
@Panic2k4:. It's because Abyssal posted the question twice. Your original comments are over at Wikibooks:Reading room/General. QuiteUnusual (discusscontribs) 07:31, 18 June 2015 (UTC)
  • Oppose - write a book about the Jurassic era by all means, but content about the movie is more appropriate to Wikipedia or IMDB. (discuss) 23:44, 29 August 2015 (UTC)

Allowing reviewers to move pages while deleting the original page?[edit]

If you've ever patrolled recent changes while I was very active (i.e. 2009, 2010, 2013 or 2015), you've probably noticed that I move pages a lot when I write. I split pages, merge pages and rename pages a lot as I write, since I often come to the realisation, while writing, that this chapter will eventually grow too long or that chapter is too short to be independent. I think allowing reviewers to move pages while deleting the original page would lessen the workload on admins a bit and eliminate the minor and harmless (but annoying) inconvenience of waiting for an admin to delete the page. Kayau (talk · contribs) 08:10, 23 July 2015 (UTC)

I ran into a similar scenario the other day − I messed up a few page moves and left a mess of {{speedy}} requests for the admins to deal with so that I could undo the moves. However, I feel the change you propose is risky, as it effectively would give all reviewers a loophole to delete any page.--Duplode (discusscontribs) 21:20, 25 July 2015 (UTC)
Aye, there's the rub. Move-without-leaving-a-redirect is essentially a limited form of deletion; the power to delete is a big deal; and we hand out the review priv to users here on a fairly relaxed basis. --Pi zero (discusscontribs) 01:26, 26 July 2015 (UTC)
The obvious solution is to have more sysops. Perhaps a round of nominations is in order? (discuss) 23:49, 29 August 2015 (UTC)

Javascript loading[edit]

It seems to me that in the past few weeks (probably the devs have been mucking with the software platform in order to optimize one or another of the ill-advised projects they're working on), en.wb javascript loading has gotten drammatically slower than it used to be. Our common.js makes very heavy use of importScript, which is supposedly inherently slower than using the gadgets extension; in theory there should be only about two places in common.js where that should be resorted to — one for book-specific css, and one for page-specific js. As some point in the reasonably near future, unless somebody objects, I hope to try to convert most of those import-scripts to gadgets. Fortunately this should be mostly straightforward to do, as we have a very well-organized common.js; once this operation is completed, we should have an almost empty common.js. --Pi zero (discusscontribs) 12:37, 2 September 2015 (UTC)

Digressive question: Lately I have noticed that in some days parts of the interface behave oddly - for instance, accept a pending revision sometimes led me to a separate confirmation page instead of just displaying the "Done, accepted!" message withing the review box. Do you think both phenomena are related? --Duplode (discusscontribs) 03:26, 3 September 2015 (UTC)
@Duplode: In the case of that particular effect, where sighting a page leads to a separate confirmation page, I believe the answer is "yes", it's definitely related. The pattern I've observed is that if the software hasn't finished loading all the javascript stuff when you sight, it takes you to a separate page. When (if, but I'm really hoping when) I import my dialog tools here, this effect will be more obvious, because the interactive elements on a page — mostly text input boxes and buttons — won't be formatted correctly until javascript is finished loading. My dialog tools include a template {{dialog/ifsupported}} that can hide those interactive elements if they're not supported; when I first roughed out my design I thought that template would only be for obscure situations like if the user is using a twenty-year-old browser or has javascript switched off, but lately, with the javascript performance of the wiki platform tanking, I've found it necessary to use the template on any interactive element that appears on a page designed to be viewed outside of a dialog (it's not a problem once you've started a dialog, because then the software is already in place and doesn't have to be reloaded, making everything faster — something else I didn't anticipate, I thought the dialog tools were going to be subjectively slower than the wiki platform). --Pi zero (discusscontribs) 11:02, 3 September 2015 (UTC)
@Pi zero: Whoa! The slowdown is quite dramatic indeed, given that I am able to compare the diffs, decide that the revision is OK and accept it before the javascript finishes loading... --Duplode (discusscontribs) 01:32, 5 September 2015 (UTC)
I've been observing in recent days that sometimes the javascript doesn't load properly at all; it doesn't just take a long time, it stops without completing. Which I can tell because one of the more visible gadgets I have turned on does not appear. Which is quite upsetting to me since my wikidialog tools can't function without their javascript element, and I'm hoping they could be of immense value here once I port them over. --Pi zero (discusscontribs) 16:10, 10 October 2015 (UTC)

Proposal of Wikibooks interwiki plolicy[edit]

Some policies and guidelines seem to need rewriting. As Wikibooks for Wikimedians guideline says "Wikibooks pages don't contain as many links as Wikipedia articles" and it also says "External linking should also be exercised sparsely.", "Wikibooks uses wikilinks conservatively". What these sentences mean? It's not clear at all.

When you refer to Wikibooks Manual of Style, you see a draft page which is stale, not clarifying Linking method clearly. It just guides you to Editing Help Page. Again you see nothing about conservatively using interwikis to other projects.

I think these kind of guidelines should be rewritten or even be converted into policies. --Doostdar (discusscontribs) 06:02, 2 October 2015 (UTC)

@Doostdar: To me, the guideline you linked to is quite clear. Interwiki and external links should be used sparingly because "a book is supposed to be a self-contained resource with a contiguous narrative". That means links pointing to pages outside of the book should be used in the way references or further reading suggestions would in a traditional book. That contrasts with how wikilinks are usied in e.g. Wikipedia, in which readers are expected to jump from one article to the next in order to get the whole picture. Implicit in this explanation is that the guideline is indeed an editorial guideline, and so it probably shouldn't be converted into a policy.--Duplode (discusscontribs) 20:37, 3 October 2015 (UTC)
You are falsifying the text. It's said that "external linking" should be exercised sparsely. How did you inferred that "Interwiki and external links" should be exercised sparsely? There is no problem with linking inside the books but using interwikis, i.e linking pages/book pages to other Wikimwdia project such as Wikipedia, Wikiquote, ... --Doostdar (discusscontribs) 14:28, 4 October 2015 (UTC)
The wording could be improved. Duplode's understanding of that passage is the same as mine; but in the next paragraph "external" means "outside the wikimedia sisterhood". There's lots of room for confusion of terminology re links; when you said "interwiki" I thought of the links on the left-hand navigation bar to closest-equivalent pages on other-language Wikibooks projects. --Pi zero (discusscontribs) 14:38, 4 October 2015 (UTC)
Note that Wikibooks for Wikimedians is not "guideline" like you stated, only an informative text and so more volatile, the same is true to Wikibooks Manual of Style that if I recall correctly failed to obtain support to even be proposed as a guideline (in a time that things where done in a more protocolar way).
I think you should feel free to update Wikibooks for Wikimedians in light of the current discussion and attempt a merge of versions in the Wikibooks Manual of Style after you included you proposal in the latest draft without any standing objection. --Panic (discusscontribs) 07:05, 5 October 2015 (UTC)
You want to say that there is not any guidelines or policies on how to use interwikis. That's exactly the same as what I told you. We need a guideline for interwikis. I'm a user with less than 100 edits in this wiki. That's why I asked you to propose the guideline. --Doostdar (discusscontribs) 07:51, 5 October 2015 (UTC)
I disagree that we need a project wide guide for interwikis (I do so based on the same notions for why I also dislike the notion of a project wide style guide). I would only not object to establish a sitewide avoidance (not a ban) on wikidata use, that is, it would be seen as automatically beneficial (non objectionable) any edits that reverted or removed wikidata dependency without any further discussion. --Panic (discusscontribs) 08:34, 5 October 2015 (UTC)
Wikidata is something like Wikicommons but for data. Who can say that it is bad that interwikis be transfered into a sepaerate project? --Doostdar (discusscontribs) 09:15, 5 October 2015 (UTC)
No, Wikidata isn't like Commons for data. With Commons, it's mostly easy to tell here if things have been seriously screwed up there, by looking at the overtly displayed pictures visible here — and even so, the fact that they're on a separate project can cause problems. There are, at least in theory, a couple of advantages to keeping all the images in a common area — keeping just one copy saves space for what are apt to be quite large files, and image copyright is a specialized area of expertise that can (in theory, as I say) be concentrated in one place without everyone on every project having to know all about it. Modifying pictures is fairly difficult, too, which discourages subtle defacement. Wikidata has none of those advantages and greatly exaggerates the disadvantages; it's simply, from a sisterhood-wide infrastructure perspective, a really bad idea. I've met a bunch of the folks over at Wikidata, and most of them are great people; and that has no effect on it being a bad idea to automatically import stuff from Wikidata to the other projects. I've gone into other aspects of the problems elsewhere; I see there's a thread about Wikidata currently at the general reading room, for instance. A phrase I used there was "maximizes damage-potential from the central location while diminishing both human control and human scope of the dependent locations (I'm an advocate of semi-automation and opponent of automation [...])." --Pi zero (discusscontribs) 11:28, 5 October 2015 (UTC)
All these are not good excuses for lack of a clear intrwiki policy in Wikibooks. At least different Wikibooks versions should know how to connect with each other. Now at Persian Wikibooks, for example, I've made a book on Latex named "لاتک". Is it correct to link it with the book named Latex in English Wikibooks or not? If yes, what about the sub pages of these two books?--Doostdar (discusscontribs) 19:53, 7 October 2015 (UTC)
You are, as I understand, talking about the "interwiki" links that appear on the side nagivation bar of each Wikibooks page, providing the nearest equivalent to that page in various other languages. (En.wb has the navigation bar on the left, fa.wb has it on the right.) That's different from the en.wb guideline you linked at the top of this section, which was about "wikilinks" that appear in the body of a page.

For the interwikis on the navigation bar, do what you believe would be most useful. If you believe the most useful fa.wb interwiki from our page LaTeX would be to fa:لاتک, then do that. If you believe the most useful en.wb interwiki from fa:لاتک would be en:LaTeX, then do that too. The same criterion — usefulness — seems applicable to subpages. I would suggest that, as long as the interwikis are useful, it's better to provide more of them. --Pi zero (discusscontribs) 02:37, 8 October 2015 (UTC)

If the book is under generic labeling (that the title simply states the subject, like Nanotechnology) it should be ok to interwiki with other books on the subject depending on how the other wikiprojects are organized. For instance, if we take it backwards, on our newest named projects, we try to not to block or overshadow other works covering the same subject, and so we use more creative/descriptive labeling for projects and a subject page that lists all the related local books and other wikiprojects' content. So adding an interwiki directly to those books is not necessary as also adding that subject link on other wikiprojects should be preferred. Doing otherwise is not prohibited (adding any metadata is always better), but it should be preferred as it would be counter productive for the organization effort being done and in making space for diversification, even as to make us more clearly distinct from wikipedia articles. --Panic (discusscontribs) 02:53, 8 October 2015 (UTC)
Even though these rules seem to be good guidelines but they don't involve of all books. Not bad for beginning phase of interwiki development. --Doostdar (discusscontribs) 17:07, 8 October 2015 (UTC)

Wikijunior search, navbar[edit]

It's been suggested, by User:Barry Desborough, that when viewing pages on Wikijunior, search should be of Wikijunior rather than of the whole of Wikibooks. At least as a default that sounds to me like a good idea. Just at this instant, I have only speculations about how one might accomplish it, though. Does anyone else have notions of ways to do it?

(Btw, it occurs to me one might also wish to customize the left-hand navbar on Wikijunior; there too, I don't immediately know how to do it and invite suggestions.) --Pi zero (discusscontribs) 23:51, 8 November 2015 (UTC)

Short of making Wikijunior a sister project in its own right (my preferred solution), Wikijunior pages could, by defult, all include a Wikijunior search box {{Wikijunior search}} as featured in the Wikijunior "home" page,
If there is a specific Wikijunior template, or Wikijunior-specific section of a universally used template, this could be included there, but I'm not yet familiar with how templates are used in Wikijunior. --Barry Desborough (discusscontribs) 15:01, 11 November 2015 (UTC)