On Fri, Apr 18, 2008 at 1:02 PM, Andrew Whitworth <wknight8111(a)gmail.com> wrote:
Content from a sub-page is not logically different
from the content of
the book's base page.
Of course they are. Otherwise you wouldn't want to list and count it
separately. If you prefer, the book *page* is logically different
from the book's *subpages*, even if their respective contents may not
be logically much different.
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.
All of this is probably solvable using redirects, except for
conducting the moves themselves. If, as the author of this extension
thinks, a regular expression is reliable enough to distinguish books
from their subpages, a bot could be used to do all the moves and fix
any resulting double redirects.
Books are already separated from their subpages
technically, using
slash delimiters. Different books have different prefixes.
An alternative approach to fix the problem would be to improve support
for subpages. This is, from a software point of view, a path of
greater resistance, since namespaces are already well-distinguished
and subpages are not. It would have to be thought out very carefully.
One thing that occurs to me is that theoretically, it doesn't have to
be set in stone that different namespaces correspond to different
colon-delimited prefixes. Hypothetically one could have "Book" in the
main namespace and "Book/subpage" in another namespace, even though
they have the same prefix. But this would require a considerable
amount of effort to implement.
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.
They would still be kept together, by a naming convention and by
templates. I think part of your objection stems from the fact that
you're used to a particular way of doing things, while I don't use
Wikibooks to any great extent and am not committed to any particular
way of doing things. I submit that the way I suggest is not so much
worse than the current way, in terms of aesthetics or utility. It's
just a convention, that people would get used to if it were adopted.
It's not great: I agree that adding "Book:" or "Page:" is
logically
redundant and should not really be necessary. But to call the
difference between the concept of a book and the concept of its pages
"an unnatural distinction", to use arguments like "the pages in a book
belong together" (as if a few letters in a name makes them more or
less together), is a little much. I was just making a suggestion.
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.
Well, look at it this way. The overwhelming majority of websites are
using software not designed specifically for them, and have to put up
with all sorts of annoying assumptions that don't fit their usage
patterns. Only the very largest websites tend to have decent software
designed in-house. Wikibooks is, comparatively, in the excellent
position that if anyone wanted to become a developer, they could
fairly easily become one, code up any features that they wanted, and
have them incorporated into the main product without having to
maintain hacks.
That most MediaWiki developers (including me) come from Wikipedia
probably speaks to the fact that Wikipedia is one of the largest
websites in the world, while Wikibooks, Wiktionary, and so on are not.
Not as many people seem to be able (or willing?) to step forward from
the smaller projects, so they get much less done for them.
If anything, I would encourage anyone who wants to improve MediaWiki's
utility for Wikibooks to work on improving the core software, not
creating what are (as you put it) hack-job extensions. Features of
more general interest and usefulness are more likely to be accepted
and maintained by others, even if they are of particular interest to
Wikibooks, plus you help out more sites than just Wikibooks. Only if
a feature is intrinsically of very narrow interest should it be put in
an extension.
I may be primarily interested in the English Wikipedia, by the way,
but I've more than once opposed the implementation feature requests
from there based on their narrowness and the existence of better and
more general solutions. And on the other hand, almost none of the
changes I've made are of use only to Wikipedia, as this proposal would
be of use only to Wikibooks. This is not a question of Wikibooks vs.
Wikipedia, it's a question of coding practice in general.
The best question to ask from a development standpoint is not "How can
I get this narrow feature implemented for Wikibooks?", but rather
"What flaws in the software does this problem we're having exhibit,
and how can I fix it in the simplest and most generally useful way
possible?" When I asked the latter question, the answer I saw is
this: this issue seems to indicate that the namespace system is either
not being used properly, or is inadequate for the purposes at
question. I suggested it be used to better effect. Failing that, if
the presence of a few letters before the page name is really a killer
issue, the clean and correct (if difficult) course is to improve the
namespace system, since it's a feature that's already meant to serve
the basic purpose desired here. Creating a new system orthogonal to
very similar existing functionality is not the right way to go from
the perspective of maintaining generally-useful software.
But again, this is just my opinion. I didn't mean to cause a fuss. I
was asked to review the extension and I gave my honest opinion on it.