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 (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.
Done, as of 23:45, 16 January 2018 (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)

Categorizing individual pages[edit]

The time has come (I recommend) to work out how we want to do this; we want to get it right. Afaik we've wanted a good way to categorize individual pages for years, and were bogged down by a category infrastructure that served its purpose but got in the way of doing more; now that we've finished a year and a half of overhauling the existing infrastructure so that we can move forward (see previous thread), we don't want to get stuck with individual-page handling that doesn't do what we want and would take another humongous effort to fix. As background, before explaining what I envision and what we need to decide, here's what we now have:

We have two main kinds of organizational pages:

  • Book categories. A book category contains the pages of a particular book. For a book with main page <title>, the book category is Category:Book:<title>.
  • Subject pages. A subject contains books (not individual pages of books). Subjects are arranged in a hierarchy; each subject has one or two parents, except the ancestor of all subjects, Subject:Books by subject, which has no parent. Subjects are sort of like sections of a library. (The facility that subjects replaced, historically, was called "bookshelves".) The main page of each book, <title>, uses a special template, {{subjects}}, to name subjects that the book should be filed in (usually only one or two subjects, though more are possible; template {{subjects}} is internally quite complicated, btw, but the point is to hide all that so it's very simple to use). For each subject page Subject:<name>, books that file themselves in that subject belong to Category:Subject:<name>.

So the major categories have a prefix, either Book: or Subject:. That's really handy for keeping track of what kind of category you're looking at. I propose we do the same for the new categories that classify individual pages, and use a template on each page to file it appropriately. We need to make at least a couple of choices, to do this.

  • Should these categories be for books and individual pages, or just for individual pages?
I favor both, so that each category corresponds to a topic, making it analogous to an article on Wikipedia, topic category on Wikinews, etc.; thus, these categories would be natural targets for incoming wikilinks from other sisters.
  • What should these categories be called: what prefix should be used, and what template name for filing?
We could use prefix "Topic:" and template name {{topics}}; there's a danger users could get confused between "subjects" and "topics", though. I had considered "Keyword:", but it's been suggested that is too syntactic whereas I think we're after a more semantic classification; or "Tag:" but apparently that would collide with other usage on the platform (indeed, there is already a standard template called {{tag}}). So I'm having trouble coming up with a really good name.

On the technical side, it may make sense to modify the subject-hierarchy facility so that books in a particular subject can be automatically classified in certain of these more-inclusive categories (whatever they're to be called). --Pi zero (discusscontribs) 21:02, 17 January 2018 (UTC)

First off, I definitely think that individual pages can be categorized on a by-page basis. Two examples immediately come to mind: let's say that you have a textbook on a broader topic that includes a page on a more narrow topic which itself also has a textbook (e.g. A page on Spanish morphology in a linguistics book but we also have a textbook[s] on Spanish). Another is categorizing pages by type, such as Category:Coding examples for all of the textbooks about computer programming which have individual pages which are just code or Category:Math worksheets, etc. I think there is definite value in these. To give an example of the how the latter is useful, imagine if MediaWiki changes how it renders code and there is a better way to make it visible or if someone builds a little tool for randomizing homework questions from a bank and we can deploy that tool across textbooks faster. As to your second question, I'm open to suggestions. Topic was what came to mind immediately but I agree that it seems too ill-defined compared to "Subject" (we had a similar issue with Topic/School/Portal on en.wv...) Plus, there is always the prospect that Flow/Liquid Threads will get deployed here and break a bunch of pages (as happened on en.wv). —Justin (koavf)TCM 09:28, 19 January 2018 (UTC)
I'd wondered about the variety of namespaces at wv.

The examples of per-page categories you mention are more technical classes of pages; we could do those, certainly, and perhaps we should, but I suspect they're yet a different type of category (more of an "internal" sort of thing). I've had in mind semantic per-page-or-book categories that would be natural sister-links to/from Wikipedia articles etc. They would share some of the advantages of en.wn topic categories. Two advantages in particular come to mind:

  • Sister links, incoming and (of course) outgoing: Each Wikinews topic category has outgoing wikilinks to Wikipedia (almost always), to Commons (usually), and sometimes to Wikiquote, Wikivoyage, etc.; and of course the category is also a suitable potential target for incoming sister links from those pages. When I set those up, though, I rarely provide an outgoing sister link to Wikibooks, because I can't easily choose one target here that corresponds to the Wikinews category.
  • In-project wikilinks: The more a project uses project-internal wikilinks, the more it feels like a coherent project (in the old days, almost all wikilinks in the body of a Wikinews article were to Wikipedia, and that made Wikinews feel more like an appendix of Wikipedia than like its own project, whereas with a "real" project like Wiktionary or whatever, readers in the mood to explore can spend an extended browsing session just clicking from one page to another within that project without ever being dumped into another such as Wikipedia unless they choose to); so the project needs to have as wide a range of targets as possible. We have a template {{w}} at en.wn that doesn't just link to Wikipedia: it first checks to see if the target exists in Wikinews mainspace, and if so it links locally, otherwise it links to Wikipedia; which over time has allowed the project to feel much more coherent.
I deplore Flow, which I see as an example of the Foundation trying to go in diametrically the opposite direction from what is best for the volunteers and sisterhood (other examples being VisualEditor and some aspects of the implementation of Wikidata). At en.wn we use liquid threads (LQT) — only for our "opinions" pages, where readers discuss the topic of an article; we all "love to hate" LQT, but agree that for that one purpose it actually works better than wiki markup which most readers don't know (more's the pity), and we'd far rather LQT than Flow even for that purpose. My hope is that, with a bit more experience in how to effectively use wikidialog, we can implement semi-automated tools to assist wiki-markup-based discussions, making both Flow and LQT irrelevant. --Pi zero (discusscontribs) 13:11, 19 January 2018 (UTC)
Visual editor isn't bad. It is useful for wikipedia, and perhaps only wikipedia.
Im thinking of categorization of the ones that are ok. Then others can be case-by-case. Some pages could be both marked.
Artix Kreiger (discusscontribs) 14:37, 19 January 2018 (UTC)
Of VisualEditor: I consider WYSIWYG to directly undermine the human foundation of wikis, because (I maintain) wikis are a successful thing thanks to wiki markup, and people learn wiki markup by seeing how other people's wiki markup is written, but WYSIWYG is all about preventing the user from seeing how things are done underneath. --Pi zero (discusscontribs) 14:55, 19 January 2018 (UTC)

Subjects and sections[edit]

  • One approach would be to rename the existing "subject" hierarchy to something else, and reuse the Subject: space for the purpose. It'd be a bother to do, but it could be done — it's a highly uniform mechanism and I understand it thoroughly — and once done it'd be done. There are nomenclature advantages for both kinds of pages:
  • The name "subjects" for the existing hierarchy has always been a bit odd; how about calling them "sections"? When explaining them I tend to say they're like sections of a library.
  • The non-hierarchical groupings of pages are organizationally much more like the physical dead-tree subject catalogs that were ubiquitous in public libraries prior to the twenty-first century. (The old dead-tree subject catalogs were superior, btw, to most of the electronic catalogs that have replaced them, because those old catalogs had been crafted by hand over time in a very wiki-like way; but I digress.)
--Pi zero (discusscontribs) 21:05, 3 February 2018 (UTC)
That seems like a reasonable scheme. —Justin (koavf)TCM 05:26, 4 February 2018 (UTC)
A snag occurs to me. Atm the standard template on a book main page to file it under subjects is called "subjects". If that gets renamed to "sections", the name may make people think of sections of the book. Perhaps a different name for the template... --Pi zero (discusscontribs) 12:05, 4 February 2018 (UTC)
Such as {{library}}... ---Pi zero (discusscontribs) 12:07, 4 February 2018 (UTC)
Brainstorming about terminology. This renaming can be done, but it's not a small operation, so once we commit to it we're likely to live with it for quite a while. In the old system, from before subjects, the root page was Wikibooks:Departments, and the subdivisions were called bookshelves. It does bother me some that "section" is so generic it can be used to refer to a part of a book. "Department" sounds to me like a top-level subdivision of the entire library. "Shelf" is good in that it has high recognition value as a grouping above the book level, but it sounds odd to have one "shelf" contained within another "shelf". We can't use "collection" because it's been preempted. --Pi zero (discusscontribs) 14:19, 5 February 2018 (UTC)
Also worthy of mention: stacks. --Pi zero (discusscontribs) 19:05, 5 February 2018 (UTC)
(Looked around a bit for a good picture of library stacks,
Library Stacks (8145376020).jpg
having spent many happy hours in such places.) --Pi zero (discusscontribs) 19:11, 5 February 2018 (UTC)

I'm now leaning strongly toward prefix Shelf:, which seems likely to have instantly graspable meaning. Instant recognition of intended meaning seems to be the top priority for this. The oddity of one "shelf" being a subset of another is something one can just get used to. --Pi zero (discusscontribs) 19:42, 6 April 2018 (UTC)

Whether to reuse Subject: for the other purpose, or use some other prefix, is a decision we'd have time to consider, while the renaming of the existing hierarchy from subject to shelf was underway. --Pi zero (discusscontribs) 19:45, 6 April 2018 (UTC)
I agree if we merge them with Category:Wikibooks bookshelves. JackPotte (discusscontribs) 20:51, 6 April 2018 (UTC)
@JackPotte: Afaik, the organizational information in the old bookshelves is contained within the current subjects hierarchy. What do you have in mind when you say "merge"? --Pi zero (discusscontribs) 23:18, 6 April 2018 (UTC)
For example, to move Wikibooks:Greek bookshelf and Subject:Greek language, which have basically the same content, into Shelf:Greek language. In this particular case, there will be nothing but the history to get from the old bookshelf, but it may be worth comparing their contents, before closing this maintenance task, telling that the list is moving since 2009. JackPotte (discusscontribs) 04:20, 7 April 2018 (UTC)
Ah! Yes, I see. --Pi zero (discusscontribs) 12:56, 7 April 2018 (UTC)
I'm giving some thought now to details of page nomenclature. Presumably the categories — whose names are especially critical, as they need to be very lucid when they appear at the bottom of each book main page — would have names like Category:Shelf:Mathematics. However, there are at least three choices for the primary information page associated with that category (corresponding to the previous generation's Subject:Mathematics):
  • Shelf:Mathematics. This however is a root page in mainspace, with implications to think through carefully.
  • <bookname>/Mathematics, where <bookname> is the name of a book containing all the shelves; we might also want to have such a book even if its pages were to use prefix Shelf:.
  • Wikibooks:Shelf:Mathematics, which would exclude it from mainspace searches.
Some observations about these.
  • Because Shelf:Mathematics is in mainspace, it would be included in a general search of mainspace; that might be a good thing. One could do a search of pages with prefix Shelf: just as one would a search within a book. Because it is a root page in mainspace, it would become a potential result for the Random book navigation link; is that a good thing? We would want to wire {{BookCat}} to do the right thing, whatever we decided that is.
  • For a bookname, we would want something short and self-explanatory so it wouldn't be burdensome for the names of the subpages, but also something self-explanatory as a book name. For example, we wouldn't want to call the book Shelf because, although it might be tolerably clear what a page Shelf/Mathematics is supposed to be, it wouldn't be clear what a book called Shelf is supposed to be. The same goes for Shelves and Shelving, either of which one could just about imagine using as the name of a how-to book for home organizers. Likely the best choice, for standalone self-description, would be either Wikibooks Shelves or Wikibooks Stacks, which is slightly longer, and has no length advantage over putting it in project space instead of mainspace: Wikibooks:Shelves or Wikibooks:Stacks.
  • I'm not enamoured of using project space, as Wikibooks:Shelves or Wikibooks:Stacks. That would exclude those pages from a generic content search, and I'd rather include them in a content search.
One thing I would not want to do is to create a new namespace, such as was done for Subject:; that seems to me to just complicate the project infrastructure in a cumbersome way. --Pi zero (discusscontribs) 15:48, 7 April 2018 (UTC)
My current inclination is to set up the pages in mainspace using prefix Shelf:, with {{BookCat}} wired to categorize them in a hidden subcategory of Category:Book:Using Wikibooks. The current template {{subjects}} would, I suppose, be replaced by (or, morph into) one called {{shelves}}. --Pi zero (discusscontribs) 17:06, 7 April 2018 (UTC)
Personally I could treat several pages, but I don't want to choose for you if you intend to treat the hundreds of them, like you had done for the books categories.
Nevertheless, I would draw your attention on the facts that:
  1. a book containing all the shelves will take several hours to be built and synced, while been redundant of {{Category tree}}. That's why if it was just for me, I would rather delete the subjects and shelves pages (but not the subjects categories).
  2. a shelf books content will be impossible to print due to the server technical limits. For example, I couldn't automate Java Programming/Print version in Lua from the TOC, because of an overflow (and it's only 163 A4 pages long). Moreover, a few books had been cut to bypass the different resources limits, like Messier Index/Print Version/1 & Messier Index/Print Version/2. I notably remember a limit with Special:Book too.
  3. Wikibooks:Shelf:Mathematics would be counterintuitive because we don't usually publish the content into this namespace, and it won't be able to filter the shelves only. So a dedicated namespace would be the ideal solution for the search engine. We just have to include the "Shelf:" namespace in the default searches, and anyone will be able to uncheck it into Special:Search.
  4. But I don't think that a shelf in the random pages would be irrelevant.
