On Fri, Apr 18, 2008 at 12:07 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Fri, Apr 18, 2008 at 11:54 AM, Raffaele raffaelemac@tiscali.it wrote:
I think it is not very intuitive -- the real content should be in the main namespace.
Not necessarily. Content that is logically different and that you want to be distinguished technically should go in separate namespaces.
Content from a sub-page is not logically different from the content of the book's base page. "Books" are more of a concept then an actually entity, they are a collection of pages. It is up to the author to determine how those pages are organized, and what is the logical relationship between them. Sometimes the base page is a title page, sometimes it is a table of contents, sometimes it is merely a redirect to one of these. Sometimes we have "Book/Chapter/Page", sometimes we have "Book/Page", sometimes we just have a one-page "Book". The basepage has no special significance besides being the most common landing point for new readers, and a prefix to differentiate the pages of one book from all the others.
Having subpages in a different namespace from the book's main page is completely illogical and, from my standpoint, unacceptable. The vast majority of all content pages on our site would need to be moved to a new namespace. Links would need to be updated, including links which are dynamically generated for in-book navigation. Consider the common snippet from a navigation template:
{{#if:{{{next|}}}|[[Bookname/{{{next|}}}|Next Page]]|}}
A bot likely can't edit all these links automatically, it is going to involve a huge waste of manpower resources to perform a task that could be easily performed by a single programmer writing a small extension instead.
Moving subpages to a new namespace would cause us to lose the automatically-generated back-links at the top of the page, which many books still rely on for navigation. Writing an extension or a javascript to replace these backlinks for pages which are written cross-namespace would be no easier then writing this allbooks extension.
Books are already separated from their subpages technically, using slash delimiters. Different books have different prefixes.
Books are single self-contained units, not to be constructed from bits and peices strewn across multiple namespaces.
For instance, mediawiki.org has most of its content in non-main namespaces, such as Manual:, Extension:, and Help:. In fact, enwikibooks already has a Cookbook namespace where a substantial amount of content resides.
The cookbook is a single book. Prior to creating the namespace, most of the pages in the cookbook were already titled using the pseudo-namespace "Cookbook:Subpage", which was deemed problematic. we created the new namespace for it in order to leverage searching and listing tools. If you think that this is the way to go, then every single book on Wikibooks should get it's own namespace. We would also need a form for easily creating new namespaces, since we don't want to have to wait on developers everytime we want to start a new book. We would also need a {{NUMBEROFNAMESPACES}} variable to count the number of books.
What works for one project, like Wikipeda or Mediawiki.org is not going to work for all projects. We want to do this the way that is right for us. If we wanted to do it the wrong way, we would just stay as we are now.
If you preferred, you could have the books in a Book: namespace and the pages in the main namespace.
This doesn't work either, for the same reasons. All content on Wikibooks is a "book", We shouldn't have to write [[Book:Bookname]] because all top-level pages are already books. You're trying to draw an unnatural distinction between a "book" and a "page" which is just not supported in the way we work. The pages in a book belong together.
The point is, don't try writing an extension when reorganization would do the same thing to better effect, using already-existent core software features.
The effect would be much worse, and I would consider either situation you suggested to be intolerable. All Wikibookians know what Wikibooks is being written on the "software that runs Wikipedia", we've been a round peg in the square hole since our project was created. We've had to come up with lots of hack-job solutions because what is best for our project is rarely well-supported in the software. We were asked for a wishlist of things that we would like as a project, not a list of more hack-jobs that we could throw together ourselves at the expense of doing things the right way.
Deciding on how to organize the site without any consideration for how well that works with the software you're using, then trying to patch the software to match your preordained specifications, is not the sensible way to do things.
The way we are organized is logical, and well-supported by the software. Using forward slashes to separate subpages is used on most Wikimedia projects, including occasional usage on Wikipedia. the recently added {{#titleparts:}} parser function supports this convention. The existence of backlinks at the top of the page support this convention. The only thing we don't have is an automatically-generated count and list of base pages. If the answer is, as it usually turns out to be "too bad, nobody cares about Wikibooks", then we'll just do things our own way.
--Andrew Whitworth