Wikibooks talk:Naming policy/Archive 3

new variable SUBPAGENAME
Over the weekend i requested a developer add a variable SUBPAGENAME it went live sunday and ive already begun using it for various templates. In regards to the naming policy i assume wikipedia uses PAGENAME for page titles using SUBPAGENAME would leave pages like Cookbook:Blah with the same title but any subpages would display just the name of the subpage and not the full filename. The auto generated backlinks and address bar would still let you know your on a subpage. Just suggesting, any thoughts? Discordance 03:38, 7 March 2006 (UTC)


 * Well... for page titles, it might be okay, but note you'll be given the same pagename for different pages sometimes. For example, returns Lesson 1 for both Japanese/Kana/Lessons/Hiragana/Lesson 1 and Japanese/Kanji/Lesson 1
 * The same is true to Table of Contents, Introductions, Chapter 2, Exercise 3, ... As you mentioned it's true that the parents and grandparents (and so) pages are presented as backlinks just below the title. For newbees, they might not know this fact and they could be confused. Or, probably they know well which Book they're reading thus not confused at all, rather, it might be helpful to know where they are at the moment. Hmm...
 * For TDI browsers such as Firefox or Opera, Talking about how you are doing (displayed "Talikng abo..." or so on the tab) might be better than Japanese/Lessons/Introduction/Ogenki desu ka/Talking about how you are doing (displayed "Japanse/Les..." or so), since the latter cannot be distinguished from, say, Japanese/Lessons/Introduction/Amerika-jin desu ka/Foreign loan words (also "Japanese/Les...") or Japanese/Lessons/Introduction/Konnichiwa/Pronunciation (again "Japanese/Les..."). However, this depends on the preferences you set and IE users would not care anyway.
 * (off topic) Although it is beyond the scope of this talk page, for categorization via template, in some cases a variable which returns foo/bar for Hoge/foo/bar is more desirable (FULLSUBPAGENAME?), rather than  which returns bar for Hoge/foo/bar. Of course this depends on the category organization (sorry, at first I missed this point). - marsian 06:45, 7 March 2006 (UTC) fixed template part 12:29, 7 March 2006 (UTC)
 * indeed it would be it was also something i was thinking of suggesting but i havnt had need for it yet, perhaps SUBPAGEPATH? Dunno someone who needs it should pick a name and submit to bugzilla. Discordance 13:56, 7 March 2006 (UTC)
 * Something you might want to consider is relative links. This would be something useful for navigation templates or other places similar to what you are suggesting here.  For the example listed above, Japanese/Kana/Lessons/Hiragana/Lesson 1 and Japanese/Kanji/Lesson 1 can be linked like this to Lesson 1 from each page (using the same Wiki text):   ../Lesson 1  This can also go in reverse like this:   Go back  This feature is not fully implmented with MediaWiki software and takes a little more work than a usual link, but it does work.  BTW, this wouldn't work with the colon naming convention for subpages.  --Rob Horning 00:54, 8 March 2006 (UTC)

Colon naming conventions
I'm going to raise this issue again. While I agreed that some sort of naming policy ought to be used by a single Wikibook, and having a total free-for-all module naming policy is inappropriate, I don't think the slash convention for naming sub-modules should necessarily be the only one. I have used the colon naming convention for sub modules as well as the slash convention. From a technical standpoint, it really doesn't matter and doesn't affect MediaWiki software one bit. Even from an administrative viewpoint to search pages on Wikibooks, it makes no differences in terms of having to search out pages and find what connects where, and how. The only real benefit of the slash convention is the "cookie crumb" trail of cascading sub-modules bring with links to "parent" modules. For authors who don't want them, the colon naming convention may be exactly what they are looking for.

My suggested policy modification is this: At the discression of the authors of the Wikibook (decided within the main talk page of the Wikibook in question) they can decide upon a naming convention for their content and use either a colon or a slash for naming sub-modules.

