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.

Category infrastructure[edit]

I propose some simple upgrades to our category infrastructure, which I think has been recognized as a problem for years. It's been upgraded a few times, and those were improvements imho, but it seems to me things can get a whole lot better with this next step I'll describe below. The two basic problems are that  (1) the current system is confusing, and  (2) it underrepresents the content of our books, which reduces the ability of readers to find relevant information and reduces the ability of other projects to provide sister links (for example, if Wikinews or Wikipedia or Wikiquote has a page about Barack Obama, they can't readily provide a sister link to Wikibooks because our category infrastructure doesn't support having a page like that).

So here are my ideas, all of which would be implemented in an incremental way that wouldn't break anything during the transition (I'm confident that can be done, and would see it through):

  • Book categories would have prefix Book:, and subject categories would have prefix Subject:.
Thus, the nature of every such category would be instantly apparent. For example, right now book European History has book category Category:European History and belongs to subject category Category:European history, which is confusing both when setting up the categories and when looking at the categories; as an admin, I've often had to untangle the results when people misunderstand how it all works. Under the new arrangement, these would be Category:Book:European History and Category:Subject:European history.
  • In addition, I suggest we have categories with prefix Keyword:, which are for categorizing page content.
Barack Obama would have a Category:Keyword:Barack Obama. It's important, I believe, to prefix all three kinds of categories, to keep very clear which is which.
  • There should be a template for adding pages to keyword categories, analogous to the existing {{Subjects}} for adding a book to subject categories.
Once we have that infrastructure in place, the task of populating the keyword categories will be simply an incremental thing that happens over a long period of time; I expect the process will get distinctly faster when, after a while, we get dialog-based semi-automated assistants on-line to help guide users through the tasks involved.
  • The list of subjects at the bottom of the main page of a book should link to the subject pages, not to the subject categories.
We've wanted to fix this for years; I can think of at least two possible ways to fix it, and mean to undertake that along with these other upgrades.

--Pi zero (discusscontribs) 15:19, 30 June 2016 (UTC)

I'd really like some feedback on this. Despite the smooth transition I envision, it's a significant change, and I wouldn't feel right moving forward on it entirely unilaterally. I'm willing to wait (heck, I don't think I would have been able to get started on it yet even if I'd been bowled over with enthusiastic responses when I first posted this); but really clarity about what others think on this is better to hear sooner than later. --Pi zero (discusscontribs) 13:03, 25 August 2016 (UTC)
On the French Wikibooks we had voted a few years ago, not for a "Book:" prefix but for a " (book)" suffix (provided by {{BookCat}}). The subject categories had remained unchanged. So I could test this a while with Wikidata, and my conclusion is that there is no uniformization, sometimes the Wikipedia category is linked to a subject one, and sometimes to a book one, because when it's the only book of the subject, nobody creates a second redundant category. Moreover, here we are talking about thousands of categories, so I hope that you have some free time ;)
Concerning the "Keyword:", I was one of the firsts to use it for themes (hypernyms), but it has been cancelled for now. What about a categorizing template like {{k|Barack Obama}}?
But to sum up, the only point on which I would really disagree with you, would be to keep the "Subject:" pages, because I find these lists too much redundant with categories, and more painful to maintain. JackPotte (discusscontribs) 18:16, 25 August 2016 (UTC)
Atm the subject pages are the only reason there's any order at all in the system; they're spectacularly not redundant. The categories are hopelessly confusing, exactly because you can't tell by looking at a category whether it's a collection of pages of a book, or a collection of books. We keep having to fix books whose classification by subject is messed up because a book-category is being mistaken for a subject-category. Fortunately we have a system in place so that problems of this kind automatically get flagged out for us; but with the changes I'm proposing the problem wouldn't happen in the first place.

If we kept the existing categories as they are and also added in categories for collections of pages that aren't necessarily in the same book, the whole thing would be profoundly worse.

However, it would all work smoothly if we introduce an iron-clad, instantly recognizable naming scheme. Which is what I'm proposing to do.

A prefix, with a colon, is absolutely unambiguous ("iron-clad") and is the first thing you see when looking at a category name (because English is read from left to right, of course). A suffix "(book)" doesn't work nearly as well; we have a few of those, for situations where our stop-gap naming convention fails to distinguish between the name of a book and the name of a subject. Moreover, if you look at the list of categories at the bottom of a page, and those categories have these prefixes on them, you'll know instantly exactly what all the things on that list are.

I've had practice with vast structural rearrangements like this. Such things can be done, and can be done smoothly. The fact that it has to be done on each of about 3000 books just means it has to be lined up carefully so that it can then be done gradually, with very simple changes at each book that don't require a lot of thought and aren't going to be done wrong, and everything will keep working right while the gradual change is going on. Often this means doing it in multiple stages, where each stage has to be finished before the next begins. If we want to phase out the subject pages as a separate namespace, the way to not get tangled up in that is to do everything else first, and leave that as a separate stage, to be undertaken only after the rest of it is complete. --Pi zero (discusscontribs) 19:15, 25 August 2016 (UTC)

