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.


Navlist[edit]

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)

Really hoping to get the low-level error-handling support done before end-of-year (admittedly challenging with the distractions of the coming week). --Pi zero (discusscontribs) 12:58, 23 December 2015 (UTC)
Awesome Interesting concept. I look forward to implement it somewhere. I'll be revising the sources and providing some feedback later. Any help needed? Keep up the good work! --Vito Francisco 21:55, 26 December 2015 (UTC)
Progress report: Efforts to apply the dialog tools in practice keep showing up needed upgrades, which I've continued to make over the past several months; I do believe it's in much better shape than it was. Along the way I got others to test it on a mess of browsers and platforms I don't have access to myself, which uncovered a bug, now fixed. The tools have so far shown themselves robust enough that they keep functioning even when most other javascript on the wiki fails, though I haven't quite decided whether to be pleased that my code keeps working or disconcerted by the intermittent failure of other core functionality such as the collapsing of the legend on RC.

My long-range hopes/expectations for use of the tools also keep ratcheting up, which tends to slow things down. I envision the tools eventually allowing interactive assistants to integrate with an interactive meta-assistant — that is, an interactive assistant for assisting in the creation and maintenance of interactive assistants. That's a tall order, and as with any other kind of assistant, lots of practical experience with the task is needed to know how it can be assisted — in other words, building assistants is a necessary step toward building a meta-assistant. I could guess I'm still a month or more away from starting to port to Wikibooks, but that's only a guess at a lower bound. --Pi zero (discusscontribs) 01:18, 17 April 2016 (UTC)

The scope of Wikibooks — Wikilore[edit]

There is a proposal at Meta to form a new sister, "Wikilore", for the purpose of capturing vanishing regional folklore. The question has arisen as to whether it would be more appropriate to host it on an existing sister project; the two mentioned have been Wikisource and Wikibooks. (One always wants to ask, when someone proposes a new sister, whether it would be more appropriately hosted by an existing sister.) I have pointed out that we do host books about works of fiction, such as Muggles' Guide to Harry Potter. However, this leaves a question about another part of Wikibooks scope policy, on which I'd really like to hear from other members of the Wikibooks community. This would be, as I understand it, a way of capturing oral folklore before it disappears. That means there would have to be some sort of means used to authenticate the material. It seems to me that whether or not this is within scope for us would depend on what we collectivley think of the means of authentication: it would not automatically fall under "original research", because the prohibition on original research is primary focused on preventing people from writing books about their own theories, and this isn't about people's own theories, rather it seems meant to record material that is independent of the person documenting it. Thoughts, anyone? --Pi zero (discusscontribs) 23:53, 19 January 2016 (UTC)

Can't they do "Wikilore" at Wikia? --Atcovi (Talk - Contribs) 01:12, 20 January 2016 (UTC)
Yes they could, although the same is true of every project. The question is really does this proposal fit in the scope of an existing Wikimedia project or should a new one be created? The proposers may end up going to Wikia if they get turned down by the community. QuiteUnusual (discusscontribs) 11:49, 22 January 2016 (UTC)

A textbook on regional folklore is acceptable and is in scope of Wikibooks. It doesn't seem that dissimilar to, for example, Indian Mythology (see this page). I note your point about authentication and believe you are correct that the original research restriction is intended to stop people writing about their theory on UFOs rather than forcing everything to be cited. QuiteUnusual (discusscontribs) 11:49, 22 January 2016 (UTC)

WSBN[edit]

Wikibook Standard Book Number

A unique book identifier similar to the International Standard Book Number (ISBN).Appears to have multiple benefits including creation of 'Restore points' below and machine readability Balaji.md au (discusscontribs) 04:50, 24 January 2016 (UTC)

I point out there's a pre-existing thread about this in the general reading room, WB:Reading room/General#WSBN?. That discussion has branched out to other things, yes, but also contains some thoughts re WSBN. --Pi zero (discusscontribs) 12:22, 24 January 2016 (UTC)

Restore Points (Editions)[edit]

Ability to see a Wikibook as it was at a given point in time and various implementations of this scheme. A retrospective, user-generated 'edition' for all Wikibooks. This could aid in citations of Wikibooks' content Balaji.md au (discusscontribs) 04:50, 24 January 2016 (UTC)

