On Fri, Apr 18, 2008 at 1:02 PM, Andrew Whitworth wknight8111@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.