Basically this adds the additional option of using colons as seperators for sub-modules. I believe this to be a reasonable request, and something that has been widely done in the past for many Wikibooks. I know there are opposing opinions to this subject, and it was inappropriate to force the existing naming policy to add this just to complete the vote. I wish it had been left in the naming policy (it was there earlier) and I'm asking now for its return. --Rob Horning 01:07, 8 March 2006 (UTC)
 * If this were a voting situation, I wouldn't mind another section allowing people to instead vote for making slash the only accepted convention. There would be many voting yes in that vote and not simply no to allowing the colon convention. We could split it into two groups or let one vote go three ways perhaps. -Matt 04:39, 8 March 2006 (UTC)
 * I think the colon naming is a much better idea for certain sorts of projects, such as many of the how-tos that are more article based than they are chapter based, the obvious example being the Cookbook, but also bartending, gardening, and other topics which end up absorbing a lot of transwikied material. For one thing, making the templates on wikipedia for book linking is quite a chore if you need a different template for every chapter and subchapter. For example, leaving links on the wikipedia articles on Carrots and Basil is a lot easier if you can just use a template linking to pages such as:


 * Cookbook:Carrot and Cookbook:Basil


 * Rather than something like


 * Cookbook/Ingredients/Vegetables/Carrots and Cookbook/Ingredients/Herbs/Basil


 * For one thing, you'd need an either an ever-expanding number of variables in the template, (such as Cookbook ((/CHAPTER))((/SUBCHAPTER))((/PAGE))), or an exer expanding number of templates (such as Cookbook/Ingredients/Vegetables((/PAGE)) and Cookbook/Ingredients/Herbs((/Page)), etc.).


 * Anyway, I agree that there should be separate votes about separate issues in the naming conventions. -- SB_Johnny | talk 13:55, 14 August 2006 (UTC)


 * First off, cookbook is a bad example, because it has it's own namespace, and therefore must use a colon for the first level of navigation There is simply no way else to do it. Also, you are assuming that the forward slash convention requires a non-flat namespace, which is not true. I have made many books that use a flat, forward slash scheme for navitation. Every single page in those books then, have an automatic back-link to the table of contents. You could just as easily have:


 * My book/my chapter


 * as you could have:


 * My book/my chapter/my subchapter/my page


 * And such a decision is left up to the authors to do with what they please. The colon convention could potentially interfere with the creation of new wiki projects, and new namespaces. The back links that the forward-slash provides may be unnecessisary, but I have yet to see a situation in which it is detrimental, or where it is prefered not to have them for some reason. Any author who doesn't want backlinks for whatever reason, is probably not taking into consideration the needs of the readers for a consistant user interface here. --Whiteknight (talk) (projects) 14:08, 14 August 2006 (UTC)


 * Since I'm dealing with new projects and namespaces explicitly on the new Wikiversity project (as an admin, no less), I strongly disagree that this is that huge of an issue, and indeed it has helped doing a transwiki when items were using a colon naming convention in the sense that it helped on the transfer between namespaces and projects. For me, this is a non-issue and not a reason to stop people from using a colon naming convention, as it really doesn't make any real harm except in extreme situations.  Inter-wiki links to Wikiversity seem to be working just fine, although the  markup isn't working yet for hopefully obvious reasons.  BTW, the page import between projects is one kick-ass piece of software, and the colon convention is one thing that has helped us out immeasurably.  --Rob Horning 21:02, 18 August 2006 (UTC)


 * Interesting point. I suppose another way of facilitating IW linking would to simply have redirects with colons, but having the "real" page use the slashes (thus facilitating forking to other wikis). SB_Johnny  | talk 15:05, 14 August 2006 (UTC)

Disadvantage with the slash
One disadvantage that has been noted with the "/" is that it creates a backlink at the top of the page, which is unnecessary if the page has a table of contents, or just a link to the book's main page, already. I was wondering if anyone knew of a javascript hack for MediaWiki:Monobook.js that could get rid of it? --Adam7davies 11:27, 31 May 2006 (UTC)


 * In my book, that is an advantage of the slash, and even if there is a way of getting rid of it, I'd ask you to do so in your personal monobook rather than the monobook that applies to everybody. The backlink is somewhat small too, Jguk 11:41, 31 May 2006 (UTC)
 * Yes, I see it as a huge advantage. A global hack would defeat one of the reasons people like the slash convention. -- LV (Dark Mark) 18:04, 31 May 2006 (UTC)
 * But as Adam says, for a book that has a standardized ToC on each page, such a link may be redundant. It might also interfere with the look and feel the book's authors are attempting to achieve. I think the contributors to each Wikibook should be given a large ammount of autonomy as to how a book is organized and presented, as long as the content falls within our mandate. Forcing a possibly unwanted and unneeded link to the top of every page of every book seems somewhat unwiki to me. Gentgeen 19:56, 31 May 2006 (UTC)
 * But the backlink is small, and I feel that it is a small price to pay for causing wikibooks to all be named in a uniform manner. However, maybe we should ask the developers to create a new directive, such as "_NOBACKLINK_" or something, to manually remove the backlink? --Whiteknight (talk) (projects) 21:47, 31 May 2006 (UTC)
 * Yeah, if that would be possible, that would be great. I'll shoot a note to Brion and see what he has to say. As to the point that "the contributors to each Wikibook should be given a large ammount of autonomy as to how a book is organized and presented", yes, but they don't own the pages, so anyone can really change them. Simplified, but I think you get the point. See you around. -- LV (Dark Mark) 23:27, 31 May 2006 (UTC)

