Re: Extension:AllBooks

On Fri, Apr 18, 2008 at 1:43 PM, Simetrical
<[email protected]> wrote:
> On Fri, Apr 18, 2008 at 1:02 PM, Andrew Whitworth <[email protected]> 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.

We're not interested in counting the individual pages (although I
suspect that's one of the easiest ways to go about this), we're
interested in counting groups of pages with the same prefix name.
Logically, it doesn't matter whether a particular page is named
"Bookname" or "Bookname/Subpagename". Consider a book with slashes in
the title, like "P/L programming". We wouldn't have a page named "P"
at all to be counted, but "P/" still serves as a unique prefix for all
pages in that book. Or the book we had about Oracle, which until just
recently didn't have a base page at all, there were
[[Oracle/Contents]] and [[Oracle/Cheatsheet]], but no [[Oracle]].

What we are after here is a simple count, a single integer value that
is probably in the neighborhood of 3000-4000 for en.wikibooks, and is
significantly lower for most other wikibooks or wikiversity projects
(since wikiversity is likely to want a feature like this too). Massive
across-the-board reorganization of the entire project is simply not an
acceptable solution for this problem.

We would also like a listing of books, although most of our books are
already well-categorized, and we can obtain mostly-accurate lists from
these categories (although it would be nice to know which "books" are
not properly categorized, that's a small issue).

Consider that a solution from our point of view is to create two bots:
1) Bot 1 makes repeated calls to api?action=query?list=allpages to
download the complete wikibooks page list.
2) Bot 2 applies a simple regex to that page list, counts the number
of unique prefixes. Posts an edit to the page
[[Template:NUMBEROFBOOKS]] with that number, and posts an edit to
[[Wikibooks:List of all books]] with the complete list.

I doubt this would be an ideal solution, but it would give us exactly
what we want.

>  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.

Again, measure the amount of implementation effort against the desired
goal. All we want is a single integer value. A massive programming
effort is no more desired on our end then a massive reorganization of
our books.

>   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.

This is exactly what we are trying to do. Ramac is trying to code this
feature up as an extension and have it added for Wikibooks.

>  Only if
>  a feature is intrinsically of very narrow interest should it be put in
>  an extension.

I would venture to guess that this feature is of particularly narrow
interest. I can only imagine that, based on the way I know other
projects to handle naming, only Wikibooks and possibly Wikiversity
would use it. Hence, the extension.

--Andrew Whitworth