On Fri, Apr 18, 2008 at 12:07 PM, Simetrical
<Simetrical+wikilist(a)gmail.com> wrote:
On Fri, Apr 18, 2008 at 11:54 AM, Raffaele
<raffaelemac(a)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