2008/1/17, Philip Hunt [email protected] wrote:
I've been reading about your idea of an "Extrapedia" containing articles that Wikipedia doesn't think are notable enough.
I've recently been thinking on similar lines, and have decided to create an inclusionist fork of Wikipedia. You are welcome to use my wiki (when it's up) as your Extrapedia, if you want.
I notice you say "Now I wonder in general: why do there need to be multiple Wikias? Why can't all articles from all Wikias be one wiki?"
Why not indeed? I'm planning a feature I call "micro-wikis" that allows anyone to create a sub-wiki of the main wiki.
How would a micro-wiki work? What would it provide? Why not just use the category system instead? :-) You could modify MediaWiki to allow searches, recent-changes-views, etc. to show content related to the category of your choice only. If the user interface for this category filter system were designed well, maybe it would be a better way to get what you want?
Cheers,
On Thu, Jan 17, 2008 at 12:34:34PM -0600, Jason Spiro wrote:
2008/1/17, Philip Hunt [email protected] wrote:
I notice you say "Now I wonder in general: why do there need to be multiple Wikias? Why can't all articles from all Wikias be one wiki?"
Because you get namespace collisions between the knowledge domains.
You don't *want* all wikis to be one.
Cheers, -- jra
Hoi, Technical problems are there to be solved.When there are good arguments why you want something there is bound to be a way to manage it. If you get a namespace collision, you want to provide a "knowledge domain" disambiguation.. Obviously.. Think outside of your box, you stepped in it yourself :) Thanks, GerardM
On Jan 17, 2008 9:33 PM, Jay R. Ashworth [email protected] wrote:
On Thu, Jan 17, 2008 at 12:34:34PM -0600, Jason Spiro wrote:
2008/1/17, Philip Hunt [email protected] wrote:
I notice you say "Now I wonder in general: why do there need to be multiple Wikias? Why can't all articles from all Wikias be one wiki?"
Because you get namespace collisions between the knowledge domains.
You don't *want* all wikis to be one.
Cheers,
-- jra
Jay R. Ashworth Baylink [email protected] 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
Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jan 17, 2008 at 09:45:00PM +0100, Gerard Meijssen wrote:
On Jan 17, 2008 9:33 PM, Jay R. Ashworth [email protected] wrote:
On Thu, Jan 17, 2008 at 12:34:34PM -0600, Jason Spiro wrote:
2008/1/17, Philip Hunt [email protected] wrote:
I notice you say "Now I wonder in general: why do there need to be multiple Wikias? Why can't all articles from all Wikias be one wiki?"
Because you get namespace collisions between the knowledge domains.
You don't *want* all wikis to be one.
Technical problems are there to be solved.When there are good arguments why you want something there is bound to be a way to manage it. If you get a namespace collision, you want to provide a "knowledge domain" disambiguation.. Obviously.. Think outside of your box, you stepped in it yourself :)
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 <jra@...> writes: ...
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.
...
Aren't disambig pages a passable solution to that problem? Is it really worthwhile for people to start so many wikis about so many fictional worlds on Wikia.com just to avoid the problem? :)
Cheers, -- Jason Spiro: corporate trainer, web developer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs and get a free estimate. Email: [email protected] / MSN: [email protected]
On 17/01/2008, Jay R. Ashworth [email protected] wrote:
On Thu, Jan 17, 2008 at 12:34:34PM -0600, Jason Spiro wrote:
2008/1/17, Philip Hunt [email protected] wrote:
I notice you say "Now I wonder in general: why do there need to be multiple Wikias? Why can't all articles from all Wikias be one wiki?"
Because you get namespace collisions between the knowledge domains.
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.
You don't *want* all wikis to be one.
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.
On Sat, Jan 19, 2008 at 08:54:33PM +0000, Philip Hunt wrote:
On 17/01/2008, Jay R. Ashworth [email protected] wrote:
On Thu, Jan 17, 2008 at 12:34:34PM -0600, Jason Spiro wrote:
2008/1/17, Philip Hunt [email protected] wrote:
I notice you say "Now I wonder in general: why do there need to be multiple Wikias? Why can't all articles from all Wikias be one wiki?"
Because you get namespace collisions between the knowledge domains.
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.
See above where I said "without making the users have to know a lot of extra-special sauce to type. That's *way* too high a wall for the averageuser to crawl over; trust me.
You don't *want* all wikis to be one.
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]]
The *proper* solution to that is to make the overhead for creating (and possibly for operating) Mediawiki smaller. If you're going to write code, that's the code you write. Cause your approach is going to cause you to end up with a whole bunch of either one-user wikis, or contributions with links that don't point where you think they ought to.
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).
Yes, but you haven't justified, to my satisfaction, requiring contributors to have *any* modified reflexes.
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.
Mediawiki Is Not A CMS.
Cheers, -- jr 'ironic for *me* to be saying that...' a
On 22/01/2008, Jay R. Ashworth [email protected] wrote:
On Sat, Jan 19, 2008 at 08:54:33PM +0000, Philip Hunt wrote:
On 17/01/2008, Jay R. Ashworth [email protected] wrote:
Because you get namespace collisions between the knowledge domains.
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.
See above where I said "without making the users have to know a lot of extra-special sauce to type. That's *way* too high a wall for the averageuser to crawl over; trust me.
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.
You don't *want* all wikis to be one.
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.
The *proper* solution to that is to make the overhead for creating (and possibly for operating) Mediawiki smaller.
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.
If you're going to write code, that's the code you write. Cause your approach is going to cause you to end up with a whole bunch of either one-user wikis, or contributions with links that don't point where you think they ought to.
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]].
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).
Yes, but you haven't justified, to my satisfaction, requiring contributors to have *any* modified reflexes.
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?
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.
Mediawiki Is Not A CMS.
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.
On Tue, Jan 22, 2008 at 07:59:37PM +0000, Philip Hunt wrote:
See above where I said "without making the users have to know a lot of extra-special sauce to type. That's *way* too high a wall for the averageuser to crawl over; trust me.
It's however a smaller wall than setting up an entirely new wiki!
Not for the users. And the amount of user interaction over the life of a wiki leaves the labor to set it up at epsilon, or less.
But you're right: using the system should be as easy as possible.
Good to hear we agree that's the goal of Wikis. :-)
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.
The *proper* solution to that is to make the overhead for creating (and possibly for operating) Mediawiki smaller.
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.
See about about optimizing for the wrong thing.
If you're going to write code, that's the code you write. Cause your approach is going to cause you to end up with a whole bunch of either one-user wikis, or contributions with links that don't point where you think they ought to.
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]].
Sure. But again, why break the common semantics...
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).
Yes, but you haven't justified, to my satisfaction, requiring contributors to have *any* modified reflexes.
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?
Yes: don't.
The advantages of the mooted 'microwiki' concept continue, to me, not to outweigh the disadvantages, and there are other ways to accomplish what you want which do not have this problem.
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.
Mediawiki Is Not A CMS.
On the contrary, Mediawiki is whatever you can coax the software into doing.
"It's not anyone's problem to support you if you try to *use* Mediawiki as a CMS". Is that better? ;-)
BTW, I have a friend whose job involves using wiki software (not MediaWiki AFAIK) as a CMS.
Sure. You can write AI in shellscript. But do you really want to?
Cheers, -- jra
"Philip Hunt" [email protected] wrote in message news:[email protected]...
On 22/01/2008, Jay R. Ashworth
[email protected] wrote:
On Sat, Jan 19, 2008 at 08:54:33PM +0000, Philip Hunt wrote:
On 17/01/2008, Jay R. Ashworth
[email protected] wrote:
Because you get namespace collisions between the knowledge domains.
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.
See above where I said "without making the users have to know a lot of extra-special sauce to type. That's *way* too high a wall for the averageuser to crawl over; trust me.
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.
You don't *want* all wikis to be one.
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.
The *proper* solution to that is to make the overhead for creating (and possibly for operating) Mediawiki smaller.
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.
If you're going to write code, that's the code you write. Cause your approach is going to cause
you to end up with a whole bunch of either one-user wikis, or contributions with links that don't point where you think they ought to.
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]].
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)
On Feb 6, 2008 12:03 PM, Mark Clements [email protected] wrote:
- 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?
I think it was written for 1.5 or something. I doubt it would apply very cleanly today.
"Simetrical" [email protected] wrote in message news:[email protected]...
On Feb 6, 2008 12:03 PM, Mark Clements
[email protected] wrote:
- 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?
I think it was written for 1.5 or something. I doubt it would apply very cleanly today.
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)
On Feb 6, 2008 12:56 PM, Mark Clements [email protected] wrote:
Where is it? I wouldn't mind taking a look at it to see if it can be brought up to speed.
http://meta.wikimedia.org/wiki/Help:Namespace_manager
"Simetrical" wrote:
Mark Clements (HappyDog) wrote:
- 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?
I think it was written for 1.5 or something. I doubt it would apply very cleanly today.
Where is it? I wouldn't mind taking a look at it to see if it can be brought up to speed.
http://meta.wikimedia.org/wiki/Help:Namespace_manager
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)
On Feb 6, 2008 2:58 PM, Mark Clements [email protected] wrote:
- 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)
Interesting. I thought it was unmaintained. Guess I should have read my own link. :)
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)?
We have multiple big branch merges waiting around right now (e.g., rev_deleted, API edit, . . .). The essential problem is that Brion has to review all commits, and apparently doesn't have enough time to review really enormous ones. One branch merge did sneak in a couple of months ago by merging one or two files at a time, but that was a very modular thing where the changes in different files weren't really related (basically separating some backend logic out from the interface logic). Right now, the best way to get things done is seemingly to avoid branches wherever possible, and implement your feature on trunk only, incrementally if it's too big to do all in one commit.
In any case, the link given on the page is to the Wikidata branch. As far as I'm aware, that's a far bigger project than just a namespace manager. If there's no branch for just this feature, that complicates the issue even more.
"Simetrical" [email protected] wrote in message news:[email protected]...
In any case, the link given on the page is to the Wikidata branch. As far as I'm aware, that's a far bigger project than just a namespace manager. If there's no branch for just this feature, that complicates the issue even more.
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)
Simetrical schreef:
We have multiple big branch merges waiting around right now (e.g., rev_deleted, API edit, . . .).
Well ApiEdit_Vodafone is far from ready, and will be a small merge. My initial APIedit branch has been merged already.
One branch merge did sneak in a couple of months ago by merging one or two files at a time, but that was a very modular thing where the changes in different files weren't really related (basically separating some backend logic out from the interface logic).
Do you mean my refactoring of API modules and some core backend functions? That wasn't even a branch merge, I just wrote, tested and committed those refactorings one at a time.
Anyway, something that touches as deep upon the core code as Namespace Manager does should be in its own branch IMO. The perceived problem with branches is nonexistent if there's someone around to svnmerge every week or so and resolve conflicts. Sadly, a lot of branches appear to be unmaintained.
Roan Kattouw (Catrope)
On Feb 7, 2008 6:39 AM, Roan Kattouw [email protected] wrote:
Anyway, something that touches as deep upon the core code as Namespace Manager does should be in its own branch IMO. The perceived problem with branches is nonexistent if there's someone around to svnmerge every week or so and resolve conflicts.
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.
"Roan Kattouw" [email protected] wrote in message news:[email protected]...
Do you mean my refactoring of API modules and some core backend functions? That wasn't even a branch merge, I just wrote, tested and committed those refactorings one at a time.
No - it's two commits by maarten: r27641 and r27713.
- Mark Clements (HappyDog)
On Wed, Feb 06, 2008 at 05:03:44PM -0000, Mark Clements 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.
*This* is the cool bit, right here.
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]].
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" [email protected] wrote in message news:[email protected]...
On Wed, Feb 06, 2008 at 05:03:44PM -0000, Mark Clements 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.
*This* is the cool bit, right here.
And, it turns out, has already been implemented in the Namespace Manager code, so all that is needed is to add that code to trunk*! There are a few extra features that could make it easier to use for the specific purpose given at the start of this thread (i.e. a simple version that just allows namespace addition which is available to all users, with the extra functionality (alternative names, deletion, etc.) is reserved for bureaucrats) however it is enough to make the idea workable.
* Of course, I have no idea whether it is really that simple, but on the surface it looks like it is fully functional, and it is already being used on OmegaWiki...
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]].
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?
That is currently the way to do it, and I don't see any reason why it would stop working.
- Mark Clements (HappyDog)
Mark Clements schreef:
And, it turns out, has already been implemented in the Namespace Manager code, so all that is needed is to add that code to trunk*! There are a few extra features that could make it easier to use for the specific purpose given at the start of this thread (i.e. a simple version that just allows namespace addition which is available to all users, with the extra functionality (alternative names, deletion, etc.) is reserved for bureaucrats) however it is enough to make the idea workable.
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)
"Roan Kattouw" [email protected] wrote in message news:[email protected]...
Mark Clements schreef:
And, it turns out, has already been implemented in the Namespace Manager code, so all that is needed is to add that code to trunk*! There are a
few
extra features that could make it easier to use for the specific purpose given at the start of this thread (i.e. a simple version that just
allows
namespace addition which is available to all users, with the extra functionality (alternative names, deletion, etc.) is reserved for bureaucrats) however it is enough to make the idea workable.
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 :(
It would be good to get some input from Eric (who wrote the code) about this.
As far as I can see, it is all ready and waiting to go - just needs merging... might need some testing re: the upgrade process, but even that side of things appears to be covered!
- Mark Clements (HappyDog)
Jay R. Ashworth wrote:
Mark Clements wrote:
- Ability to specify for a namespace whether links without a namespace
prefix resolve to (a) the default namespace or (b) the current namespace.
*This* is the cool bit, right here.
Be aware that by moving [[Wikipedia:Foo]] to [[Help:Foo]] you may be creating red links! It should be handled with great care.
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?
[[:help]] already means help in main ns. And it shouldn't be changed to another thing.
On Feb 7, 2008 4:21 PM, Platonides [email protected] wrote:
Be aware that by moving [[Wikipedia:Foo]] to [[Help:Foo]] you may be creating red links!
Er, wouldn't it still leave a redirect?
"Simetrical" [email protected] wrote in message news:[email protected]...
On Feb 7, 2008 4:21 PM, Platonides
[email protected] wrote:
Be aware that by moving [[Wikipedia:Foo]] to [[Help:Foo]] you may be creating red links!
Er, wouldn't it still leave a redirect?
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)
Mark Clements 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.
I'm not really convinced this would be a serious problem, though. For the kinds of applications this feature would most likely be used (such as the "micro-wikis" this thread started from), I wouldn't expect cross-namespace moves to be common at all, and those who did them would presumably know what to expect. Compare the situation with the current transwiki process, where the same problem already occurs and is handled routinely.
Of course, if someone were to feel like implementing it, a "fix link targets" option for cross-namespace moves would be a nice cherry on top of this feature. Could be useful for transwikiing as well, and it might even be possible to make it fix relative subpage links too.