----- Original Message ----- > From: "Daniel Barrett" <[email protected]>
> 1. A desire for a department to have "their own space" on the wiki. > I'm not talking about access control, but (1) customized look & feel, > and (2) ability to narrow searches to find articles only within that > space. The closest related concept in MediaWiki is the namespace, > which can have its own CSS styling, and you can search within a > namespace using Lucene with the syntax "NamespaceName:SearchString". > However, this is not a pleasant solution, because it's cumbersome to > precede every article title with "NamespaceName: " when you create, > link, and search. > > If the *concept* of namespaces could be decoupled from its title > syntax, this would be a big win for us. So a namespace would be a > first-class property of an article (like it is in the database), and > not a prefix of the article title (at the UI level). I've been > thinking about writing an extension that provides this kind of UI when > creating articles, searching for them, linking, etc. > > Some way to search within categories reliably would also be a huge > win. Lucene provides "incategory:" but it misses all articles with > transcluded category tags. > > 2. Hierarchy. Departments want not only "their own space," they want > "subspaces" beneath it. For example, "Human Resources" wiki area with > sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence > supports this... but we decided against Confluence because you have to > choose an article's area when you create it (at least when we > evaluated Confluence years ago). This is a mental barrier to creating > an article, if you don't know where you want to put it yet. MediaWiki > is so much better in this regard -- if you want an article, just make > it, and don't worry where it "goes" since the main namespace is flat. > > I've been thinking about writing an extension that superimposes a > hierarchy on existing namespaces, and what the implications would be > for the rest of the MediaWiki UI. It's an interesting problem. Anyone > tried it? What you want, I think, is what Zope2 called "acquisition". It's like OO subclass inheritance, but it's *geographic* depending on where you were in the tree; the old Mac Frontier system did something like it too. You want links to have a Search Path, that starts with whatever part/ subpart of the tree the current page is in, and then climbs the tree, ending in the unadorned Main namespace, whenever a user clicks them. That breaks the semantics of wikilinks some, but that's probably ok for your use. It *might* be generally useful; I'm trying to figure out if there are any obvious common use cases that it breaks, and how you tell where in the tree a page lives when it's created (and how you would show that to users). Cheers, -- jra -- Jay R. Ashworth Baylink [email protected] Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