Thank you for your attention. JackPotte (discusscontribs) 13:43, 8 April 2018 (UTC)
Sounds like we're largely in agreement. One remark re namespace usage: agreed shelves are rather too contentful for project space, the same seems to me true for category space. It's one thing to copy the shelf presentations into categories (we do this now for subject presentations, and went to some trouble to make it happen), but that's not the same as having the presentations primarily reside there. --Pi zero (discusscontribs) 00:23, 9 April 2018 (UTC)


One nuance, as I start to map out implementation details on this. At the very top of the soon-to-be-shelf hierarchy are a few pages that logically don't appear to be shelves. In the old bookshelf regime, the root was Wikibooks:Departments, and each page directly below it was a "department" rather than a "bookshelf". It's possible to make allowances for one "shelf" to be a subset of another, up to a point, but there's a scale at which it becomes really hard to imagine a "shelf" containing such a vast array of books. Even in the dedicated Subject: namespace, those top two levels of pages —the root and its children— are treated differently, in that they don't use {{Subject page}} and aren't supposed to ever have books directly filed in them. In the more recent discipline, there has been no enforcement of the principle of not filing books in the top two levels of subjects, as putting all those pages in a separate namespace naturally creates a sense of uniformity between what had been distinguished as "departments" and "bookshelves". However, in moving to give the lower echelons prefix Shelf:, one doesn't want to use that prefix for the pages at the two top levels. A likely solution is to treat those top-level pages as modules of a book. The shelves themselves would not be treated as pages of the book, though it would still make sense to file them in a hidden shelving category under the book category.

