Wikibooks talk:Naming policy/Archive 2

Colon convention and interwiki links
What if someone creates a "cookbook" wiki, and someone adds "cookbook" to Interwiki map? Does this means that all Cookbook links on Wikibooks, like this link Cookbook:Recipes, start failing? That is, do interwiki links conflict with our colon convention? --Kernigh 20:37, 8 November 2005 (UTC)


 * Raises a good point, but i can't imagine anybody naming a new wiki something that doesnt have the wiki-prefix attached. I can see a "wikicooks" or something like that spring up, or a "wikicookbooks" or something. All of the new books that I have been working on all use the forward-slash convention anyway, i think that's the best way to go. --Whiteknight T C E 20:49, 8 November 2005 (UTC)

Our current Interwiki map is bloated. I can do Cookbook and cat. What if someone copies "Cookbook" from the default PmWiki InterMap? (I was surprised to encounter a "cookbook:" wiki, but at least there might not much interest in linking to PmWiki recipes from MediaWiki wikis.) --Kernigh 06:19, 14 December 2005 (UTC)

Colon Convention Usefulness
Could someone explain to me the use of colon convention? I personally think it makes more work for writers, isn't a practice used in other Wikis, and causes a lot of trouble with the MediaWiki software. I like the idea of removing the acceptance of colon convention from this policy entirely. To me, slash notation is a lot cleaner and there's a lot more experience with it by many. If this seems acceptable, I would hope there'd be an effort to refit all existing books, especially Cookbook. Colon notation seems rather obsolete. -Matt 21:56, 13 December 2005 (UTC)
 * I agree wholeheartedly. there are no benefits to the colon convention, and there are benefits to the slash convention. -- 22:32, 13 December 2005 (UTC)
 * I'd like for the section to be removed from the policy then (if more people support it). The real problem is getting all the old books fixed up, but I really think getting this policy moved to "enforced" first is a step in that direction. Some Wikibooks' organization is atrocious (some books have even gone as far as having several of their pages be root right off of wikibooks.org) and I think that to get this site some more respect we need to get it more organized. -Matt 23:30, 13 December 2005 (UTC)


 * The current reason for colon convention seems to be to avoid renaming several existing pages, including the Cookbook pages. However, I do prefer slash convention for books that I edit, and I did mention the conflict with interwiki links in the previous thread. But my one reason for supporting colon convention is that I currently use it in the category and template namespaces (especially as Guide to X11:stub does not match any submodule "Guide to X11/stub"). --Kernigh 06:23, 14 December 2005 (UTC)


 * That is a good point. We could keep the colon convention around for use in templates, because in templates, everything is already in the Template: namespace. -- 15:11, 14 December 2005 (UTC)


 * I agree that Template should stay around (should have specified that since I never wanted it gone to begin) since it is a proper use of the convention. One thing we may want to add to this policy is that the colon convention should only be used by things like templates, but to keep the templates within a structure of their own based on the book. The Guide to X11 is close to an example of what I'd like. It's not just "Template:Xinerama" or something like that but "Template:Guide to X11/Xinerama." It might not be a bad idea to keep the templates structured this way. Is there a problem with that implementation? -Matt 15:33, 14 December 2005 (UTC)


 * With respect to the Cookbook, one reason for using the colon convention is that the book is supposedly supposed to get its own namespace (indicated by "namespace:") and leaving it as-is would relieve any updating of links. When this happens is of course completely up to wikimedia administrators and developers so who knows. Also, unlike other books, the Cookbook has much less structure, so I think most pages would end up just being "Cookbook/Recipe Name" anyway... Kellen T 14:49, 16 December 2005 (UTC)


 * With the cookbook, i can understand it. Cookbook isn't exactly a "book" in the sense that you can't coherently read it in order. Giving Cookbook a namespace helps to keep all the unrelated material together in one place. However, i don't think that we should just give an entire namespace to every little new book that comes along. Few books are going to have the depth and scope that the cookbook has. -- 15:39, 16 December 2005 (UTC)


 * I read somewhere that someone planned for a "Cookbook" namespace, but so far it has somehow never been created. --Kernigh 23:24, 18 December 2005 (UTC)
 * The problem is that only those with developer access to the wiki's PHP can add a namespace, so it's a slow process. Heck, I asked to enable .ico uploading a while back and I betcha that's still not done either... GarrettTalk 23:45, 18 December 2005 (UTC)


 * I have made changes to reflect the recent discussions. Hopefully this will help out the organization here. -Matt 18:33, 26 December 2005 (UTC)
 * Generally, good. Slash convention is much more helpful. -- LV (Dark Mark) 16:00, 28 December 2005 (UTC)

As a FYI, the Cookbook namespace is currently up, and has been, from atleast December 20. Gentgeen 13:04, 2 January 2006 (UTC)

I changed Naming policy so that colon convention would be allowed for Cookbook and Categories, in addition to Templates.

Do we want to allow something like "Category:Bookname/Something". Or should it always be "Category:Bookname:Something"? --Kernigh 03:00, 11 January 2006 (UTC)


 * Since cats have no automatic parent I don't think it matters what is used, as long as it's placed within the parent cat and the implied parent cat actually does exist. GarrettTalk 09:24, 11 January 2006 (UTC)


 * Well, I personally prefer something like "Cookbook:Soup/Chicken Noodle", but that's just me. Unsure about the difference for categories though. -- LV (Dark Mark) 21:54, 12 January 2006 (UTC)


 * Actually, it would probably work best to use colon after anything that is not a namespace, for example "Template:Guide to X11:stub" instead of Template:Guide to X11:stub. Otherwise, the would suggest that "Guide to X11" was the namespace, like with  . (I moved "Wikibooks:Template messages:toc" to Template:Template messages. --Kernigh 04:57, 30 January 2006 (UTC)) In fact, if I created "Template:Cookbook:Development", I probably would not be able to use it. --Kernigh 01:10, 18 January 2006 (UTC)

one way that colons work better than slashes
"colon convention? I personally think it makes more work for writers"

I have found one way that colons work better than slashes. Writers often refer to other chapters of the book. Writers spend less effort and are less likely to make mistakes when they use the pipe trick. But the pipe trick only works when titles use colon or the parentheses. (How do I file a bug report to request that the pipe trick be improved, so that it also works when titles contain slashes?) Because of the pipe trick, take less work than using the slash to write . --DavidCary 17:41, 14 January 2006 (UTC)
 * Sweet Potato Electrical Power Embedded System Basics (see the colon?) or
 * Sweet Potato Electrical Power Embedded System Basics (see the parentheses?)
 * Sweet Potato Electrical Power Embedded System Basics (see the slash and the extra typing?)


 * I agree that pipe trick is a great thing. I'm disappointed that it does not work with slash convention links. --Derbeth talk 19:10, 14 January 2006 (UTC)


 * I would also expect that the pipe trick works for subpages. There is already a bug report for this: . But take into account that subpages also provide shortcuts for brevity, e.g. you can use /Subpage/ which resolves into /Subpage/. ManuelGR 03:36, 15 January 2006 (UTC)


 * I didn't know that. That trick will save me some time. Thank you. --DavidCary 00:44, 18 January 2006 (UTC)

