On Fri, Apr 18, 2008 at 11:54 AM, Raffaele <raffaelemac(a)tiscali.it> wrote: Not necessarily. Content that is logically different and that you want to be distinguished technically should go in separate 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. There's a concept of a "content namespace", so the pages could be made to behave much like the main namespace: counted as articles on Special:Statistics, searched by default, etc. If you preferred, you could have the books in a Book: namespace and the pages in the main namespace. 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. I'm not a shell user, but if I were, I would reject any extension to this effect unless it were shown that suitable reorganization couldn't use built-in namespace features instead. The layout of the site should be determined by technical requirements where those have an effect on things. 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. I'm a MediaWiki developer. I'm not a shell user and can't enable new extensions, but I can provide review and add things to Subversion. In this case I've given my review: I don't think the extension's concept is a good idea and I think it should be scrapped in favor of reorganization, and work on pagesinnamespace, if these features are desired. The ones who could enable your extension are Brion Vibber or Tim Starling, either of whom may disagree with my opinion on this idea.

On Fri, Apr 18, 2008 at 1:02 PM, Andrew Whitworth <wknight8111(a)gmail.com> wrote: 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. 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. 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. 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. 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.

On Fri, Apr 18, 2008 at 2:34 PM, Andrew Whitworth <wknight8111(a)gmail.com> wrote: In all honesty, there *is* a place for bots on wikis, and features that aren't so easy to implement cleanly in software are a good place for them. In many ways bots are more flexible and easier to handle. In this case, I suggest getting someone with a toolserver account to run the regex on the page table instead of using the API to retrieve the list in bits and pieces. (The current number not matching Ramac's regex is 6,085.) I had a discussion with some people (Mike, wknight8111, darkcode, Ramac) about this on #wikibooks. I still think these couple of features, and a few others, fit most naturally in with the concept of namespaces, and that it would make the most sense to reorganize the site (but I doubt that will happen, due to inertia). Some other features would be better suited to implementation as better subpage handling. For instance, the ability to move all subpages together with the base page is a perfectly logical thing to have in the core software, and in fact I just added it in r33565. I think few of the features Wikibooks wants are really narrow enough, intrinsically, to belong in extensions. Allowing automatic TOCs, navigation, etc. for particular namespaces was the only one I saw that really doesn't fit with any more generic feature that is or should be present, and that would make a good extension. At any rate, the decision as to whether these features would make a good extension (and if so, what about it needs to be improved) is up to Brion, who I've pointed to this discussion.