Re JackPotte's note that "a shelf books content will be impossible to print due to the server technical limits." If we want to generate a print version, it seems to me there should be no insurmountable technical problem generating a print version of the small book I'm describing, consisting of a splash page, departments page [maybe or maybe-not distinct from the splash page], and pages for the individual departments (but not the shelves). Although, I'm unsure whether we would care about a print version, since the book is something of an organizational device (reminiscent, in that regard, of "book" Engineering Tables). --Pi zero (discusscontribs) 14:24, 15 April 2018 (UTC)

Template renamings[edit]

Checking here before doing the following renamings of some magic-word-like templates; unless I get early opposition, I mean to move ahead quite soon.

  • rename Template:FULLBOOKNAME to Template:NAIVEBOOKNAME
  • rename Template:BOOKNAME to Template:NAIVEBOOKSTEM
  • rename Template:ROOTBOOKNAME to Template:BOOKNAME

This even looks strange to me, when put baldly like this.

For years we have had two sets of magic-word-like templates for decomposing page names, with clashing naming conventions.

The first set of templates were created in late 2007, with the names BOOKNAME, FULLBOOKNAME, CHAPTERNAME, and FULLCHAPTERNAME. Likely these were intended to provide more book-oriented decomposition of page names than the built-in magic words that are generic to any wiki. Imho the only one of these that really did quite what it said was CHAPTERNAME.