Adding book name to the end?
Inside the movie making manual, check out the category "Category:Writing movies": It's difficult to quickly scan through this page and only read the page titles ("Certification", "Downloading Scripts", "Logline"...), since the linked articles don't begin with this title. Couldn't we add the book name to the end of a book and shorten it, as in "Certification (mmm)", "Downloading Script (mmm)" and so on? Or is there a technical way around this problem, like displaying the alt-name of the category-tag from the linked page? Thanks for any help! Cramer 22:59, 16 January 2006 (UTC)


 * I see. Yes, that's a good argument for the historical "disambiguation convention"  once used in some books (and still used at Wikipedia). Categorization has a few tricks, but don't see any that do exactly what you want. --DavidCary 00:44, 18 January 2006 (UTC)


 * Free Culture uses an opposite format, . --Kernigh 02:13, 18 January 2006 (UTC)


 * Actually, a style like "Certification (mmm)" would make categories easier to read, but it would also make Special:Allpages harder to use. I consider both categories and special pages to be mostly for editors, not readers. I think that slash convention (like Guide to X11/Starting Sessions) is important, because MediaWiki generates a link for readers back to the front page Guide to X11, and many editors otherwise forget to include such a link (consider Civ:The Basics or Energy (GCSE science).) --Kernigh 02:13, 18 January 2006 (UTC)


 * For subpages in categories there is a workaround &mdash; setting the sorting key to the title after the slash. But for the Special:Allpages problem for disambiguation pages there is no workaround. By the way, better that Special:Allpages for books, is Special:Prefixindex. See Special:Prefixindex/Ada Programming/, for an example. This would not work for "Chapter (Book)". ManuelGR 20:39, 18 January 2006 (UTC)


 * Well, it's only a partial workaround - the pages are sorted correctly, but displayed incorrectly. I never use Special:Allpages, but if somebody else uses it, I can feel your concerns. I guess the only way around it is to have a different naming space for every book, like wikicities where every new wiki gets their own domain. Could we implement such a thing here? Cramer 18:40, 5 February 2006 (UTC)

Bad Tactics

 * I have no problem with the concept of coming up with a standard for naming modules, and I am in general agreement with the proposed policy. But I strongly object to placement of banners on modules that appear not to presently fit the suggested naming "rule". These banners are essentially a form of vandalism to the book or module. If they are intended to convey a suggestion (that renaming is in order), then they belong on the discussion page of the module where any information intebnded for contributors is placed. What was one of the real pluses of working at Wikibooks, was the lack of editors with nothing better to do than run around imposing their idea of what is correct on contributing editors work. This phase has apparently ended here. - marsh 19:13, 22 January 2006 (UTC)


 * I don't understand you. It is a common Wikipedia rule to place cleanup messages at front of page, not discussion page. Discussion pages are rarely visited and the purpose of cleanup-NC is to encourage book visitor to help change its naming convention. The template was ment for orphaned books without active contributors, where it's not easy to get help from book authors. --Derbeth talk 21:56, 22 January 2006 (UTC)


 * The problem is that we can't do the changes outself. The police allows for some freedom and it is up the authors and contributors of the book to decide how to structure the book. Also: rename is often uses where we only suspect the page to belong to some paricular book. Take Melon for example. It can't stand on it's own (Wikibooks is not Wikipedia) and it is linked from Nutrition and Edible Plants and could belong to either book. All we can do is mark the book and hope that the authors and contributors take the hint. --Krischik T 07:16, 23 January 2006 (UTC)


 * Inappropriate POV use of cleanup message box. I think that cleanup message boxes should not be used, even on discussion pages, to attempt to enforce a rejected policy or a proposed policy.  The proposed consistent naming policy appears to have lost in previous voting.  Pages should not be marked with official-looking cleanup message boxes to hint to readers that the page is in violation of policy when it is not in violation.  And, especially, a bot should not be used to find and mark such pages as needing "cleanup". KHatcher 13:41, 26 January 2006 (UTC)


 * Excuse me, I'm not a bot, so why do you write about bots inserting cleanup messages? I was marking for cleanup books that had completely wrong naming convention. We were discussing some proposals here, but we all agree that pages shouldn't have titles like "Introduction" and book having chapters "Basic Ecology Contents", "Ecology Introduction", "Ecology: Species and Populations" and "Invasive Species Glossary" are not named properly. There are some generally accepted depreciated naming conventions: "Chaptername" and "Book Chaptername", which shouldn't be used. I think in such cases inserting cleanup message is a right decision. --Derbeth talk 17:44, 26 January 2006 (UTC)

Icelandic Wikibook, naming conventions, etc.
Guid day to ye. I'm still bewildered by what you meant by the "naming conventions". What was the name of the Icelandic Wikibook before it was changed (if it was changed)? - 20:37, 22 January 2006 (UTC) The Great Gavini

Separating enforced and proposed part of the policy
I'm tired of endless discussion of every paragraph of the policy. If we maintain current speed of dispute, we won't prepare complete policy this year. I think that we keep focusing on details with detriment to the whole policy. My suggestion is to divide naming policy into two parts: one we have reached consensus on, and other we are discussing. First will be marked as enforced, second as proposed policy. I would see most of the current article in first part, including title delimiter rules and page structure. As we still have doubts about categories, templates and aliases, these paragraphs will be marked as proposed.

As for me, I would support every consistent policy, regardless which shape it will have. I find current policy mature and well-written, maybe excluding part concerning category naming, but I would accept it. --Derbeth talk 22:30, 22 January 2006 (UTC)

Clear out the votes
I was thinking about clearing the votes. Many of those who have voted have not revised there vote (at least not that I noticed). Yes: seperate the page, clear the votes, start again and hopefully this time we get a consensus.

As for me: I was the first to vote "yes" as I allways thought: "good enough and better then no policy at all". But then came the "nit pickers" who are never satified.

--Krischik T 07:04, 23 January 2006 (UTC)
 * I would support clearing the votes. Go for it? You're the admin. -Matt 02:07, 24 January 2006 (UTC)
 * I decided to archive the top of this talk page, including the old poll. This allows someone to start a new poll. The old poll is in /Archive 1 if someone needs it. --Kernigh 07:47, 24 January 2006 (UTC)