Exported page wont work on normal Mediawiki installation if the page has such naming convention. Is there special extension or bot used to automatically generate link up in the hierarchy —The preceding unsigned comment was added by 202.161.131.67 (talk • contribs).

Slash surrounded by letters has poor readability. Has anybody raised this inconvenient? Ask any publishing expert in book composition, and they will explain that the eye needs stops to improve its scanning ability. That's the reason for instance of fonts with serifs. Spaces before immediately before and after the slash would improve readability. Compare these two examples, or even a third alternative: --Gciriani (talk) 02:31, 21 June 2008 (UTC)
 * 1) Harry Potter/Chapter 1/The Boy Who Lived
 * 2) Harry Potter / Chapter 1 / The Boy Who Lived
 * 3) Harry Potter - Chapter 1 - The Boy Who Lived


 * The display of the title is a problem separable from the naming policy, which I support in its current form. Take a look at my request for enhancement (Separate page title rendering from subpage syntax) in Mediazilla, you might agree with it. ManuelGR (talk) 16:07, 21 June 2008 (UTC)


 * The French Wikibooks use a different setup from ours. One we might want to adopt. See for example: Japonais/Vocabulaire/Astronomie. --Swift (talk) 01:49, 22 June 2008 (UTC)


 * We should adopt this setup or something similar. In the meanwhile we can apply it to our monobook.js for personal customization, I have already done it in User:ManuelGR/monobook.js. ManuelGR (talk) 12:23, 23 June 2008 (UTC)

Let's reopen this debate...
Looks to me like there was not a consensus on the Naming policy standards vis-a-vis slash vs. colon, and the situation "on the ground" certainly reflects this, as I've seen numerous books using colons rather than slash, and even some with both (which definitely seems a bad idea).

Since both are being used now de facto, and the "enforced policy" isn't being enforced, I think it's time to make it official that both are permitted, and set up guidelines for the use of each.

Colon and slash each have their advantages and disadvantages, as discussed on this page and the archives. Guidelines should be set up to help overcome the disadvantages for each convention. -- SB_Johnny | talk 11:20, 18 August 2006 (UTC)


 * This version of the policy states that books that were using the "colon convention" before the acceptance of the policy are allowed to keep the colons (although it is not preferred). All new books should use the slash convention. Saying that some books still do use the colon convention does not mean that we should allow it through policy; if anything, we should be more active in switching books over to the slash convention. I personally am in the process (slowly) of switching the Modern Physics book over to use the slash convention, so progress is being made on at least one book. Keep in mind that the Cookbook is technically a separate namespace, just like "wikibooks:" or "User talk:". Namespaces use colons by default to distinguish between the namespace and the pages.
 * Keep in mind also that it is easier to go onto wikipedia and alter the old IW templates then it would be to alter this policy. --Whiteknight (talk) (projects) 13:36, 18 August 2006 (UTC)

Colon guidelines

 * 1) Use a TOC or other template to allow navigation from either the top or bottom of the page.
 * 2) Make sure to link all pages from a main directory.

Slash guidelines

 * 1) Create redirects from colon-named pages, to ensure interwiki templates function properly

