On Thu, Jan 17, 2008 at 09:45:00PM +0100, Gerard Meijssen wrote: Obviously, I have to show my work, or people will fall off. The major advantage of a wiki is that writers can just *write*, and mark things which ought to be pointers to other pages -- already written or not -- with the brackets, without having to engage in contortions like interwiki markup. This is why subpages aren't real useful in most wiki contexts, either. This is not a problem that can really be solved by technology; all the solutions I can see resolve to Where We Already Are. That is: "a knowledge domain disambiguation" is "put that stuff on another wiki, it doesn't belong on this one". If "the ability to reference that wiki's pages without interwiki markup" is *not* what you're looking for by putting them on the same wiki, what *are* you looking for. (Hint: if it's single sign-on, see also Single Sign On) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Witty slogan redacted until AMPTP stop screwing WGA

On 17/01/2008, Jay R. Ashworth <jra(a)baylink.com> wrote: Not if the system is properly designed. For example, you could have an article called "Omaha" in a wicro-wiki about poker, and a similarly-named article in a micro-wiki about US geography. The links for these might be: [[Microwiki:poker/Omaha]] and [[Microwiki:USA geography/Omaha]] which resolves the ambiguity. Indeed not. However, consider a case where someone wants to put up some information on the web. They can either (i) create a new wiki for this stuff, (ii) put it on an existing wiki, or (iii) not use a wiki at all. Comparing (i) and (ii), (i) is likely to take considerably more effort than (ii). On includipedia, the process of creating a new micro-wiki might look something like this: On an existing page, perhaps the user's user page, a user will edit the markup by adding [[Microwiki:foo]] Then they'll commit the edit and click on the new link. This will put them into the front page of a new micro-wiki called "foo" which for now is empty. They'll add text to this page. Subpages will have links of the form [[Microwiki:foo/bar]] It would be nice if there was a way of shortening this e.g. just using [[>bar]] and i meaning "bar in the current microwiki". I'm not sure how easy it would be to do that in MediaWiki (not looked at the code in detail yet). If the information to go up is going to be big and complex, then creating a whole new wiki for it is probasbly the best bet. But for something small, for example a Linux User Group that wants to put up a few pages about who they are, what they do, and where they meet, a micro-wiki might be an efficient way of doing it. -- Philip Hunt, cabalamat(a)googlemail.com

On 22/01/2008, Jay R. Ashworth <jra(a)baylink.com> wrote: It's however a smaller wall than setting up an entirely new wiki! But you're right: using the system should be as easy as possible. Setting up a new wiki is always likely to involve complication. For a start, one needs access to a webserver, which typically costs money and takes time to set up. Adding pages to an existing wiki is always going to be a simpler solution than creating a new wiki and then adding pages to it. I agree the last problem is one I need to seriously think about. One possible solution might be that within [[Microwiki:foo]], [[bar]] points to [[Microwiki:foo/bar]] and that if I want to point to bar in the main namespace I have to say something like [[:bar]]. If MediaWiki is to be given extra functionality, users will have to have a way of accessing it. This might involve new syntax. Can you think of a way of doing micro-wikis without extra syntax? On the contrary, Mediawiki is whatever you can coax the software into doing. BTW, I have a friend whose job involves using wiki software (not MediaWiki AFAIK) as a CMS. -- Philip Hunt, cabalamat(a)googlemail.com

"Philip Hunt" <cabalamat(a)googlemail.com> wrote in message news:823293b50801221159t8bd4ee5ic10deea870cd9896@mail.gmail.com... <jra(a)baylink.com> wrote: <jra(a)baylink.com> wrote: This is something that could be handled using namespaces. The additional features required in the software would be: * Namespace manager built into MediaWiki. AFAIK this has been done but never comitted to trunk? What happened to that code? Any chance of getting it into the core software? * Ability to specify for a namespace whether links without a namespace prefix resolve to (a) the default namespace or (b) the current namespace. Therefore workflow would be as follows: To start a new 'microwiki' go into the namespace manager, and add a new namespace with an appropriate (unique) name. The manager should automatically add the associated talk namespace too. You will need to set 'Destination of links with no namespace specified' to 'same namespace' instead of 'default namespace', but otherwise the defaults should be OK. Might be nice to have a simple interface for users and a fuller interface for sysadmins (as I know the existing code has a load of other options that may not be relevant in a lot of cases). Might also be nice to have a link to the 'Main page' of the new namespace that allows you to start using it straight away. To use the new 'microwiki' go to a page in that namespace and start typing. Links work exactly as if you were in the main namespace of a new wiki. To link to another microwiki, specify the full namespace. Therefore if you are on the page [[Poker:Flush]] to link to [[Poker:Omaha]] you would simply need to use [[Omaha]], but to link to the geography page you would need to use [[USA Geography:Omaha]]. - Mark Clements (HappyDog)

"Simetrical" <Simetrical+wikilist(a)gmail.com> wrote in message news:7c2a12e20802060949s4281d932r7107281a8bc9a9ce@mail.gmail.com... <gmane(a)kennel17.co.uk> wrote: getting Where is it? I wouldn't mind taking a look at it to see if it can be brought up to speed. - Mark Clements (HappyDog)

"Simetrical" wrote: Well, I've taken a look and there were a couple of surprises: * It already handles the issue of being able to specify where unmarked links (i.e. links with no explicit namespace) go to. * It was written for MW 1.10, so there should not be much work involved in getting it to apply cleanly to head! (Specifically 1.10alpha, branched at r19771) What would it take to get this into core? Is there a specific reason why this has not already happened (i.e. known issues, or incompleteness) or is it just a matter of someone not getting round to it (either requesting it or dealing with the request)? - Mark Clements (HappyDog)

"Simetrical" <Simetrical+wikilist(a)gmail.com> wrote in message news:7c2a12e20802061558m5855ac8gcc372f9ad7287f39@mail.gmail.com... It looks that way, but after the original branch creation, there have only been 18 commits to it. The last 2 are relating to the WikiData API module, but most if not all of the rest appear to be Namespace related. Of the remaining 16 commits, 1 is the initial merge of the namespace code (presumably from an external repository) and 11 only affect 1 or 2 files, so I don't think it will be that big a job to isolate the WikiData changes, especially if we can get Erik involved, as all but the last 3 commits were from him. - Mark Clements (HappyDog)

On Feb 7, 2008 6:39 AM, Roan Kattouw <roan.kattouw(a)home.nl> wrote: They still have to get checked in. I don't think it would be such a big deal to write up the core parts of this, in terms of needing to branch. I envision a process like this: 1) Write up a namespace-handling class and centralize all reference to namespace numbers and namespace-related variables there. Change things that currently refer to namespace numbers directly (i.e., everything) to use the class' methods instead. 2) Create an appropriate database table and populate it with the default namespace settings. 3) Gradually change the namespace class (which could, in fact, be Namespace . . . although not under that name for long, given that it's a keyword in PHP 5.3) to use the database in addition to the namespace-related globals. Specifically, set it so it will obey any LocalSettings.php customizations first, then what's in the database, then DefaultSettings.php default namespace settings (if it looks at those at all). This preserves backward compatibility in all respects. Some way will be needed to distinguish the default settings from customized ones, of course. 4) Create a namespace manager. This will allow modification of namespaces as you would expect. For as long as setting stuff in LocalSettings.php is allowed (which may be forever), it will gray out any options that are hardcoded there. None of those steps is a breaking change, and they can all be done in small pieces. There's no point in creating a giant branch that you have to keep up to date (which SVN makes a big headache) and which will then have to be merged all at once. A similar procedure could be followed for an in-wiki permissions editor.