Problems with forcing article titles to be computer filenames
The articles (modules) written for Wikibooks need to have a good title (something your English teacher would have approved as an appropriate title) and also a concise filename (something your computer programming teacher would have approved) for use in programming functions such as linking to the article and showing its hierarchy within the chapter and book. This was easy on Wikipedia, because each article (module) could have a short title (encyclopia articles typically do have short titles) which could also serve as the filename. And the Wikipedia articles do not have to link back to any higher level article, so the automatic Table of Contents box on Wikipedia only needs to show the downward hierarchy of any sections and subsections within the article, but it does not need to show any upward hierarchy. But the Wikipedia page naming method and the Wikipedia auto TOC do not really fit the needs of Wikibooks. For example, suppose that the editor for a book on Windmills would like to invite a respected historian to contribute an article (module, or section of the book) on the topic of history of the traditional American farm windmill. The historian may wish to call his article, "History of the Traditional American Farm Windmill." The historian might not like to have his article forced to be named: Windmills/History/Farms/American or any other article title which looks like a computer file name. He might not accept the invitation to write the article is he is forced to use some computer convention in naming his work. Forcing the current proposed Wikibook:Naming Policy may make it harder for book editors to recruit the best people to write the articles. --KHatcher 16:02, 27 January 2006 (UTC)

Has anyone heard of a high quality book publisher (for printed books) who requires book editors and authors to name their book sections according to a hierarchical format (like a computer file structure) as proposed on the WB:Naming Policy page as follows? Lifeforms/Animals/Insects/Butterfly I think that removing ability of book editors and authors to name their work could make many of them unhappy and likely to look elsewhere for a kinder book publisher. The reason for the current proposed policy (requiring a computer file naming structure as the Wikibook page naming convention) is to show the hierarchical position of the page within the book, and also to help readers quickly navigate to the next higher level section. But there might be a better way to do this than using the page title for this purpose. We need to find a way to meet both objectives: (1) let authors provide best title for the page, and (2) provide a way to show page hierarchy and quick link to the "parent" page. KHatcher


 * http://www.pmwiki.org/wiki/PmWiki/Directives#title - But I guess that's a feature request if we want that in MediaWiki as well --Krischik T 07:20, 26 January 2006 (UTC)


 * The recommended alternative to the name "History of the Traditional American Farm Windmill" is not "Windmills/History/Farms/American" but rather "Windmills/History of the Traditional American Farm Windmill." The former alternative may be offputting to a historian, but the second is considerably less likely to be so.  The proposed policy does not require a hierarchical naming scheme.  In particular, it does not require a name like "Lifeforms/Animals/Insects/Butterfly."  The hierarchical naming scheme is given as one alternative, and not even as the recommended one.  The flat naming scheme is given as the recommended alternative.  In it, the butterfly page becomes "Lifeforms/Butterfly".  If even this seems a bit offputting, remember that this is an example used to illustrate the difference between the flat and hierarchical schemes.  For a real book that follows the recommended nameing scheme, see How To Build A Computer which was listed approvingly as an example in the policy.  For a book I'm writing, Formal Logic, I use a mixed scheme.  It has a three level hierarchy with further organization at the the lowest level following the flat naming scheme.  Although not specifically forseen by the naming policy, this plan complies with it.  See also my comment to your Idea 1 below.  --JMRyan 16:04, 28 January 2006 (UTC)


 * Yes, you are right to point out that the flat naming naming scheme is given as the recommended alternative, and that is likely to be less offputting to authors. I like the idea of having alternatives and recommendations regarding the naming scheme to be available to book editors.  But even the flat naming scheme can be awkward when the book title is long and the section title is long.  I just went to my bookshelf and pulled out a random book, to see how authors might be naming their book sections.
 * The book is "An Introduction to Philosophy: Ideas in Confict" (by Peter Y. Windt).
 * Chapter 11 is titled "Perception and Knowledge of the Physical World" and the first section in that chapter is titled
 * "Rene Descartes: 'Sceptical Doubts about Our Knowledge of the Physical World."
 * So the page name for this section would be long and probably spill over into two lines of text. The flat naming scheme could be made less offputting to authors if the first line (the book name before the divider) were in smaller font that the second line (the title of the section), and if the line break came at a logical place such as just after the divider. -- KHatcher 16:22, 29 January 2006 (UTC)
 * Suppose Wikibooks (or WikiCommons) editor wished to import an existing classics book (with permission, of course) and set it up with all the linkages. If the original book had long titles, as above, it would be handy to have a shorthand version to type as links (within the double brackets).  So a page name that is structured as computer filename would be helpful as a shorthand, such as,  PhilosophyIntro:Perception:Descartes for the above case.  Then the pages would look better if the page filename appeared in small font and the actual article title appeared in prominent font.
 * Now there is the second issue of whether to force authors to use the slash as the divider. Using the slash, rather than colon, triggers the feature of automatically putting the backlink to the higher level module (first part of page name before the slash) just under the page name.  But some book editors may prefer to make their own backlink in their own format, and may not want a duplicate automatic backlink put on the book pages.  I think that editors should be free to do this, as long as they do indeed provide some backlink. -- KHatcher 16:22, 29 January 2006 (UTC)
 * Also I think the slash looks less aesthetic in print, because it does not provide enough visual separation between the words.

Unbundling TWO Proposed Policies - Naming and BackLinking

 * The current proposed policy on Naming policy actually combines two proposals. The first is the naming convention and the second is how the article will be linked back to the parent article (module).  Under the current proposal, lower level page names will be required to include the names of higher level modules within their page name, and to separate the multiple higher level names using slashes.  Using slashes in the multilevel page name (instead of colon or dash or space) then triggers the function of automatically showing the backlinks (in small font) just below the page name on each page.  This automatic backlinking feature then either forces the book editor to accept this method of showing backlinking on the pages, or it produces a duplicate backlinking if the book editor has already provided his own system of backlinking and showing page hierarchy.  I notice that User:Marshman already uses his own system of showing page hierarchy and backlinking in his Botany book, and his system looks very nice and looks better than the backlinking system to be forced by the proposed WB:NP. -- KHatcher 16:02, 27 January 2006 (UTC)