@Balaji.md au: I'd recommend posting your points here: Wikibooks:Reading_room/General#WSBN.3F. —Justin (koavf)TCM 05:02, 24 January 2016 (UTC)
I thought this was the place for improvement proposals ;). Balaji.md au (discusscontribs) 05:03, 24 January 2016 (UTC)

Cookbook[edit]

Subproject Cookbook contains content which is different from other contents of Wikibooks. How about seperating it from wikibooks? --Doostdar (discusscontribs) 17:54, 1 March 2016 (UTC)

I know of no disadvantage to having it here, and frankly I think it is an advantage, since it allows the administrative infrastructure of Wikibooks to efficiently serve Cookbook along with the other books here. --Pi zero (discusscontribs) 22:47, 1 March 2016 (UTC)
In many languages such as Persian the Cookbook has enough pages to be a seperate project. --Doostdar (discusscontribs) 03:40, 2 March 2016 (UTC)
When you say "enough pages to be a separate project", you seem to be supposing it would desirable for it be a separate project. I've already given a reason, in my preceding remarks, why it would be more practical to have them be a single project than to separate them, which also implies that separating them would be undesirable. --Pi zero (discusscontribs) 04:08, 2 March 2016 (UTC)
The structre of cookbook is different from other books here. By the way in my experience in Persian Wikibooks users who edit cookbook usually are uninterested in other parts of the project. Cookbook pages may not be part of class projects and are not used by Wikiversity. They can usually have interwikis while usual books don't. --Doostdar (discusscontribs) 05:55, 2 March 2016 (UTC)
Some thoughts.
  • Books have different structures from each other; Wikibooks is by its nature a collection of smaller projects each of which has some of its own character. Books have higher-level structure; Cookbook has less than some books, but more than most projects — more than Wiktionary, Wikipedia, Wikinews. The sort of books hosted on Wikibooks have different assembly rules than Wikinews or Wikisource (on the strict side) or Wikiversity (on the permissive side). But Cookbook is a pretty good fit.
  • If folks come here and are only interested in one book, that's not a problem; it'd be great to get them interested in other parts of the larger project, but failure to do so doesn't provide any sort of motive for sending it elsewhere.
  • Other books sometimes do have interwikis. That too varies from book to book, and greater success of one book than another in multilingual sharing does not seem to me to be any reason to separate projects. Here again, I simply don't see that the one (density of interwikis) has anything to do with the other (common administration).
Frankly, any time things have enough similarity to be handled under a single project, they should be. There are cases where it really isn't practical, where the administrative considerations are genuinely different enough in structure that it makes sense to keep them separate (something that some of the more insular Wikipedians just don't get); but when there's no need for separation, shared infrastructure is desirable. --Pi zero (discusscontribs) 13:09, 2 March 2016 (UTC)
Requests for new projects are made at Meta:Proposals for new projects, not here. However, given that Wikibooks already relies on a tiny number of admins and the global sysops to just about keep things under control, I strongly support Pi zero's view that splitting it would be a mistake. The Cookbook is a target for mass copyright violation which is difficult for global sysops to deal with; splitting it off would likely create a festering pile of vandalism and illegal content with nobody to curate it. Even if that wasn't the result, I can't see how it gains anything from being split. QuiteUnusual (discusscontribs) 12:23, 3 March 2016 (UTC)

Proposal to globally ban WayneRay from Wikimedia[edit]

Per Wikimedia's Global bans policy, I'm alerting all communities in which WayneRay participated in that there's a proposal to globally ban his account from all of Wikimedia. Members of the Wikibooks community are welcome in participate in the discussion. --Michaeldsuarez (discusscontribs) 14:45, 18 April 2016 (UTC)

Template:RC allows to filter the recent changes by category[edit]

This new template (inspired from the Wiktionary) displays one category pages evolution.

  1. Should we add it into a drop down menu?
  2. Would you be in favor of its deployment into every category?
  3. With {{CategoryTOC}}?

JackPotte (discusscontribs) 18:33, 30 April 2016 (UTC)