@JackPotte: Trying to sum this up: We need a clear, straightforward action plan. I'm offering one. I'm willing to implement it. And, honestly, if we find something about it really doesn't work, we can change it later — in fact, after doing this I expect another change will be easier because I'll already have done it once. In particular, as I said, if we want to eliminate the subject pages after the categories have been straightened out, that's cool. But I need some sort of go-ahead before I can proceed. Are you okay with seeing me move forward on this, given that I'm willing to do it and that the things I do can be revised later? --Pi zero (discusscontribs) 17:24, 28 August 2016 (UTC)
@Pi zero: you have my blessing, but it's typically a bot job, and I can't see any bot belonging to you. As I would like to avoid to waste your time, may I suggest to transform Wikibooks:Desired bots to something we could link to d:Q4582561? Then we would be able to post these specifications and to share the tasks or the scripts to do them. JackPotte (discusscontribs) 18:12, 28 August 2016 (UTC)
Re bots, the thought is appreciated, but I don't like bots. I really don't. It's not just a personal preference, I disapprove of them philosophically. Wikis should never be maintained by an unthinking entity; the human touch is what makes wikis precious. If I already had my semi-automation tools ported here from Wikinews (which I don't; I'm not satisfied with them yet), I could imagine semi-automation for this, and indeed I have hopes that in the long run almost everything now done with bots can be handled by semi-automation, but for now I have in mind to do things by hand. Which has one beneficial effect: it guarantees my action plan will be simple, and that everything will remain in a consistent state while the work is in progress, because those things have to be true in order for it to be done by hand. Honestly, editing 3000 pages isn't scary; you just need to make sure there's a way to know what has and hasn't been done, and if you do just 64 a day, a month and a half later it'll all be done. (Semi-automation might allow you to do it all in a week or less.) --Pi zero (discusscontribs) 18:37, 28 August 2016 (UTC)
(I may, indeed, be able to devise a way of doing it so I don't have to directly edit the book pages at all, at least for most of the changes involved; that would be ideal. The previous set of infrastructure changes was feasible exactly because Wikibooks was already using {{subjects}}.) --Pi zero (discusscontribs) 19:53, 28 August 2016 (UTC)

Subject category renaming[edit]

I think the first challenge I'll take on is adding prefix "Subject:" to the subject categories. It's occurred to me that all these category names appear verbatim in the DPLs on the subject pages (see for example Subject:History), and I'm not sure how I feel about all those book titles having "Book:" prefixed to them. Perhaps I just need to get used to the idea. I've been aware for years that there are lots of situations where one really wants to snarf a DPL and then somehow further process the results, which the DPL extension doesn't support at all. I have in mind to semi-automate it using my dialog tools once they're deployed but for now that's not yet an option. --Pi zero (discusscontribs) 14:40, 4 September 2016 (UTC)

An advantage on your new system would be to automatically display {{Book search}} into the books categories only. JackPotte (discusscontribs) 07:05, 22 September 2016 (UTC)
Good idea. --Pi zero (discusscontribs) 09:04, 22 September 2016 (UTC)

Update: I've just been planning out the subject-categories campaign. As best I can figure, besides the categories themselves there are five key pages involved: Subject:Books by subject, {{Root subject}}, {{Subject page}}, {{Allbooks category}}, and {{Subjects}}; each of the five is transcluded on about two or three thousand pages (mostly, subject/category pages and the main pages of books). My basic plan is,  (1) modify the templates to support/populate the new as well as the old cats, and create the new ones;  (2) once the new cats are all available, modify things to use the new ones; and  (3) dispose of the old cats, not forgetting to do history merges when appropriate. --Pi zero (discusscontribs) 16:14, 27 October 2016 (UTC)

Steps (1) and (2) appear to be complete. (3) is going to take a lot of time and meticulous effort, because it will require manually addressing the subject-categorization of every book, and book category, on the project (all 5966 — or so — of them). I can't really begrudge the labor, though, because most of it actually goes fairly quickly: the reason it's time-consuming is that it flushes into the open lots of pre-existing categorization errors, which then have to be fixed. So the whole project is going to be much better categorized by completion of this phase. --Pi zero (discusscontribs) 04:23, 1 November 2016 (UTC)
I've disposed of 1/4 of the old subject categories. I'm rather encouraged about the infrastructure aspect of this; the most awkward/peculiar cases in the project are necessarily turning up and taking time-and-effort to fix, but it's all sorting-out that would need to be done for the next, and much larger, operation of renaming to book categories. Demonstrating that the larger plan is fundamentally coherent, as one phase aids the next. It's also so much easier to work with a mixed set of categories once you can tell at a glance that certain ones of them are subject categories, I'm quite encouraged about the wisdom of the larger renaming scheme. --Pi zero (discusscontribs) 20:17, 12 November 2016 (UTC)
1/2 now. --Pi zero (discusscontribs) 23:31, 23 November 2016 (UTC)
60% --Pi zero (discusscontribs) 21:59, 2 December 2016 (UTC)
70% --Pi zero (discusscontribs) 03:38, 6 December 2016 (UTC)
80% --Pi zero (discusscontribs) 23:16, 9 December 2016 (UTC)
90% --Pi zero (discusscontribs) 16:34, 16 December 2016 (UTC)
Done renaming the subject categories.

My sense, after that effort, is that the even larger effort to rename the book categories is just too large to undertake until I can bring semi-automation to bear on it; so I expect to put any near-future Wikibooks time into dialog/assistants. --Pi zero (discusscontribs) 23:37, 19 December 2016 (UTC)

@Pi zero: This can probably be done with a bot that has admin rights. —Justin (koavf)TCM 04:17, 20 December 2016 (UTC)
I wouldn't care to try it with a bot. Every case is likely to be different, requiring careful human attention. I hope I can use it as a test case for "growing" a semi-automated assistant, though. That wouldn't happen immediately, but I think separating the subject categories, which is now done, was the more urgent task. I'd rather put overhead effort into the semi-automated route rather than the bot route, because the effort into the semi-automated route also benefits future assistants. --Pi zero (discusscontribs) 04:30, 20 December 2016 (UTC)

As a simple step to move things forward, I'm considering setting things up so that each subject category page recreates the content of the corresponding subject page. (I meant to set up {{subject category}} so that it would support this if the subject page wanted to cooperate; in theory, it should be just a matter of modifying {{subject page}} and {{root subject}} to provide the necessary content.) --Pi zero (discusscontribs) 11:25, 7 March 2017 (UTC)

I've done this. All the subject categories should now mirror the full layout on the corresponding subject page; if any of them don't, ping me. --Pi zero (discusscontribs) 05:35, 18 April 2017 (UTC)
Lessons learned from this operation: A useful test case for the sort of thing I'd like a meta-assistant to be able to help with. A large operation (though just within range for a single person to do manually), mostly repetitive but with occasional customizations required that seem to require a human being to recognize them. I imagine an admin conjuring up a meta-assistant, which then guides them through the process of setting up an assistant for the operation, at each step helping them to recognize and usefully provide information that the human operator should have in order to realize when a particular case wants customized treatment; and flexibility to handle such a case in a partly or entirely manual fashion, informing the manually intervening operator of what the uncustomized behavior would be and making it easy to get back into the semi-automated part of the operation once that manual intervention has been completed.

(Why am I so concerned with aspiring to meta-level support? Because I think we have gotten ourselves into a bad place by focusing so much on accomplishing specific tasks that we neglect the vital need to empower ordinary volunteers — the sort who should not be asked to deal with anything technical beyond wiki markup — to take charge of choosing what specific tasks should be done and providing the know-how for how to do them. Imho this is the sort of misfocus that has driven the Foundation's major software initiatives, leading to an ongoing shifting of infrastructure out of reach of ordinary volunteers. --Pi zero (discusscontribs) 15:15, 18 April 2017 (UTC)

Book category renaming[edit]

I've somewhat revised my thinking about the size of the task of migrating the book-category names to use prefix Book:. Although it needs, I think, to be done slowly and carefully, it is probably not entirely beyond manual size. For any given book category, most of it can be achieved — but, often creating a mess that needs immediate attention by a human being — simply by renaming the book category (and its subsidiary categories) without leaving redirects, because {{BookCat}} and {{BOOKCATEGORY}} will figure out the move and recategorize accordingly. The mess comes with all the places where the old book-category naming conventions are hardcoded in, instead of using {{BookCat}} or {{BOOKCATEGORY}}; for example, this will probably turn up just about every case on the project of a book-specific template whose name doesn't start with the name of the book. For each book category renamed, one will have to carefully check for pages still belonging to the old category or its subcategories, and and also check for incoming links to the old category and its subcategories; and the templates will need to either be modified to use {{BOOKCATEGORY}}, or be renamed to use the book name and use {{BookCat}}. Renaming the templates will usually be desirable but a lot more work, and is a point where semi-automated assistance might be useful but it would actually be a pretty sophisticated task for an assistant. Anyway, I've got the basic support built into {{BookCat}} and {{BOOKCATEGORY}} now, and have set up one book category with the new naming convention, to start shaking the bugs out of the system. --Pi zero (discusscontribs) 13:07, 19 April 2017 (UTC)

I'm not sure how this is going to play with the TODO mechanism (which I've never used and don't know how works — though I imagine I'll be figuring it out now since I find myself with a need to know). --Pi zero (discusscontribs)
The TODO thing turned out to be not difficult, btw.

As a matter of general edification, here are (recent) numbers of book categories under the old and new scheme; as best I can reconstruct, when I started the number of extant book categories was 2813, with two new ones created before I started tracking this here (I was going to have these generated automatically, but I don't trust magic word PAGESINCATEGORY, and besides, if I occasionally update this by hand it'll make a permanent record of the dates in the page's revision history):

2200 --> 637
--Pi zero (discusscontribs) 23:23, 24 April 2017 (UTC) – 17:30, 10 July 2017 (UTC)

Here are some notes on how to do these renamings; I've been gratified to find several other Wikibookians have pitched into help, so thought I'd share these notes here:

  • Moving a book category, say from Category:Garthok Narfling to Category:Book:Garthok Narfling, does not immediately cause the wiki software to move the pages from listing under the old name to listing under the new name.
  • If the pages of the book use templates that automatically detect the name of the book category, then the pages themselves will (after a few seconds) report that they belong to the new category; that is, the new category is listed at the bottom of the page. However, looking at the new category, the page is not listed, and looking at the old category the page is listed. This is because the wiki software generates the list on the category pages from an internal cache that is only updated either when the page is edited, or when a template used by the page is modified, or if you wait long enough eventually the wiki software should notice the change; I think there's a message somewhere that claims the software should get around to noticing these changes within about a month.
  • To do a null edit on a page, call up an edit panel on your browser, and pick the "publish" button without making any changes. That should cause the wiki software to update its cached categorization of the page. Sometimes it takes a few second for the cache to update; and occasionally I find it necessary to do a second null edit. Remember, this won't help if the page itself doesn't claim to be in the new category rather than the old one.
  • There are three general-purpose templates that detect the name of the book category. The main page of a book should always use {{subjects}}. Subpages ordinarily use {{BookCat}}; occasionally they use {{BookCat|filing=deep}}. The third template that detects the book category name is {{BOOKCATEGORY}}; some pages directly or indirectly use that for categorization. There are also some books that have book-specific templates that categorize the pages that use them, and those book-specific templates should use one of the general-purpose templates.
  • If the book category has subcategories, they have to be dealt with too.
  • There is a loose naming convention, not always observed, that subcategories of a book category should be named by the book-category name followed by a slash and a suffixing name. For example, the canonical name for the category of templates for book Garthok Narfling would be Category:Book:Garthok Narfling/Templates. If subcats use that convention, they need to be renamed when the parent category is renamed. Admins have an advantage here because the wiki software gives them an option, when moving a page, to move all of its subpages (up to 500). If the subcat uses {{BookCat}}, it will recategorize itself automatically. Often the category page needs editing to name its book correctly, usually via {{ROOTBOOKNAME}}; for example,
This category contains templates used in the '''''[[{{ROOTBOOKNAME}}]]''''' book.
Pages in the subcat have to be induced to be relisted from the old subcat to the new one. If the subcat doesn't use this convention, one can either modify the subcat using {{BOOKCATEGORY}}, or move the subcat to use the convention. For example, a subcat Category:Garthok Nafling stubs might be left in place, with code [[{{BOOKCATEGORY|Garthok Narfling}}]]. I usually leave most subcats in place, but usually rename template subcats and image subcats.
  • Templates don't always use the naming convention Template:<bookname>/<subname>. If they don't, the template needs to be categorized using something like
[[{{BOOKCATEGORY|Garthok Narfling}}/Templates]]
Images always need treatment like this, since they never have names of the form File:<bookname>/<subname>.
  • If a book has templates, it makes sense to deal with them first, since if the template should happen to need modification in the process, that would cause the wiki software to update cache of all the pages that use the template. (This rarely works, but once e.g. I was able to avoid null-editing pages of a thousand-page book one-at-a-time by tweaking a template that was used on almost all of the thousand pages.)

--Pi zero (discusscontribs) 23:48, 22 June 2017 (UTC)

How to attract new authors ? Do we need a new rule ?[edit]

Let them know that they can sign their books, that they can refuse unwanted changes and that wikibooks can be cited in the appropriate Wikipedia articles.

For this I want to place links from Wikipedia to wikibooks, but I would prefer that the books are signed. Also, if some authors of Wikibooks wanted to make a come out, identifying themselves as authors or coauthors, this would help us to make Wikibooks known and to attract new authors. Thierry Dugnolle (discusscontribs) 12:03, 28 April 2017 (UTC)

@Thierry Dugnolle: See WB:OWN. --Pi zero (discusscontribs) 12:08, 28 April 2017 (UTC)
Such a rule contradicts the usual practice on Wikibooks. Completed books usually have one or a few more or less identified authors. It is natural. There has to be a strong will for a book to be completed. That Wikibooks have authors does not prevent them from working cooperatively, between authors, and between authors and readers. See [1] (in french). This is why I think the rule you mentioned is obsolete and should be removed. Thierry Dugnolle (discusscontribs) 12:33, 28 April 2017 (UTC)
WB:RFA is another proposal. See Wikibooks talk:Respect for authors for a vote on this proposal : An author can refuse unwanted modifications. Thierry Dugnolle (discusscontribs) 22:18, 28 April 2017 (UTC)
@Thierry Dugnolle: As far as I can tell, what you are proposing is not "usual practice" on Wikibooks, but instead a radical contradiction the nature of Wikibooks. --Pi zero (discusscontribs) 00:33, 29 April 2017 (UTC)
It is usual practice in the french-speaking Wikibooks community, may be not in the english-speaking one. If you're right I will never be again a nuisance on the english-speaking Wikibooks, I will remain in the french-speaking Wikibooks community, which is, according to you, in radical contradiction against the nature of Wikibooks. --Thierry Dugnolle (discusscontribs) 00:53, 29 April 2017 (UTC)
After reading parts of this discussion on several different pages I still fail to clearly understand what the idea of what Thierry Dugnolle is proposing. I understand that he is asking for a clearer directive on the process of editorial control, but haven't seen any write up of the process or clarification to the roles on those involved. Under American law (the one the wikimedia projects are under) authorship can be hard to define and has less rights over their creations than for instance, as I understand, under French law that more than protecting the authors rights protects his reputation (in regards to rights over use and alteration/re-composition of his work that would impact is good name or be contrary to his will).
I would support and have previously attempted to make things clearer. I think that local project/book communities should be clearly empowered over the global community of the aggregation in regards to their works. This is something that more important in the projects like ours, where individual works try to be self consistent and are often independently curated and can and should provide active individual creators a reputation and recognition for the hard work done as well a level of protection (but not create dictators) as to enable them to freely express their creativity over the long process that is creating a book. To abstract and simplify we must find a middle ground between having the capability of attracting highly regarded and recognized experts as authors or ultimately devolve in outsourcing the creative work to zoos and have a large enough troop of monkeys type random content into the project and hope that the general community bothers to filter it and refine it over time. Panic (discusscontribs) 02:44, 30 April 2017 (UTC)
The same for me : I fail to clearly understand what you are proposing.
I want to say to future authors : if you declare yourself as responsible for the wikibook you write, you have the right to refuse unwanted modifications - except modifications required by the common rules and enforced by administrators. Is it unclear ? And do you disagree ? Thierry Dugnolle (discusscontribs) 02:57, 30 April 2017 (UTC)
@Thierry Dugnolle: Authorship in Wikibooks is a subtle matter, as indicated by the very name of the project. "Wiki" implies aggregation, while "book" implies organic unity. There should be both openness to outside input and space for authors to develop their visions. Shifting the balance decisively towards one side or the other would change the character of the project. My stance on your proposal, or on what kind of middle ground there might be between it and WB:OWN, isn't fully settled yet. For the moment, I will only suggest the possibility that, if there is a certain ambivalence in our policy and practices about authorship, that might be for the best.
(If you would like a better idea of where I'm coming from, you might want to have a look at this long, rambling essay in my userspace. While it is not strictly about authorship, it touches on a number of issues relevant for this discusstion.)
Duplode (discusscontribs) 04:30, 30 April 2017 (UTC)
Do you think the new rule is bad and should be rejected ? --Thierry Dugnolle (discusscontribs) 10:10, 30 April 2017 (UTC)
So I made an argument largely about the importance of shades of grey for this discussion, and noted that my stance about your proposal isn't fully settled yet, and the first thing you ask for in reply is a yes-no answer... In any case, the comment above was of a more general nature. I will add more specific views about your proposal to its talk page, to make the discussions a little easier to follow. (In fact, I have just added an extra bullet point there.) --Duplode (discusscontribs) 23:33, 30 April 2017 (UTC)
Forgive me If i was too sanguine on the subject. I'm waiting for your contributions to this debate and won't request your answer any more. --Thierry Dugnolle (discusscontribs) 13:56, 1 May 2017 (UTC)
No worries. I just think it is a good thing to take my time and debate an important change before crystallising my views in a vote. --Duplode (discusscontribs) 19:44, 1 May 2017 (UTC)

There needs to be clearer process overall. Even when I go to the first book on the front page I cannot convert to pdf a familiar appearing format. It does not look like a book. I would gladly write a book if it appeared like a book on WikiBooks. —Preceding unsigned comment added by DrTobias (discusscontribs)

@DrTobias: There are presses which make more pleasant PDFs and there are CSS alternatives as well. What would you like to write for us? —Justin (koavf)TCM 03:48, 26 June 2017 (UTC)

New Lua template: Template:Footer[edit]

Hello, I've just developed {{Footer}} to replace the many fastidious manual templates we have into Category:Navigational templates, such as {{B3D:N2P/NAV}} or {{Python Programming}}, which should be carefully filled during their deployments and updated after every TOC modification.

I want to deploy it in my books, and allow to customize more options like the arrow pictures, the frame color, and the possibility to add a header similar to this footer. As it doesn't need any parameter, we would even be able to deploy it like {{BookCat}}, embedded into one book-specific template. What do you think? JackPotte (discusscontribs) 01:15, 12 June 2017 (UTC)

This seems distantly related to the {{navlist}} facility I developed a while back and deployed on Conlang, which I know has since been used on a few other books, and which I've been grumbling about upgrading (for one thing, I was thinking of using a more user-friendly format for the navlist).

I don't understand what yours does. Where does it look for the table of contents? The book's main page? (I dislike using Lua for anything specific if one can possibly avoid it, of course, but, whatever.) --Pi zero (discusscontribs) 02:20, 12 June 2017 (UTC)

It's just fully automatic from any of our TOC (like this one), so the Lua couldn't been avoided (unless we enumerate a certain number of cases... from a special TOC template). Actually I didn't find your templates before, and I couldn't imagine their existence, even if I had tried this kind of experience before with an inconclusive result. JackPotte (discusscontribs) 07:39, 12 June 2017 (UTC)
@JackPotte: Navlist was last discussed, afaik, in a thread here now archived at Wikibooks:Reading room/Proposals/2016/April. --Pi zero (discusscontribs) 17:08, 12 June 2017 (UTC)
The problem is that Navlist needs to rewrite all the TOC in a complex way, whereas Template:Footer works with the standard TOC (the bulleted lists like on Wikipedia, so no need to touch them) in a few Wikibooks (French, Spanish, German...).

Today, I propose an automatic header with the same skin on Template talk:Programming/Navigation. JackPotte (discusscontribs) 21:20, 29 August 2017 (UTC)

I've pointed out, several times at this reading room as I recall, that (by using {{evalx}}) we could now upgrade navlist to use whatever syntax we wish for the toc, and I have solicited input on what syntax people think would be best for the purpose, but I don't recall anyone ever offering any such input in response to my requests therefor. Meanwhile, over the years I have come to mistrust the idea of an instant-single-point-of-failure page controlling the entire navigational structure of the entire book, and if one does have such a page I think it's better to have it be a template, set apart from the main page of the book. The instant-single-point-of-failure problem is a smaller-scale version of the same problem as using wikidata to generate interwiki links, something for which I do have a better alternative to suggest but do not yet have an implementation of that alternative. --Pi zero (discusscontribs) 21:45, 29 August 2017 (UTC)
Understood, but my Lua module is not a god object and just utilizes the available information to do automatically and instantaneously what should be done manually, in order to avoid the duplicate code antipattern. Moreover, it doesn't crash if we insert some strange things into the TOC but ignore these lines. JackPotte (discusscontribs) 21:52, 29 August 2017 (UTC)
Redundant data storage is not always an instance of the duplicate code antipattern. Or, putting it another way, single-point-of-failure is also an antipattern, especially in the wikis. What you do want, with redundant storage, is something to aid in tracking coordination between related elements. Just saying. --Pi zero (discusscontribs) 01:16, 30 August 2017 (UTC)
Personally I can't bear to update each linked page when deleting every day: this is the longest part of the process and it could be avoided. JackPotte (discusscontribs) 09:37, 1 September 2017 (UTC)
Indeed. I did conclude, at some point, that the real need in the long run is for wiki-driven interactivity, so that the users on the wiki can readily arrange to make that procedure easier to do. Hence my long-term pursit of dialog. --Pi zero (discusscontribs) 10:52, 1 September 2017 (UTC)

Cookbook and WikiJunior namespaces in search results[edit]

Hi. I discovered that the namespaces for Cookbook and WikiJunior are not part of the search results on Special:Search when you are in the default mode of "Content pages". This seems accidental and/or undesirable to me. Please indicate in ticket phab:T170473 if your community would like to have this corrected. TheDJ (discusscontribs) 20:25, 12 July 2017 (UTC)

Favor JackPotte (discusscontribs) 21:12, 12 July 2017 (UTC)
Support Especially since if you are looking up the sort of thing that is likely a recipe, you won't be looking for it in most textbooks or manuals and vice versa. I would object if I thought there would be a lot of confusing returns but this is more likely to be helpful than harmful. —Justin (koavf)TCM 22:10, 12 July 2017 (UTC)
Support Absolutely. Strange it wasn't already so. --Pi zero (discusscontribs) 22:45, 12 July 2017 (UTC)

Category infrastructure (continued)[edit]

I'm starting a new thread for this. I started the original thread just over a year ago; by making a clean break, the old section can be allowed to age and be archived. (Automatic archiving of this page is currently set for a "mere" four months.) Here's a summary of what's happened so far:

  • The basic proposal was to use prefixes on most category names, so it's clear what they are; we've had confusion for many years now over whether a given category is a book category or a subject category, and the difficulty of keeping track of which category is of what sort is probably why we've never even tried to have topic categories that could be used to classify book pages as well as books as a whole. I suggested subject categories should start with Subject:, book categories with Book:, and those other categories with some other prefix such as Keyword:. The third part is the most unknown territory, but it would also be the last thing done, so I figured there was no urgency yet about figuring it out.
  • I also hoped to get wikidialog running on Wikibooks, and perhaps use it to help with some of these other infrastructure changes.
  • Within the first half year after starting the topic here, I did get the subject categories renamed, and took advantage of the more uniform structure to make the subject categories echo the classified book lists of the subject pages themselves, so that when you click on a link to a subject category, it's pretty much just as useful as being taken to the subject page itself. I also got the dialog tools installed here, but the real challenge of dialog turns out to be learning how to use them to build assistants ("wizards"), and that is an on-going exploration being done elsewhere, so not all that much has been done here with dialog even though it's available.
  • Almost exactly three months ago as I write this, I started on the renaming of book categories. To start with there were about 2800 book categories with old-style names, and now there are 2100; so if we continued at this rate it'd take another nine months to complete that phase of the operation. Several other Wikibookians have helped in various ways, which has made a real difference in how fast things have gone. Rate of the current tedious renaming operations may decline over a sustained period, which would seem to make the projected completion of this phase more than nine months off; but then, if some dialog-based semi-automation comes on line at some point, it could greatly speed things up. There are some detailed notes on how to do book-category renaming yonder.

Going forward:

  • My running progress report has experienced a glitch, but I'm starting to get a handle on it again. As I'd originally envisioned the process, book categories would be moved one at a time, with all attendant checks and processing, template {{BOOKCATEGORY}} would make sure category references referred to the old name until the move was implemented for each book, and one category would list the books not yet done while another would list those completed. That worked through more than a third of the books, but then — with all good intentions — almost all the remaining categories got moved, without any of the attendant checks and processing. On 4 October 2017, shortly before that happened, there were 1600 book categories under the old naming convention, and 1259 under the new. Now I've got a list of 1430 book categories that were renamed but still need to be processed, plus another 143 still using the old naming convention, a total of 1573 to go, and 2714 under the new naming convention, indicating 1284 completed. I expect to process the ones in the old-naming-convention category first, and then do the ones on my list starting from the bottom. I don't really have a baseline for whether this will go faster or more slowly than before.
Remaining: 1427+23=1450 out of 2838+23=2861, as of 17:09, 20 October 2017 (UTC).
  • I'm still thinking about the third stage of this operation: keyword categories. The purpose of such categories is the same as the old library card catalogs, that were mostly destroyed around the turn of the century on the (incorrect) assumption that automatic string search would do the job better — customized help with finding what works in the collection are related to what topics, based on considering each individual work. In effect, the old card catalogs were crowdsourced.
  • In the process of all these book category renamings, I find I'm getting a remarkably wide view of our whole collection, even though I rarely get more than fleeting glimpses of specifics. I've long perceived that Wikibooks is a confederation of thousands of ultra-tiny microprojects that have banded together to share a common administrative infrastructure. What they have in common, at least statistically, is more-or-less described by WB:WIW, but of course any given book may be not only different from all the others, but may be different in a way that none of the others are different from each other. If we want to provide help that will improve books across large parts of the whole collection, we have to do it in a way that admits endless variations (in contrast to the more usual technique used by programming platforms, where everyone is required to conform to some uniform structure for which some tools are then provided). A general problem I can see applies to most of the roughly-three-thousand books in our collection is that a contributor doesn't know how to contribute: the book is created with some sort of vision of how the whole is to be organized and what the various parts are to contribute to that whole, but since this is different for each book, how is a would-be contributor to know what to do? There are lots and lots of books in our collection that have a few sections written and then a bunch of red links, and in order to write those missing parts someone will have to create their own vision of what ought to go there. On Wikijunior, it seems to me, the most successful long-term-growth books have quite well-defined formats for each page, such as Wikijunior:World Religions which has a standard list of questions to address for each religion (in fact, an earlier version of the book basically stalled for years because of flaws in the list of questions). Most books don't have modules as uniformly structured as that, of course.

--Pi zero (discusscontribs) 13:21, 21 July 2017 (UTC)

Thanks for the update. Several years ago I had created some topic categories for pages, but not only. They have been deleted here but on the French Wikibooks, you can admire the example of the database category, which not only contains the DBMS books but the database management pages from the PHP and Python books. This structure suits me and I can't see any relevance to split it with different prefixes like Books subject: and Pages subject:. Moreover, Keyword: looks like a referencing concept which would for example imply to categorize the page translating the term "database" from English to French into [[Category:Keyword:Database]], so the targeted readers would get many false positives (eg: programmers vs linguists).
Concerning Wikidialog I didn't test it but believe that we could adapt ourselves to it, like it's alternative: the JS lib MW:OOjs UI usable in our gadgets. JackPotte (discusscontribs) 16:19, 21 July 2017 (UTC)
  • Regarding "subject" and "keyword" categories, there is a messy problem of terminology mixed up in it, and because of that, it might not be clear what I'm trying to do.

    Many years ago, en.wb organized its books using bookshelves. Like other centralized organization systems I've seen on the wikis, the bookshelves arrangement apparently didn't work out. We later set up a hierarchy of "subject pages", with their own namespace, using DPLs (dynamic page lists), which are updated automatically from categories specified on the main pages of the individual books; and apparently that arrangement, automatically self-updating from specifications on the individual books, caused the bookshelves to fall out of use. (Root subject.) Later I upgraded the subject pages so that they would automatically list not only books in a particular subject, but also all books in any of its descendants in the hierarchy. The whole subject hierarchy, though, is still a means of classifying books, not pages. It is much like sections of a library; you know, science books are on the second floor, physics books are on that floor in the three aisles closest to the north stairwell, etc. I've sometimes regretted that we use the name "subject" for these hierarchical groupings of books, because it means the word "subject" isn't available for us to use to refer to anything else. I wouldn't think it'd be practical to change the name now; it must be hardwired into page references all over en.wb, all over the wikimedian sisterhood, and all over the internet.

    The fact that we don't have categories that correspond to Wikipedia articles (whereas en.wn does have categories corresponding, roughly, to Wikipedia articles) is limiting both to the ability of our readers to find things, and to the ability of our sister projects to provide incoming links to our material. I often find myself setting up sister links from a topic category on Wikinews, and I can't provide a Wikibooks link because there simply isn't any one page here to target. String searches are always lousy compared to searches based on human-generated information about the semantic content of individual resources. There is a problem about what to call these, though. We have several different functions performed by categories here on en.wb, and I find prefixes like Book: and Subject: are enormously effective in making it instantly clear what the functions of particular categories are (I'm extremely pleased by the results of these category renamings, so far), but the question becomes what prefix to use with these categories that could list any content page, not just the main page of a book. I thought of keyword: as a possibility because it's common for academic pages to provide a list of "keywords" describing topics to which the pager is relevant; but those "keywords" are often really key phrases, of more than one word. The word "subject" might be an obvious choice, if it wasn't already taken, since the old library card catalogs were "subject catalogs". The word "topic" comes to mind, but, really, wouldn't it be awfully confusing to have two kinds of categories where one is called a "subject category" and the other a "topic category"?

  • An important part of my purpose in developing the dialog tools is to put all page interactivity under the direct control of wiki markup. This is a very big deal for me, as a matter of wiki philosophy; I see the Foundation explicitly trying to shift focus away from wiki markup and I see that as uniformly bad for the future of the entire sisterhood. I somehow found time to write an essay on that (link).
--Pi zero (discusscontribs) 20:42, 21 July 2017 (UTC)
@JackPotte: Perhaps a better choice that Keyword: would be Tag:. See w:Tag (metadata). --Pi zero (discusscontribs) 15:58, 22 July 2017 (UTC)
Why not? Now let's decide the way to add them, I was thinking about {{BookCat|tag1|tag2}} because it's short and simple.
Another longest solution would be (as {{Tag}} already exists) a dedicated template, and it would be able to bring an anchor to the tag related paragraph. JackPotte (discusscontribs) 19:42, 22 July 2017 (UTC)
@JackPotte: Some time ago when our working plan was keyword:, I see you suggested a template {{k}}. If we use tag:, I predict some people using a template called {{tag}} despite the fact it does the wrong thing; and I wouldn't care to use {{t}} since it's so close to {{tl}}. As for {{BookCat|tag1|tag2|...}}, that template already has a parameter, I forget what it does, and I've been thinking for some time I'd like to find and eliminate all uses of that parameter so I could remove it from the template and replace it with a parameter that works uniformly with our other related templates such as {{BOOKCATEGORY}} — which would still be incompatible with {{BookCat|tag1|tag2|...}}.

Another difficulty with piggy-backing on {{BookCat}} is that it's really not meant to be used on the main page of a book; it's designed to not cause a problem when used there, but the main page of a book is really the only page associated with a book where {{BookCat}} isn't mean to be used; one uses {{subjects}} there, instead (and {{subjects}} is designed to degrade gracefully when used elsewhere, but really isn't meant to be used except on a book main page). --Pi zero (discusscontribs) 22:17, 22 July 2017 (UTC)

Proposal for a book on HTML 5 and CSS3[edit]

I would like to suggest a book start-up about HTML 5 and CSS 3

What would be the benefit in addition to HTML 5 Programming and Web development and Cascading Style Sheets please? JackPotte (discusscontribs) 11:14, 24 July 2017 (UTC)

Add the autopatrol right to the user group "reviewers"[edit]

Hello, when a user becomes a reviewer, he's supposed to be trusted by the community. However the MW:Help:Patrolled edits doesn't take this right from MW:Extension:FlaggedRevs into account, by default.

That's why I propose to add the right "autopatrol" to the "reviewers" group, as it had been made for the administrators and bots. Then, we won't have to mark their new pages as patrolled anymore. JackPotte (discusscontribs) 17:28, 3 August 2017 (UTC)

I don't even know what the autopatrol thing does. I've this vague impression that it does something that's kind of like an earlier/lesser attempt at something similar to what we use the review bit for, and that (consequently?) it isn't used much on en.wb, but, as I say, that's just a vague impression.

What does the autopatrol thing do? --Pi zero (discusscontribs) 19:15, 3 August 2017 (UTC)

@Pi zero: typically if you want to make the page User talk:Tyler.ks disappear from Special:NewPages&hidepatrolled=1, you have to click at the bottom right of this new page, on [Mark this page as patrolled]. And the problem is that the reviewers new pages are treated like the IPs ones.
So, their autopatrol right would just remove the [Mark this page as patrolled] link for them (and I will be able to check the newbies new pages more quickly). JackPotte (discusscontribs) 19:30, 3 August 2017 (UTC)
Ah, I see. So the platform is set up to make it easy to use autopatrol for vetting page creations? Sounds like a fair thing to add to reviewer; sure. --Pi zero (discusscontribs) 21:39, 3 August 2017 (UTC)

Done T172561. JackPotte (discusscontribs) 20:22, 4 August 2017 (UTC)

Automatic Navigation of Individual Books[edit]

Most books on enwikibooks do not have an navigational template. I made a template ({{AutomaticNavigation}}) to automatically show the pages of a root book. I propose adding this template to every book in enwikibooks that does not have a navigational template. |Wikibooks=PokestarFan • Talk • Contributions|#default=PokestarFan • Talk • Contributions}}|Wikibooks=PokestarFan • Talk • Contributions|#default=PokestarFan • Talk • Contributions}}|Wikibooks=PokestarFan • Talk • Contributions|#default=PokestarFan • Talk • Contributions}} 04:30, 9 August 2017 (UTC)

My first thought is that there is no one navigation strategy that would work for all books. Books are not alike, and ultimately it requires human minds to think about each one and custom-choose what to do with each. Perhaps your template, in its current form or some clever variant of it we can come up with — or both — or, for that matter, some other device (or, again, some combination of these things) can cover many books that have no navigation device atm. But I do not think anything can be appropriate for all books that don't current have any navigation template. I'm not so sure there's even anything that can work for most of them.

I did try, once, to build a powerful device that would work for many books, the Template:Navlist suite, and have in mind lately to upgrade it, possibly when I finish some of the category-infrastructure upgrades I'm doing or possibly before then; but even a navlist upgrade raises interesting design challenges, as I've mentioned a bit here from time to time. Alas, I got rather limited feedback from others here about how to upgrade navlist; which is not surprising, because upgrading navlist is a genuinely difficult design problem. It's too much to expect someone would immediately hit on some brilliant idea (it would be nice, though :-).

Some questions/thoughts:

  • What does your template do? It isn't easy to tell, for sure, by looking at the template code, and we would need to write good documentation for it in any case. And we need some practical experience with it in order to get a sense of when it is, and when it isn't, particularly useful, or whether some variant of it would work better, etc.
  • For navlist upgrading, I have at least three thoughts, and would welcome feedback on them.
  • The existing template uses a syntax for the navlist that I think is too clumsy to use generally. But I'm not sure what notation one ought to consider using instead.
  • The whole navlist device (suite of templates) is built around the idea of a single central page that describes the whole structure of the book, but this approach has a basic weakness: it maximizes the potential for damage from one central location, malicious or otherwise. This is of course also a design failing of all manner of directly Wikidata-driven content. More ambiguously, it also means that, because the central page for a book is then actually transcluded on every page of the book, the wiki software will register any edit to any part of the central page (which is a sort of glorified table-of-contents) as forcing updates to every page of the book, which is a modestly-high-server-load operation. I imagine the devs would say this was clearly a bad thing; I can't help feeling ambivalent about it, atm, because I'm about three months in to a roughtly-twelve-month project of changing the book category naming scheme, and it would greatly speed up parts of the operation if there were a trivially easy way to force the serve to purge all the pages of any given book; no doubt the devs would be upset, though.
  • I see to recall JackPotte had recently mentioned some sort of device that did something along these general lines.
--Pi zero (discusscontribs) 12:29, 9 August 2017 (UTC)
Apparently there's a problem with the current {{AutomaticNavigation}} at least into SuperCard Programming.
Moreover, its alphabetical order isn't the best to navigate, I would prefer to include the TOC in a template for it, like on fr:Modèle:ModèleLivre.
Apart from that, I had effectively proposed an automatic Lua navigation template for the book subpages: {{footer}} (in the accurate order from the TOC), but no need to deploy it in all books because their authors should all agree first.
JackPotte (discusscontribs) 12:54, 9 August 2017 (UTC)

What to do with Mathematics Worksheet[edit]

There are a lot of userful math problems, but the book would be better suited if each worksheet were to be moved into a book of it's specific subject (for example Mathematics Worksheet/Algebra/Pascal's Triangle would go to the book/subsection of a book on Pascal's Triangle). PokestarFan • Talk • Contributions 15:08, 25 August 2017 (UTC)