Idea 1 - Use page filename and page title

 * One idea is to not try to make the page name serve two different and incompatible objectives at the same time. Instead, separate the two functions by having both a page filename (which shows hierarchy) and a page title (whatever authors want for any new page title).
 * One method of doing this is shown in book on Botany in chapter on Mycoloty, Botany Mycology, where the page name (first line on the page) is allowed to be a computer filename, and the actual page (or chapter) title is written as text in large font.  So the author can select any most appropriate title he wishes.  I would just prefer that the font for the filename be made smaller in comparison with the actual title for the article.  -- KHatcher 16:02, 27 January 2006 (UTC)
 * Another method (as used by Wikipedia) is to let the page name be the article title. Then the page filename would need to be shown in smaller font below the page title, and there would need to be some way for the author to enter the correct title (rather than the page filename) as the first line on the page.  Krischik in his comment (above) offered a possible coding method for doing this.  -- KHatcher 16:02, 27 January 2006 (UTC)


 * The method employed in Botany Mycology does not violate the naming policy, though the page name "Botany Mycology" does. Changing the page name to "Botany/Mycology" to conform with the naming policy would not change the fact that the page employs Idea 1.  In other words, your idea is consistent with the naming policy.  The wiki software provides no support for implementing this idea, but there is nothing, naming policy or otherwise, to prevent you from implementing it by hand as you did in Botany Mycology.  You were concerned above about the offputting name "Windmills/History/Farms/American."  Implementing Idea 1 by hand should soothe the few prospective authors that would be put off by the page name "Windmills/History of the Traditional American Farm Windmill."  --JMRyan 16:22, 28 January 2006 (UTC)

Idea 2 - Improve the auto TOC

 * Second idea (which may even solve two problems in organizing a book):   Improve the automatic table of contents feature on each wikibook page so that it shows the page hierarchy upwards as well as downwards.  Then the reader could click on the higher level section or chapter in the auto TOC to navigate to the "parent" page.

Idea 3 - Status quo with superheadings

 * I prefer the status quo where book authors are still allowed to name their book pages as they think best (and no one sneakily adds a bot-written box on the discussion pages to lure readers to change the "nonconforming" page names into the computer file structure format). Anything to help the book authors (help, not force) to improve the clarity and consistency of page hierarchy and improve quick page navigation within the book will be welcome.  I'd like to make better use of the existing auto TOC feature for this purpose.  Does anyone know how to fix the section numbering within the auto TOC so that the first section is not always numbered as 1.0?  For example, if the page is chapter 4 of the book, I would like for the auto TOC to begin numbering the page subheadings as 4.1 then 4.2 then 4.3 etc.  With ability to control the numbering, I could then show the upward hierarchy for the page in the auto TOC by using some subheadings creatively as superheadings. KHatcher 00:42, 26 January 2006 (UTC)

Idea 4 - Page name using 2 lines and 2 fonts

 * This might be a compromise solution. Using the proposed naming policy (with slashes) sometimes causes long page names which spill over into two lines at top of a page.   The page would look better if this line break occurred at a logical place, such as after the last slash.  That would provide a better visual separation of the book name (on the first line) from the chapter or section name (on the second line).  I suggest making this separation even when the page name is short.  If the first line of the page name (the book title) could be shown in small font, with the second line (the title of the chapter or section) in the existing large font, that might provide a way to meet both objectives.   - KHatcher 14:04, 26 January 2006 (UTC)

I'm strongly sceptical about all these ideas. MediaWiki team is focused on improvements useful for Wikipedia, I don't think they would put much effort on features useful only at a marginal project, which Wikibooks unfortunately is. Even if they started working on it, I won't expect results very soon - should we sit and wait for new MediaWiki version? Moreover, in my opinion there will always be books that won't fit schema of "normal" Wikibooks, having an odd structure which would mess up automatic navigation generating. As for me, we are stick to current naming conventions.

One more thing: what if a module got orphaned? If it was named like "Solution 3" it would be very hard to find it's parent book. If you check orphaned page list, you will see how big this problem is. --Derbeth talk 17:44, 26 January 2006 (UTC)

Examples where filename and title differ
I had a similar problem at Wikisource; the page was called Elements of Style:Form but I wanted the title to be "IV. A Few Matters of Form". I added the title in a manner similar to what Botany does.

Today I adjusted Guide to X11/Building in the same way. At the top of the page:
 * 1) Filename "Guide to X11/Building", which is what I copy and put in double-square-brackets when I want to make a link.
 * 2) Backlink "< Guide to X11" to the front page of the book.
 * 3) Guide to X11 which produces a green box for navigation.
 * 4) Contents automatically inserted by MediaWiki.
 * 5) == Building ==, the title; one can replace it with a longer title without renaming the page.

An older version of the same page only had elements 1 and 2, the minimum needed to label and navigate this book. When I created the page, if I had called it "Guide to X11:Building" instead, the link would be missing, like how Civ:Terminology has no link to Civ. But Botany Mycology is an example of authors providing links without using slash convention. --Kernigh 00:58, 30 January 2006 (UTC)


 * This is a good example, and it shows a professional looking page. It also shows a TOC feature where I have wished for a solution.  Your green box shows that Building is your book's chapter 3, but the automatic TOC shows number 1. Building.  Does anyone know how to make the TOC show the correct chapter, by numbering as 3. Building, with the sections below numbered as 3.1 then 3.2 then 3.3?   -- KHatcher 20:38, 30 January 2006 (UTC)

Idea 5 - Use a Book portal, similar to Wikipedia use of topic portals

 * Wikipedia has several major topic portals to help guide readers to pages which all pertain to a particular topic (Geography, Science, etc.). Might be possible for Wikibooks to also use the portal concept, with Book:Bookname instead of Portal:Geography.  In Wikipedia, each page pertaining to the portal topic then gets a template pointing back to the portal entrance.  Simiilarly, each page on a Wikibook could also get a template (perhaps as the very first code on the page) pointing back to the book mainpage.

Idea 6 - Each book gets own domain name or subwiki, similar to Wikicities projects
See discussion under the subwiki topic (below). Also, on February 5, Cramer asked about giving each book its own domain name, similar to the way that Wikicities gives each project its own domain name. For example, the StarWars wikicity has domain name. This would keep all the pages in a book together within the same domain name, without having to include the book title in every page name.