On Wed, Feb 06, 2008 at 05:03:44PM -0000, Mark Clements wrote: *This* is the cool bit, right here. Let me say that I think this would be useful even if not for "microw~1" type stuff; I'm noodling on the possible downfalls... The only one that springs to mind at the moment is: how do you point out to the main namespace? It has a name, I guess, right? Is there available shorthand that could be utilized? [[:help]]? or does that mean something already? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)

Mark Clements schreef: Do I read this correctly in that Namespace Manager allows users to add/modify namespaces through a special page restricted by $wgGroupPermissions ? If you could get *that* implemented, it'd probably be the feature of the year :D Of course it'll probably be hell to merge post-1.10 changes into the Namespace Manager branch :( Roan Kattouw (Catrope)

Jay R. Ashworth wrote: Be aware that by moving [[Wikipedia:Foo]] to [[Help:Foo]] you may be creating red links! It should be handled with great care. [[:help]] already means help in main ns. And it shouldn't be changed to another thing.

"Simetrical" <Simetrical+wikilist(a)gmail.com> wrote in message news:7c2a12e20802071829v7aea7721t84b68c2b63954ac9@mail.gmail.com... <Platonides(a)gmail.com> wrote: He means that if you have article [[Wikipedia:Foo]] which links to [[Bar]] and you move it to [[Help:Foo]] then the link to [[Wikipedia:Bar]] will now point to [[Help:Bar]] which is not the originally intended destination. Whilst this may turn it into a redlink, a more dangerous result is if [[Help:Bar]] already exists so the destination changes and nobody spots it. - Mark Clements (HappyDog)