Grandfathering provision
No it's not de facto and if you find a book started after the 1 March 2006 not following to policy then tell us and we start enforcing... --Krischik T 13:35, 18 August 2006 (UTC)


 * Can you point to where there was a consensus reached? The record of the talks doesn't seem to have anything approaching it. -- SB_Johnny | talk 14:23, 18 August 2006 (UTC)


 * I don't mind just changing the formats myself, but just want to be sure this isn't gonna change again) -- SB_Johnny | talk 14:36, 18 August 2006 (UTC)
 * The naming policy was approved in a formal vote that took place on Policy/Vote/Naming policy. The reason for the grandfather clause was to keep too many people from getting stirred up and complaining about the change when they had existing Wikibooks they felt comfortable about.  BTW, I still think that you should be allowed to use the colon as a page seperator, and think the whole issue with requring only slashes is BS and made simply because they wanted to have a rule and a policy.  Besides, it was getting railroaded in as a policy at the time, like apparently a few current policies seem to be doing right now as well.  --Rob Horning 20:53, 18 August 2006 (UTC)
 * That's not fair, wikibooks should have some kind of decision-making policy on the books (if you were, in fact, talking about the general voting rules policy). There are a few other policies being discussed, but I would hardly say any of them are being "railroaded in". --Whiteknight (talk) (projects) 21:06, 18 August 2006 (UTC)
 * Is there some procedure by which we can change those old pages to reflect the new standard? Please somehow include a corresponding link too...--deostroll 10:28, 8 January 2007 (UTC)


 * I agree with Robert Horning that something has gone wrong when
 * (a) a vote is called for a version of a naming policy Policies and guidelines/Vote/Naming policy that specifically states "No cleanup boxes regarding page naming will be used on any existing books.", then
 * (b) the vote shows there is wide consensus, and it is made an enforced policy, then
 * (c) any mention of "existing books" (the "Grandfathering provision" ) is deleted from the policy, then
 * (d) a cleanup box is slapped on one of those "existing books", claiming it violates the naming convention "that had wide consensus".
 * Assuming that Hanlon's razor applies to the above confusion, what should we do to make sure the current policy actually does reflect consensus?
 * --DavidCary (talk) 18:32, 4 September 2008 (UTC)


 * Consensus can change. Given that the poll you cite is nearly 3 years old, I think that's a fairly reasonable explanation. One might also consider that this has been common practise for some time now, showing agreement among active members of the community. Indeed, this is the first and only comment on the subject since I joined the project. As for removing the grandfathering provision, I think that may have been premature - some discussion first might have been in order. That said, I certainly agree with AdRiley's rationale, and I would advocate strongly for his change if we decide to reverse the edit pending further discussion. Mike.lifeguard 18:44, 4 September 2008 (UTC)
 * I apologise if I have offended anyone by removing the grandfathering provision. I had considered starting a discusion but wondered does anyone really care enough to spend time debating what I saw as a minor issue?  So I decided to be bold and remove the provision and see if anyone objected.  I did that in June and this is the first comment I have seen on it.  I welcome a discusion on the topic if you think it is needed.  Do you have any particular reason to want to keep the old naming convention for that book?  The new convention has many benifits and moving forward I think it will be better for the project if all of our books follow it.  I am happy to do the leg work in renaming the pages (as I have been doing for some time now) if that is a problem. --AdRiley (talk) 08:11, 5 September 2008 (UTC)


 * I am tempted to change this policy to an arbitrary style that I prefer, and then claim that any evidence to the contrary is "old", that since then "consensus has changed" to agree with me :-).
 * However, almost any naming policy at all is better than not having a naming policy.
 * I agree that the "slash convention" does have many benefits, and is certainly far superior than the unfortunate practice of creating pages that don't seem to be connected with any particular book.
 * I think that I am not the only one that prefers the "colon convention".
 * I want to keep the colon convention on books like Serial Programming ([Serial Programming:Serial Java]]) because (a) chapter headers in a few paper books actually do use a colon, but I don't know of any that use a slash. Also, (b) deep hierarchies are usually (in my opinion) misguided, and it seems that people are more likely to create such a misguided deep hierarchy with the "slash convention" than the "colon convention".
 * I see that that Wikibooks talk:Naming policy/Archive 2 has more discussion on this topic. --DavidCary (talk) 06:32, 9 September 2008 (UTC)
 * David, I have restored the clause and will propose its removal under a new heading where we can gather more opinions one way or the other. In brief response to your reasons to keep the colons, they sound like reasons why you think the colon convention is better overall; I think that discussion has been had and the slash convention was decided upon, I am not proposing that we reopen a debate as to what naming convention is better.  What I asked is, having chosen that convetion, why keep colons for our old books making them inconsistent with how we now do things?  --AdRiley (talk) 06:31, 10 September 2008 (UTC)


 * Rather than "reopen a debate", may I ask for a link to that debate, a link to where "that discussion has been had"? The places I link to above seem to show that, years ago, there was a consensus to keep the colons for some books. Having made that decision, why change now? Has there been some more recent "debate" and "discussion" of which I remain blissfully ignorant? --DavidCary (talk) 22:29, 11 September 2008 (UTC)
 * The debate I refer to is the one which occured prior to this naming policy being passed as an official wikibooks policy by a community vote over 2 years ago.
 * I think perhaps "there was a consensus to keep the colons for some books" is a slight overstatement? What the clause actually says is "Books started before March 1, 2006 are strongly encouraged to change their name structure to comply with this policy".  All I am proposing is that we strengthen the "strongly encourage" to a "must".
 * In terms of a recent debate and discussion: no there has not been a new one, that is what we now have further down this page. --AdRiley (talk) 08:31, 12 September 2008 (UTC)
 * Huh? Are we looking at the same page? I'm looking at "Existing books - Any convention can be used, provided that book name is included in every chapter title. Consequently, we don't allow chapters with generic names like "Contents" anymore that don't also have the book name in the title. No cleanup boxes regarding page naming will be used on any existing books.". The consensus for that policy was shown by the 2006 vote at Policies and guidelines/Vote/Naming policy. —Preceding unsigned comment added by DavidCary (discuss • contribs)
 * Obviously not. I am looking at the official policy page, the page which you objected to me changing and the page for which this is the discusion page for. I'm not looking at the version from 2 and a half years ago. --AdRiley (talk) 07:44, 26 September 2008 (UTC)