Where was vote on "deprecated" naming schemes?
The proposed naming policy points out historical conventions which are said to be "deprecated" (which means disapproved and belittled). But I've looked at current talk page and the one archived talk page, and do not see any discussion or consensus about this. Where is it? The archived talk page shows the losing vote for the proposed naming policy, with its push to force consistency in page naming. This losing vote is one reason it is unwise to be pushing readers to enforce this proposal and punishing book editors for "violating" it, when it is only a proposal which has already lost a vote. I'll change the project page to remove implication that these other naming schemes are presently deprecated (rather than proposed to be deprecated). It this change is incorrect (if there has actually already been consensus to deprecate some naming schemes), then OK with me to revert and put the correct information on the page. -- KHatcher 18:04, 29 January 2006 (UTC)


 * I can't imagine situation where there are 10 different, incompatibile naming conventions allowed at a project. That's completely absurd and would end up with making reading and managing books impossible. If we don't have some standards, don't integrate books together, Wikibooks will turn into unorganised host for completely independent, standalone books with small, closed groups of contributors - because every book would have completely different editorial guidelines. Is that what we want?
 * From list of historical naming conventions especially 'no delimiter convention' is the most detrimental and misleading one, it obfuscates book name and makes using automated tools (like bots, but also finding parent book) almost impossible. Wikipedia convention causes the same problem, also disambiguation convention is not convenient in this category. Why we should care about bots? Suppose we have book "Movie making manual" and their authors decided they want the title "Movie Making Manual". But unfortunately first book author started naming pages with one of conventions mentioned above and they have to rename 50 pages manualy. If they had pages named in slash or colon convention, running bot which would alter every page of this book would be very easy.
 * Would someone support me if I started vote on only one subject - to completely forbid all historical conventions (I mean all except colon and slash one) for newly created books? --Derbeth talk 20:30, 29 January 2006 (UTC)


 * A second vote sounds like a good idea. Well, consistency has advantages, and freedom of choice always comes with the risk of making a poor choice (as well as the opportunity to create a better choice than the conventional choice, or just to be a different flavor).  Would you like to remove the user preferences option for Wikibooks?  Before casting my vote, I'd like to hear more from your perspective about the advantages of consistency.  I know that you do a lot of work to help Wikibooks, and I'd like to hear about how consistency can make your work easier.  -- KHatcher 22:53, 29 January 2006 (UTC)


 * Last comment by Kernigh gave me an excellent example on how book could mess up with naming convention. Look at Botany - there are three different naming styles in the main TOC. In my opinion, our policy should clearly dissuade users from giving books such structure.
 * Why consistency is important? Do you imagine that people wanting to contribute to someone else's book have to learn everything from scratch for every single book? It's not important which naming convention we choose, the thing is that we should have only one or maybe two so that readers and contributors won't be confused with every new book. Yes, authors are very creative, but in my opinion they should concentrate on writing content not inventing new naming systems. --Derbeth talk 15:00, 30 January 2006 (UTC)
 * Yes, I think that you have the right idea here about pointing out advantages and disadvantages of   the two approaches (status quo versus proposal 2).  So below there is a new subheading to help with that comparison.  Wikibooks is a collaborative effort of people with various skills - computer programing, editing, knowledge of specific subjects, etc.  The policies need to find a good middle ground, and so discussion from these different perspectives will be helpful. -- User:KHatcher


 * To correct, that vote is not very significant for current discussion. The votes are across a span of six months and the page content changed quite a bit across the "voting time." The votes pointed out important discussion topics at the time but weren't really maintained by those voting. The votes represented an incorrect view of what the policy was becoming and were stricken. There was no "loss" in my opinion since those votes covered way too many issues and were outdated. -Matt 18:09, 30 January 2006 (UTC)

Clear statement of Proposal 2
Proposal 2, as request by Derbeth (above) is "to completely forbid all historical conventions (I mean all except colon and slash one) for newly created books".


 * New books - only slash is allowed as delimiter for page names. Page names must be in format .  Colon as delimiter is reserved to Cookbook only.
 * Existing books - Any convention can be used, provided that book name is included in every chapter title. No cleanup boxes regarding page naming will be used on any existing books.  Existing books must provide their own backlinks on all pages (except slash convention which automatically provides the backlinks).
 * Enforcement - Polite cleanup request can be put on the discussion page (not the module page) of nonconforming new books.  There is no enforcement for existing books.

Clear statement of Status quo
Book editors may use their discretion in naming pages in a new book and existing books. The WB:NP page will provide guidance to help new book editors make an informed choice. Books must provide their own backlinks (using their own format) on all pages, unless slash convention is used to provide the standard automatic backlinking. A template may be used on pages to provide the backlinking to the book title and chapters. The WB:NP will provide advice and examples of such book templates and custom backlinking. -- KHatcher 22:23, 30 January 2006 (UTC)

Proposal 2 - advantages and disadvantages
Pros:
 * consistent, clear, easy to understand for readers and editors naming policy
 * slash convention provides pre-formatted automatic backlinks to the higher level pages (bookname, chaptername)
 * slash convention provides exclusive possiblity to use fast links to subchapters ( /chapter/ ) and sibling chapters ( ../sibling/ ), saving the time for typing the longer form ( bookname/chapter )
 * colon convention: only one applicable for namespaces (which Cookbook is)

Cons:
 * does not let book authors decide which naming convention is best for them
 * forces book section names to look like computer file names, such as: Windmills/Australian farms
 * if authors want to use a better book section title, such as "History of Windmills on Australian Farms" then the page appears to have two large-font titles
 * slash convention inserts a mandatory (no option to turn it off) second line of text on each page with the pre-formatted backlink, which is unnecessary if pages include their own backlinks or book contents template such as Botany example.
 * slash convention causes multiple redundancy with cluttered appearance at top of each page if authors want to use literary titles for book sections instead of computer file names, and also use their own backlinks (or book contents template) instead of the pre-formatted backlinks. -- KHatcher 16:24, 9 February 2006 (UTC)

Status Quo - advantages and disadvantages
Pros:
 * book auhors have full freedom

Cons:
 * two completely different books may link to the same chapter without knowing it (like Contents)
 * makes automatics tasks (use of bots to fix errors) hard
 * may confuse readers and contributors (if a contributor sees two books with completely different naming conventions)
 * two different naming convention in one book are allowed

I think that if good advice is provided at WB:NP, nearly all new books' editors will decide to use the slash convention or the colon convention. But the books' editors will be able to use a different custom page naming scheme if they believe that better suits the book purpose. -- KHatcher 22:23, 30 January 2006 (UTC)


 * I really see no benefits of the colon convention over the slash convention (given that slashes allow for better navigation). Let's require all new books to use the slash convention of  (and if they wish , , etc). It allows for a lot of editor freedom, and has the benefit of clearly segregating each book so that you're never confused as to what book you're reading.


 * Then encourage existing books over to this convention. No doubt, at some stage, we'll then be left in time with a small rump of books that haven't changed over to the slash convention. We can look at forcing the final resistance over then, Jguk 16:23, 10 February 2006 (UTC)

In defense of a slash
(I started writing this comment before the pros and cons heading above was added. I would have written in in a more pro v. con style had I seen it earlier.)

