------------------------------

Dave wrote: Yep .. discussion is for the full page ..

Peter Blaise responds: Okay, that's one for the wish list, then.

I watch the end user as they move their mouse around the MediaWiki screen trying to cause it to make sense to them. When they edit a section, there's a [discussion] tab in view, so it makes sense to them (and to me) that they can then click on [discussion] and discuss the section they are editing. Nope! They get a discussion/talk page for the entire article, not for the section they were just looking at!

In response to such surprises, I'm constantly reconfiguring my MediaWiki to not get people caught in such traps, where the programmer's logic conflicts with the intuitive, presumptive logic of a new user.

So, I'll break up our original documents into a series of sectionless sub-documents, then build a table of contents to introduce each group of pages that result, and then put a [previous][next] set of links across the bottom (and top?) of each of the many pages that makes up the total original document. An additional challenge is what to call all the smaller pieces of the original full-size single document so the user can find them and go to them using the

search [__________] [Go][Search]

area directly (whatever that's called!).

You know the next logical question: "Does anyone have a lead on tools that assist in automating this?" I've found that Word2wiki http://www.mediawiki.org/wiki/Extension:Word2MediaWikiPlus is a useful tool to manually convert and upload one document at a time once that document has been cleaned up and prepared. That was fine when I uploaded 17 chapters as 17 documents = 17 tasks. Now, I find that the MediaWiki on-screen presentation of such legacy documents demands that I break up the original documents into many separate pieces, instead. Suddenly I've got to re-cut-and-paste 4,500 sections from those 17 chapters, and then upload those 4,500 sections one at a time. That's 9,000 tasks steps (at least), not 17! It also requires much new data entry to create and manage 4,500 new sub-documents, name them, keep track of them, and build links across them so a visitor can read them all in order. The metrics here are orders of magnitude more complex and time consuming, hence my search for automation tools. No one has done this before?

This is what we need a big budget for, in order to actually implement a MediaWiki using legacy documents - *usable* document conversion and import is arduous.

Any leads on how to print any group of MediaWiki pages as a book, or print the whole MediaWiki namespace as a book, or convert and whole or selected pieces as PDF on demand?

Thanks!

-- Peter Blaise

PS - One reason I'm happy to chat here is to allow others, especially newbies, to see what I'm going through. If it helps them accurately anticipate their challenge, fine. Everyone says building a wiki is easy - and it is, I have found(!). But the challenge for me lies in building a working, reliable, maintainable wiki, importing legacy document contents, and empowering the end user to get the same benefits they had before considering search and replace, print sections or whole, and so on.