Caps
How to notate a page's place in a hierarchy is only one aspect of how to name a page. So why is this project page about nothing else?

In particular, there seems to be a disagreement going on over how page titles should be capitalised. Look at the second-level titles in Puzzles for instance. Do we/should we have a policy on this, besides Make it consistent within any book? -- Smjg 15:42, 26 November 2006 (UTC)


 * Leaving it up to the authors of a book is a significant freedom I think, but basic mistakes like missing capitalization or avoiding offensive all-caps naming should be added I think. I personally think that's a worthwhile addition, extending it to other punctuation as well. -within focus 19:30, 26 November 2006 (UTC)

Cover Pages
I think the Naming Policy should say more about cover pages and their proper location. I see a lot of Wikibooks making their main page the cover page, then linking to the Contents page with the text "Go to Contents" or something similar.

Cover pages used in this way are essentially splash pages, or one more page to click through before reaching sought information. Like Flash intros, splash pages went out of style (on successful webpages) somewhere around 1999. Do a Google search for "splash pages" and you'll find many articles explaining the reasons for the splash screen's demise.

Basically, splash screens: Wikipedia-specific problems are that they:
 * Drive away traffic - Most visitors assess websites within a second or two. If they don't find the information they need in that time, they move on. Studies have shown that splash pages typically deflect 25% or more of a page's visitors.
 * Decrease search engine rankings - Because they have no useful content and few links, they dilute search engine rankings (which is the mode of entry to Wikibooks for many users).
 * Degrade Website Performance - The graphically intensive cover pages can add several seconds to load times (especially when Wikimedia's servers are overloaded), frustrating repeat visitors or those with slow connections.
 * Confuse visitors - Most cover pages are dominated by a large graphic which sends you to the image info page when clicked on, not the Contents page, leading visitors to not know where to click to continue. Sometimes the image/s are so large, the "Go to Contents" link isn't visible without scrolling (ex. - German).
 * Hurt Wikibook navigation - When people click on the automatically generated "up" link on subpages, they get sent back to the cover page, making book navigation harder (ex. - Principles of Economics).

According to the Manual of Style guidelines, the Table of Contents should be at "Bookname" and the Cover page should be located at "Bookname/Cover". I think this should be explicitly stated and enforced as Naming Policy, not just suggested as a guideline. Doing this will make all Wikibooks easier for visitors to find and to use.

&mdash; Everlong 14:44, 18 December 2006 (UTC)


 * Ok, but note (in the Manual of Style): External links, like links from bookshelves, should point to the book cover, not table of contents. So current MoS does not discourage creating Cover pages.


 * I think that people generally need books that are a bit "eye-candy". Cover page is a good place for a larger image, BOTM cup, some infoboxes, categories and iterwiki links. You can also reuse it on print version (see MoS "Title page and print version").


 * Anyway, I also think that new authors should obey our rules of naming cover page and book main page. But I doubt that this policy is a correct place to mention it; Manual of Style explains it well, is not too long and quite clearly written (at least for me). I suggest adding "see also" link here pointing to MoS and explaining, that MoS contains full description how the book should be organised. --Derbeth talk 19:16, 18 December 2006 (UTC)