Wikibooks faces a significant organizational challenge that sets us apart from our sister wikis. We write books, not self-contained articles. Because of this, we need some mechanism for organizing our individual modules pages into discrete books. The wiki software provides only very meager facilities for this. We have to do most of the work by adopting some sort of convention or other. The slash naming convention provides three important organizing elements. Whether we adopt the slash convention or some other, adopting any convention will require enforcing some rules. If it is not an enforced policy, then it is not an adopted convention.

1. The slash naming convention helps authors avoid stepping on each other’s page names. For example, book I am working on, Formal Logic, has a page (Formal Logic/Sets) giving a quick and dirty introduction to set theory terminology used in the rest of Formal Logic. There are also set theory chapters of Discrete mathematics, Topology, Puzzles, Beginning Mathematics, and perhaps others. Any number of additional books might want a brief introduction on set theory such as in Formal Logic but geared to their own book. As another example, a chapter on mushrooms might show up in books on botany (the book Botany has a chapter on the broader topic of fungi), cooking, gardening, Super Mario, illegal drugs, or or books to which finding edible mushrooms is relevant (hobbies, survivalism, pig-breeding). The slash convention allows all these current and perhaps future pages co-exist peacefully. This is especially important when a book is mapped out with red-linked future pages. The author is guaranteed he won't be surprised by a name clash when gets around to adding a page to match the red link.
 * These are good points. They are not solely advantages of the the slash convention, however.  They are achieved by all the historical conventions which do use the book name (or its abbreviation) somewhere in the page name.  -- KHatcher 10:35, 31 January 2006 (Note: The post of 10:35, 31 January 2006, was made from IP address 128.192.18.97 while the user was not logged in.)
 * You are not exactly right. Two naming conventions: slash and colon are naturally preferred. One reason is that you can find them in Wikipedia (colon is used in namespaces and slash in subpages). We don't want to embarrass people coming from Wikipedia to Wikibooks by introducing strange naming conventions. Another thing privileging slash and colon conventions are MediaWiki links. You can use "pipe trick" with colon convention:  Cookbook:onions  and another trick with slash convention: <tt> /Subchapter/ ../Sibling chapter/ </tt>. This is impossible with all other conventions. I think these two facts show real advantage colon and slash convention have over other conventions. --Derbeth talk 17:17, 31 January 2006 (UTC)

2. The slash naming convention places a page within a book and lets the reader know where in the book you are. The reader readily sees that he is at this subpage of that chapter of such-and-such a book. At present, for example, it is ambiguous whether Wikibooks has a set theory book. There is a Set Theory link from the Mathematics bookshelf. But Set Theory is a redirect to Topology/Set Theory which may be its own book or may be a chapter of Topology, it’s actually ambiguous which it is. The subpages of Topology/Set Theory have names like Set Theory:Axioms which adds to the confusion. And who knows what book Set Theory:Review review belongs to? It is one of our approximately 1000 orphaned pages. It is entirely unclear whether Set Theory:Review was intended as belonging to Topology/Set Theory. Without an enforced consistent convention which places pages within a book and which lets the reader know where in the book you are, we end up with a big mess.
 * These are good points. They are not solely advantages of the slash convention, however.  They are achieved by all of the historical naming conventions for which the editors do provide backlinks to show position of the page within the book.  It is not necessary to require duplicate methods to show position of the page within the book, both backlinks and the page naming scheme. -- KHatcher 10:35, 31 January 2006