A second set of templates were created starting in mid 2009, based on the idea of templates that orient to the book associated with a page (not only if the page is in the book, but if it's an associated category or template). The first of these was called ROOTBOOKNAME, only because the name "BOOKNAME" was already in use. This set has continued to grow, a particularly important one recently being {{BOOKCATEGORY}}; but it has been a continuing thorn-in-the-side that the name BOOKNAME was occupied by an older-style template.

In recent times I worked out that FULLCHAPTERNAME was really a device for producing a book sort key, and renamed it to {{BOOKSORTKEY}}. Nothing needs changing about CHAPTERNAME. Over the past few days, I've eliminated all (but one) use of the old BOOKNAME. We generally don't delete old infrastructure, we just mothball it or in some cases history-merge it; and I wouldn't care to merge the histories of BOOKNAME and ROOTBOOKNAME as they overlap and would produce a confusing mess, so I figured to shunt the old BOOKNAME aside to a name that wouldn't do any harm, for which I have suggested NAIVEBOOKSTEM. I do think NAIVEBOOKNAME is a much more accurate description of what the old FULLBOOKNAME template does. And "BOOKNAME" really is a much more natural name for the thing currently being called "ROOTBOOKNAME". --Pi zero (discusscontribs) 19:28, 21 January 2018 (UTC)

For what it's worth, I certainly have no objection if you want to do the work. If you need help, please ping me. —Justin (koavf)TCM 05:47, 22 January 2018 (UTC)
This has now largely been Done ; The main vestige of the old naming, at this point, is uses of redirect "ROOTBOOKNAME", which I am slowly changing to "BOOKNAME". --Pi zero (discusscontribs) 15:55, 24 January 2018 (UTC)
good work. Artix Kreiger (discusscontribs) 16:14, 24 January 2018 (UTC)

Transclude related Reading Rooms[edit]

At present (see the banner at the top of this page), we have several Reading Rooms in three broad categories: Discussions, Assistance, and Requests. I propose transcluding these into three larger pages. Since en.wb does not have very much activity, having so many conversations spread across many pages makes it less likely that anything will be seen. For an example of how this would work, see s:en:Wikisource:Scriptorium (which transcludes a /Help subpage) or w:en:WP:CFD (which transcludes the /Speedy deletion page). They can still remain separate pages but once they are transcluded into one, it will increase visibility for any one conversation. —Justin (koavf)TCM 19:52, 4 February 2018 (UTC)

At Wikinews we used to transclude all the water coolers into one big page. It never worked well. If the parent page was unprotected, people would post things onto the parent creating a confusing muddle. If the parent page was protected, the same people would claim they were prevented from posting. In any case, the only way people are likely to see discussion threads, and additions to discussion threads, is if they have all the relevant pages on their watch list, and transclusion onto a parent page only creates more confusion in that regard.

So I'm not convinced it'd be advantageous. --Pi zero (discusscontribs) 21:45, 4 February 2018 (UTC)

The protection method seems to work on Wiktionary. Just have really big "CLICK HERE TO ASK FOR HELP" and "CLICK HERE TO PROPOSE A POLICY" at the top. Seems to work there without any problems. We can also make a notice in case someone hits "View source" by accident. —Justin (koavf)TCM 05:33, 7 February 2018 (UTC)

Change from comma-based article counting[edit]

In light of recent events (described below), this community needs to discuss whether it wants to change the way content pages are "officially" counted on this wiki.

First, some background on "article counting": As described at mw:Manual:Article count and mw:Manual:$wgArticleCountMethod, MediaWiki-based wikis like this one have three possible ways of counting "content pages" (historically called "good articles" and now usually just called "articles"). All three counting methods require that a page be in a "content namespace" and not be a redirect in order to be counted as an article. The wiki may be set up to also require that the page contain at least one [[wikilink]] (the 'link' method) or at least one comma (the 'comma' method); otherwise all such pages are counted (the 'any' method). (BTW, the single-quotes are intentional, since single-quotes are used in the [large] configuration file that stores the relevant settings — search for the text "ArticleCountMethod" to see.)

This wiki uses the 'comma' method and has 3 content namespaces: the main namespace (which needs no "prefix" in front of page titles) and the "Cookbook:" and "Wikijunior:" namespaces. Therefore, the count of "content pages" on this wiki (which I will continue to call the "article count", mainly out of habit) nominally includes all non-redirects in those three namespaces that contain at least one comma. I say "nominally" because, in fact, what I just said is not actually true. (!) Allow me to explain…

Many bugs related to article counting have been found and fixed in the MediaWiki code over the years, but this wiki has (probably) never been recounted to fix the article count itself. This is mainly because the two maintenance scripts that are run to fix on-wiki statistics (which are called initSiteStats.php and updateArticleCount.php) do not actually implement the 'comma' method at all; instead, for performance reasons, they simply check for positive page length (in addition to the usual non-redirect and content-namespace criteria). Since April 2015, the second script (to recount only articles) has been run on the 21st of each month in order to keep the article counts more-or-less correct, even if relevant bugs remain in the code. But all Wikibooks wikis have been excluded from the periodic recounting because the English and Portuguese Wikibooks use the 'comma' criterion (and are the only Wikimedia wikis to do so — FYI, the Czech Wikinews, Chinese Wikinews, Gujarati Wikisource, Polish Wikisource, Serbian Wikisource, Serbian Wikiquote, and Wikidata use the 'any' method, and all other Wikimedia wikis use the 'link' method).

It appears that the 'comma' method is correctly implemented when pages are saved (i.e., created or edited), but that's laregly irrelevant if the article count itself has become very wrong because of past bugs. In any case, it doesn't matter anymore, because…

On February 15th and again on February 21st this wiki was recounted using the initSiteStats.php script. What this means is, the current article count no longer reflects the comma-based criterion, nor is it possible at this point to fix it (anytime soon) so that it accurately reflects the comma-based criterion (because there is no maintenance script to recount it in that way).

As reported at m:Wikimedia News#February 2018, the article count of this wiki changed from 57,843 (about 18 hours before the February 15th recount) to 79,075 (up to 6 hours afterwards), a 37% increase. Presumably the same thing would have happened if the 'any' method had been used, since there are no zero-length pages here. (Note that the "live" article count is 79,756.)

So, now we find ourselves in a situation where the current article count of this wiki is (approximately) "correct" with respect to a different criterion than the one we have assumed was being used to count articles here. This count may tend to drift a bit as the wiki is edited (since page-saves still use the 'comma' criterion), but it will never match the true 'comma' based count unless someone writes some relevant code and gets it approved for use. (This may be unlikely because searching wikitext for a specific string is resource intensive.) Meanwhile, there are plans to periodically recount all stats on all Wikimedia wikis, including Wikibooks, which would mean that the count here would be periodically be reset to this weird "positive-length" based count, anyway. Although the current count doesn't technically match that given by any of the official, documented counting methods, as a practical matter it approximately matches what the 'any' method would give.

So, should we switch from the 'comma' article-counting method to the 'any' method, since that is essentially the situation we find ourselves in now?

(For additional context, see the discussion at phab:T59788 and the information at m:Article counts revisited.)

- dcljr (discusscontribs) 08:48, 28 February 2018‎ (UTC)

The following two posts appear to account for the current configuration:
--Pi zero (discusscontribs) 02:23, 1 March 2018 (UTC)
It looks as if we decided to switch from links to commas in February 2011 because we deemed links unsuitable here, and then the any option was added later than year. I wonder whether the two events are related. I see the technical suggestion of commas was provided to us at the time by bawolff; @Bawolff: do you have any thoughts on this? --Pi zero (discusscontribs) 13:07, 1 March 2018 (UTC)
Comma count method has been an issue for a long time, as its difficult to recount. I'd reccomend using the any method if the community finds that acceptable. Bawolff (discusscontribs) 22:04, 1 March 2018 (UTC)
Support. Situation clarified; I'm comfortable. --Pi zero (discusscontribs) 18:10, 3 March 2018 (UTC)
Comment . Good to see there's no objections to this yet. Be warned, though, that a decision to remove comma-based counting entirely from the software (phab:T188472) is moving ahead faster that I had anticipated, so if anyone does object to this change, speak now… - dcljr (discusscontribs) 00:49, 4 March 2018 (UTC)

FYI, comma-based article counting has been removed entirely from the MediaWiki software, and this wiki has been switched to use the 'any' article-counting method (phab:T188472). - dcljr (discusscontribs) 03:07, 8 March 2018 (UTC)