3. The slash naming convention provides automatic back-links. This makes it possible to find pages up the hierarchy and, in particular, find the root or main page of the book. Some authors can’t be bothered to adhere to any naming convention, not even a book-specific convention (see, for example, Botany whose page names vary among approximately three conventions). But even these tend to provide back links within their books. So the importance of back-links seems unquestioned.
 * I agree about importance of back-links. Perhaps the policy should be to require backlinks, rather than to require a particular page naming scheme.  Orphan pages are then defined as those which are missing the backlink to the parent module.
 * That the slash convention provides automatic back-links in a standard style would be an advantage for book editors who like that style, but a disadvantage for book editors who would prefer to have a different style of backlinking, such as by using a template on each page to show the book outline. In that case, the slash convention puts duplicate and unnecesssary backlinking information on the page and also puts duplicate information in the page name about position of page within the book. Some book editors may like to have their own graphic design style for the book, and not be forced to use a standard style or to have duplicate information cluttering up the pages.  Yes, there are some novices on Wikibooks who are sloppy about book set up.  It would good to have a way to deal with this, without harming the competent book editors.  -- KHatcher 10:35, 31 January 2006
 * My apologies for not getting back to this until after the vote started. The issue is not just competent v. sloppy authors.  It is also a issue of mature books v. new books.  Books are frequently created as a few red links and evolve into something useful.  The authors will often not fully know where the  book is going, what the graphic design should be, what sorts of navigational help will be best suited for that particular book.  It would be fairly absurd to start a book and comply with a slash convention (becuase you haven't got all that figured out yet&mdash;and then rename all the pages in a freewheeling non-complient way when the book matures and they type of alternative navagation assistance becomes settled.  Besides, it the automatic back-link line really obnoxious?  It does not seem any more obnoxious then the "Redirected from ..;.."  link.  --JMRyan 07:15, 15 February 2006 (UTC)

The slash convention provides these organizational features, but perhaps other conventions could do so as well. The kinds of convention we can adopt divide into two sorts: page name conventions and content conventions. (By content convention, I mean requirements concerning actual page content, the stuff that you type in on an edit page. And by adopting a convention, I mean enforcing a policy.)  Among page name conventions, the slash convention is the only one that will provide all three advantages. The colon convention, and perhaps others, can provide the first two advantages. However, only the slash convention provides automatic back links. Further, no content convention can provide us with the first of these features. So any alternative to the slash convention that provides all three organizational features will have to be a mixture of page and content conventions.
 * I think the Wikibooks uses the term "convention" to mean just the most common methods and not enforced. But term accepted "policy" would mean enforced.  -- 128.192.18.97 15:39, 31 January 2006 (UTC)

Imagine what an enforced content convention ensuring back links would look like. Would it simply say that you must provide some back links of some sort? Back links to the main page? Back links up the page hierarchy (assuming that there is a page hierarchy)? What other standards would they have to meet? Would you be prohibited from adding additional back links? If you think automatic back links resulting from the slash convention are obtrusive and big-brotherish, imagine you would feel about an enforced content policy requiring back-links. The same kind of consideration goes for an enforced content policy requiring the content to include information as to book the page belongs to and where in the book the page is.

I submit that enforcing the slash convention is the best, most robust, least obtrusive, and least big-brotherish means we have of organizing pages into books.

It has been objected that the slash convention restricts author options. For, example, I can’t entitle my page “History of the Traditional American Farm Windmill.” But there is no reason an author can’t provide such a title in the content independently of the page name. Botany Mycology does this, (though the page name does not conform to the slash convention). It has been objected that authors want to provide their own back linking scheme, one which may well work better in a particular book than the automatic back links generated by the slash convention. But there is no reason an author can’t provide his own back linking scheme in addition to the slash convention’s automatic back links. Formal Logic and Guide to X11 do this.
 * These points provide a work-around for the slash convention, by letting authors provide a duplicate page title and a duplicate method of backlinks if they have to use the slash convention but don't like how it makes page names look or how it shows the backlinks. Book editors may not want to have book graphic design style with such duplicate information on all the pages. -- KHatcher 10:35, 31 January 2006

Our authors’ flexibility in how they collect, organize, and back link their pages would be even more constrained if we enforced content conventions concerning these matters. And enforce we must, for otherwise we end up with a mess. Indeed, we already have a mess as indicated by our thousand orphaned pages. In Wikipedia, each article is supposed to be self-contained, so orphaned pages are less important. In Wikibooks, an orphaned page is part of a book that is not really part of a book after all&mdash;so orphaned pages are a much more serious affair. Perhaps if the wiki software provided better tools for organizing pages into books, we would not have to enforce a naming convention at all. But it doesn’t, and we have to work with the software we have. --JMRyan 22:48, 30 January 2006 (UTC)
 * I would prefer to continue to look for better tools using wiki software to achieve important organizing goals, while continuing to give book editors choice about book graphic design style. Is there another way to deal with the orphaned pages, such as searching for those having no backlinks and putting them all under an "orphaned book pages" folder (book) for a certain period of time until they are repaired?
 * By the way, why are orphaned pages (with no backlinks) such a serious problem on Wikibooks, when all the pages on Wikipedia have no backlinks?  I don't really see a serious problem here, just perhaps a small aesthetic issue of wanting to look different than Wikipedia.  Could someone please explain?  OK, so Wikibooks would have some pages (maybe a lot of pages) which look like Wikipedia pages.  Why is this bad?  It is not bothering me as a book editor or as a reader of Wikibooks.  Why is it bothering you?  Please see Wikibooks talk:Naming policy. -- KHatcher 10:35, 31 January 2006
 * This write-up explains the many advantages slash has over other conventions. Perhaps we can have a smaller subvote regarding the removal of proposal information and deciding on which method to use? -Matt 02:17, 31 January 2006 (UTC)
 * I completely agree with arguments of JMRyan. I think that current shape of Proposal 2 written by KHatcher is mature and ready for small vote - understood by vote only about which delimiter should be used in books and how to treat books having other that official naming convention. --Derbeth talk 13:46, 31 January 2006 (UTC)
 * Note that Proposal 2 does allow the colon convention, which does not provide automatic backlinks. -- KHatcher 10:35, 31 January 2006
 * In the second proposal, colon convention is only allowed for a few specific uses. Colon convention's current uses in many books (such as Programming: ones) would need to be marked as needing cleanup. I think of this as a very important point to note. Allowing colon convention for book pages is not acceptable under this proposal. -Matt 21:56, 31 January 2006 (UTC)

IP address 128.192.18.97 (signed as KHatcher, forgot to login?) wrote: By the way, why are orphaned pages (with no backlinks) such a serious problem on Wikibooks, when all the pages on Wikipedia have no backlinks?

Actually, every Wikipedia article and Wiktionary entry has a backlink called "Main Page". Also, encyclopedia articles and dictionary entries have predictable names; Wikibooks do not. I have to check a bookshelf to search to know if a book is called Letter writing or "Writing a Letter" or "How to write a letter" or "Effective Letters". --Kernigh 16:27, 31 January 2006 (UTC)


 * I'd like to add that one of the reasons why orphaned modules are such a huge problem on Wikibooks as well is that generally a single module doesn't stand on its own within Wikibooks, unlike Wikipedia. A Wikipedia article, even a stub, is self-supporting and doesn't really depend on any other article to help build its content.  That is one of the reasons why writing a Wikipedia article is generally easier to start or write, as you don't have to do nearly so much preparation.  Writing a whole book, on the other hand, takes a considerably higher level of organization and this policy is an attempt to encourage that sort of organization.  In addition, if you find an orphaned module that follows this naming convention policy, you can usually link it more directly to where it belongs, and sometimes content that would otherwise be deleted immediately as random gibberish can be kept because it can be put into context for what it represents.


 * Consider for a moment this page: Riddles: 28  This page would normally be deleted immediately on Wikipedia, but it is just fine on Wikibooks because of the context it has with the module Riddles.  --Rob Horning 16:40, 31 January 2006 (UTC)
 * Just fine with me, too. And it doesn't use the slash or colon convention, it uses a space-colon convention which looks good on the page.   -- KHatcher 18:03, 31 January 2006 (UTC)
 * My apologies for not getting back to this until after the vote started. I think Rob Horning was talking about the content being okay, not the page name.  The content is just a back link plus the single word "Ladder".  Out of context, such a page would just be trash subject to a speedy delete.  But in context, it is the answer to a riddle posed on another page.  How do we know not to mark it for speedy delete?  Two reasons:  (1) it has a (hand placed) back link and (2) the Riddles page has a link to it.  But what if the author forgot to do (2).  Then it is an orphaned page: one cannot get to by following links.  Now suppose someone moves Riddles to The Book of Riddles, thus breaking the back link.  Or suppose the author mistyped the back link and came up with Fiddles instead.  Three bad things happen.  First, someone reading the Riddles book doesn't find the answer to Riddle 28.  Second, someone else comes along a creates Riddles:28 to answer Riddle 28, thus duplicating the effort of the previous author.  Third, someone marks Riddles: 28 for speedy deletion because they don't know that it actually belongs to a book.  For real (not just hypothetical as here) problems of this sort, see Votes for deletion and Votes for deletion.  --JMRyan 14:05, 15 February 2006 (UTC)


 * I changed statement of Proposal 2. In my opinion, we cannot accept situations like Contents. Even old books with "no delimiter" convention should be fixed. Other ones may stay.
 * I see that the discussion has freezed, should we start vote? In my opinion, current shape of naming policy page is hard to understand for newcomers - there are two concurrent proposals with many points, everything is very complicated. I would like to see simple hint: "name pages like Book/Chapter". --Derbeth talk 11:53, 8 February 2006 (UTC)


 * The "Clear statement of Proposal 2" in Talk differs greatly from what is said on the content page. I support what's on the content page, especially only allowing slash for new pages (and not colon). I thought there was significant discussion here explaining how colon really should only be used like it is outlined on the content page. I think clean-up tags could go on talk pages only, but enforcing the naming policy on old books is a must. Here's what I think:
 * Slash only for new book content
 * Colon allowed on new pages for categories, templates, and Cookbook
 * Clean-up tags can go on both new and existing books, in the talk pages
 * Naming policy enforced on both new and existing pages
 * The "status quo" idea seemed decently defeated here and the "Clear statement of Proposal 2" seems to be bringing in too much openness. I thought that what I just outlined above was largely the concensus, unless I'm missing discussion somewhere. I would vote "no" on the "clear statement" because I don't think it's what's right for organizing the large mess of improperly named pages all over here. -Matt 17:35, 8 February 2006 (UTC)


 * Ok, I made another change to restrict use of colon convention. But I don't agree with your attitude to existing books. Book authors have better things to do than correcting naming conventions. I think that we should leave it as it is and make enforcement a separate vote. Please understand, that we need any naming convention. Current proposal is less restrictive than yours, but it has chanse for wider support. We can always make another votes to change details - like enforcements for old books. Another thing is naming of categories and templates. This issue is completely unimportant for me and I would like to exclude it completely from this proposal to avoid endless discussions and think about it when we have some basic set of rules ready and accepted. We need minimal but clear set of rules now. I would like to break status quo as soon as possible. If you take such restrictive approach, we won't get consensus soon. --Derbeth talk 19:53, 8 February 2006 (UTC)
 * Sounds reasonable to me. I think a lot of the recent bot talk was connected to fixing old colon convention pages so I didn't think authors would have to do too much to get their naming correct. I would support what you say above assuming the details can be figured out later. I think old books that didn't conform would tarnish things, but we can definitely focus on just getting new page guidelines up and running for now. I'd go for a vote. -Matt 23:59, 8 February 2006 (UTC)


 * If you haven't noticed it: vote has begun. See Policy/Vote/Naming policy. --Derbeth talk 09:17, 13 February 2006 (UTC)

Need to include book folder name in all page names? or use small subwiki?
A book such as Study Guide to the Science of Botany has both a book folder name (Botany, at very top of the page) and an actual book title, Study Guide to the Science of Botany. Inherent in Proposal 2 is the requirement to include the book folder name as the first portion of every page name. Why is this needed if the page already includes a backlink to the main page of the book?

User:Kernigh's comment (above) about Wikipedia pages all have backlink to "Main Page" is fortunate because it sparks an idea. Yes, and every Wikibooks module also has a similar backlink called "Main Page" back to Wikibooks, as shown in the navigation box along the left column. Kernigh's observation sparks another idea to solve our problems, perhaps using the navigation box. I notice that Wikicities has a way for each project there to have its own Main Page and URL  Also Wikipedia provides a sub-wiki for each language. Is there any potential to provide something like a subwiki for each book on Wikibooks? This idea is way beyond my poor computer skills, so I hope you can comment on its feasibility. If it succeeded, we would not need to include the book folder name as part of each page name as a work-around to keeping the pages within the correct book, since they would automatically be within the correct subwiki as they were created. Sorry if this is just wild idea, but I think we need to try think broadly and creatively about a solution to help everyone. -- KHatcher 18:03, 31 January 2006 (UTC)
 * I don't think its technically possible, we host hunderds of books. Apart from technical problems, what do you think is easier for a newcomer: note that pages are named like "Book/Chapter" or that each book has its subwiki? --Derbeth talk 18:41, 31 January 2006 (UTC)
 * It was technically possible on Wikipedia, though, for the languages. When Wikipedia had this similar problem, they could have set policy that all pages names have two parts to keep pages together, so articles would be named, for example, "English/History of Windmills".  That would not look so good.  Wikipedia made the better choice, and it is not hard for authors to work within the language subwiki, instead of typing "Language/ArticleTitle" on every page. -- KHatcher 21:04, 31 January 2006 (UTC)
 * Haven't you noticed you need separate account for every language edition of Wikipedia, you can't use templates in one wiki in another etc. In fact distinct language editions of Wikipedia can be treated as separate projects. --Derbeth talk 21:18, 31 January 2006 (UTC)
 * This problem may be fixed, BTW. A common account system has been formally developed and tested, but trying to get it up and running is going to be a big pain in the a*** to try and merge all of the Wikimedia accounts.  Expect to hear more about this in the not too distant future.  As for common templates, yeah, that is going to be a problem.  --Rob Horning 18:24, 5 February 2006 (UTC)


 * Giving each book a separate subdomain would mean to break Wikibooks in a thousand of independent projects. This is technically difficult, a redundancy of effort and against maintaining a unified community. On the other hand, it would be easier to request to the developers a different rendering of root page title and subpage title than convince the Wikimedia foundation to provide a different subdomain for every book. And imagine the pain to suffer for starting a new book. If the arguments against subpages are the ugly subpage titles, then there are better ways to improve them than breaking Wikibooks in a thousand of different wikis. ManuelGR 20:59, 5 February 2006 (UTC)
 * Giving books that want to use different naming conventions/navigation system their own namespace is a lot easier, this has already been done for the Cookbook. Once a book has become a namespace its ID can then be called in CSS and the backlink disabled, or any other necessary thematic changes made. However you'd have to convince the devs, not us, they're the ones implementing it on the PHP side of things. Personally I disagree with it unless it's really irreconcilable (as the case of the Cookbook), as the backlink is very small and can be easily overpowered by making the book's own navigation system more noticeable. Hopefully one day there will be a __NOBACKLINK__ command, but until then this is the easiest solution. GarrettTalk 22:20, 5 February 2006 (UTC)

School_of_Library_and_Information_Science
This is a funny one. I discovered it when I fixed a redirect link. Only after the fix it came to me that Human Resource Management does not actualy belong the the School of Library and Information Science at all (you have to click on edit to actually see the problem ;-) ). But it shows clearly that Wikibooks can not live without an enforced naming convention because the change of overlap is just to great. --Krischik T 14:54, 2 February 2006 (UTC)


 * And something like this doesn't happen in university settings either, where you have a required class for an engineering course on technical writing that is taught by the English department, but only engineering students attend? I've even seen dual-listed department classes (English/Engineering in something like this), which would be the equivalent of having a link on a page like this that is then redirected to another page.


 * This is also yet another reason why Wikiversity needs its own space, to deal with issues like this on their own terms and not have to be forced into conventions required by dealing with textbooks. --Rob Horning 19:25, 10 February 2006 (UTC)