Brion et al.,
I'm through my to-do list for the namespace changes. They reside in the WIKIDATA branch.
a) Please review these changes and point out any remaining issues that need to be addressed.
b) Which branch should these changes be merged into once fully reviewed? HEAD or a separate release branch?
Best,
Erik
= The changes in a nutshell =
== Backend ==
- All namespace definitions are stored in the database (cached using memcached if available). Namespaces are objects stored in a global array, $wgNamespaces, and generally easier to deal with. - Any namespace can have an arbitrary number of names. This includes the canonical English name, the local translation, and synonyms. - Every namespace has a default name to which all other names redirect. - By default, "Image:" is now accessible through File:, Image:, Video: and Sound:. - Namespaces can have a default link prefix. Every unprefixed link in those namespaces will be treated as if it was prefixed with it. Example: In namespace [[Cookbook:Fish]], [[Pig]] could become [[Cookbook:Pig]]. The edit page in the namespace contains a notice to this effect. - Namespaces can be hidden from most selection lists, to make managing a site with hundreds of namespaces feasible. - The relationship between namespaces and talk pages is no longer hardcoded. Theoretically, we can relatively easily implement support for multiple talk pages associated with a namespace, for example.
== Namespace manager ==
- All the attributes of namespaces which are changeable can be changed through the namespace manager ([[Special:Namespaces]]). - The namespace manager allows merging "pseudonamespaces" into real ones. For example, Wikibooks uses a prefix "Cookbook:" for its Cookbook pages; the namespace manager provides a facility for merging all pages with this prefix, as well as the talk pages, into a real namespace. - By default, users in the 'bureaucrat' group have the necessary rights. We take some reasonable security precautions: - Deletions are not possible if a namespace contains pages. - System namespaces expected by MediaWiki can never be deleted. - Additions that would hide "pseudonamespaces" (hardcoded prefixes in page titles) or Interwiki links are not possible. - A separate permission exists for merging pseudonamespaces into non-empty real ones, since this action can be essentially irreversible. - It should not be possible to make changes which leave the database in an inconsistent or illogical state. No operation is performed unless all its parts can be completed. - Namespace additions, deletions, conversions and changes are logged. The logging of namespace changes could be improved, but should be sufficient for now.
== Install and Upgrade process ==
- When installing MediaWiki for the first time, the namespace definitions are loaded in the appropriate language. - When upgrading MediaWiki using update.php, any existing custom nanemspace definitions and settings (subpages etc.) should be imported.
== Page titles ==
- The page title is now passed to the skin in its components (action, namespace, title, suffix) rather than as a single string. These can be styled differently. In MonoBook, for example, the namespace component is now smaller and in italics. - This has resulted in some simplified interface messages.
== Future features ==
Some ideas for things that could be implemented:
- Read/write permissions associated with namespaces. - Namespace icons that are rendered as part of the page tite. - Complex namespace hierarchies. - Default "preload" template for a namespace. - Namespace view filters for users. This could make it feasible to use a single installation to set up a wiki farm. - And, of course, association of namespaces with Wikidata schemas. :-)
Erik Moeller wrote: [snip]
== Future features ==
Some ideas for things that could be implemented:
Also, perhaps add a 'Review' flag for namespaces so that pages within it are reviewable or not using Magnus's page review feature. I think right now it is hard-coded to only operate on the main ('0') namespace.
Jonathan Leybovich wrote:
Erik Moeller wrote: [snip]
== Future features ==
Some ideas for things that could be implemented:
Also, perhaps add a 'Review' flag for namespaces so that pages within it are reviewable or not using Magnus's page review feature. I think right now it is hard-coded to only operate on the main ('0') namespace.
It is, but that can just as well be fixed by other means.
What I didn't see in the list (just skimming through) was putting all this info into the XML export...
Magnus
On 12/19/05, Jonathan Leybovich jleybov@yahoo.com wrote:
Erik Moeller wrote: [snip]
== Future features ==
Some ideas for things that could be implemented:
Also, perhaps add a 'Review' flag for namespaces so that pages within it are reviewable or not using Magnus's page review feature.
Magnus's Rewiew extension is just that, and it doesn't make sense to make special considerations for extension in the main code by definition. If extensions want something from the main codebase their authors can add hooks to the main code and modify things with those hooks.
Ævar Arnfjörð Bjarmason wrote:
On 12/19/05, Jonathan Leybovich jleybov@yahoo.com wrote:
Erik Moeller wrote: [snip]
== Future features ==
Some ideas for things that could be implemented:
Also, perhaps add a 'Review' flag for namespaces so that pages within it are reviewable or not using Magnus's page review feature.
Magnus's Rewiew extension is just that, and it doesn't make sense to make special considerations for extension in the main code by definition. If extensions want something from the main codebase their authors can add hooks to the main code and modify things with those hooks.
What *would* make sense would be to add a way for extensions to add/set parameters to a namespace. That would cover all database/import/export functions once, so no need for an extension (any extension) to do this over and again.
Magnus
Ævar Arnfjörð Bjarmason <avarab@...> writes:
Magnus's Rewiew extension is just that, and it doesn't make sense to make special considerations for extension in the main code by definition. If extensions want something from the main codebase their authors can add hooks to the main code and modify things with those hooks.
But this "extension" already has its own table in the data model! Granted the review/validate feature can be coded to capture different data than it does now, but the presence of a VALIDATE table in the data model firmly entrenches the notion that pages are validateable within the Mediawiki "ontology". It thus shouldn't be bad design to recognize and control this notion elsewhere in the datamodel.
On 12/20/05, Jonathan Leybovich jleybov@yahoo.com wrote:
Ævar Arnfjörð Bjarmason <avarab@...> writes:
Magnus's Rewiew extension is just that, and it doesn't make sense to make special considerations for extension in the main code by definition. If extensions want something from the main codebase their authors can add hooks to the main code and modify things with those hooks.
But this "extension" already has its own table in the data model! Granted the review/validate feature can be coded to capture different data than it does now, but the presence of a VALIDATE table in the data model firmly entrenches the notion that pages are validateable within the Mediawiki "ontology". It thus shouldn't be bad design to recognize and control this notion elsewhere in the datamodel.
The only reason why there's a validate table in the main distribution is because Review used to be in the main code, the database definition will presumably be moved to the extensions module along with the rest in time, Magnus?
Ævar Arnfjörð Bjarmason wrote:
On 12/20/05, Jonathan Leybovich jleybov@yahoo.com wrote:
Ævar Arnfjörð Bjarmason <avarab@...> writes:
Magnus's Rewiew extension is just that, and it doesn't make sense to make special considerations for extension in the main code by definition. If extensions want something from the main codebase their authors can add hooks to the main code and modify things with those hooks.
But this "extension" already has its own table in the data model! Granted the review/validate feature can be coded to capture different data than it does now, but the presence of a VALIDATE table in the data model firmly entrenches the notion that pages are validateable within the Mediawiki "ontology". It thus shouldn't be bad design to recognize and control this notion elsewhere in the datamodel.
The only reason why there's a validate table in the main distribution is because Review used to be in the main code, the database definition will presumably be moved to the extensions module along with the rest in time, Magnus?
I thought about it, but then I realized that removing a table definition from the main distribution just to make people insert *the very same definition* from the extension manually (AFAIK, there's no way to do this automatically?) seems like ... well, insanity ;-)
Clean code is one thing, but what harm does that table do in the main distribution?
Magnus
On 19/12/05, Erik Moeller erik_moeller@gmx.de wrote:
I'm through my to-do list for the namespace changes. They reside in the WIKIDATA branch.
I haven't looked at or run the code yet, but this sounds like a very useful feature.
== Future features ==
One thing that I was pondering when you posted about this before is whether the "special behaviour" of namespaces like "Image:", "Category:", etc could be built into some kind of hooks mechanism. I know it seems silly, but I rather like the idea of modularising the code so that existing features can be treated as extensions, because it means extensions can be written that mimic or replace those features.
In this case, people sometimes say they want to develop new namespaces for references, or category-like namespaces for blogging, etc; I guess some such things could be done through wikidata, but then again, wikidata could be attached to namespaces via those same hooks. Maybe.
Like most of my ideas, this is complete head-in-the-clouds stuff, but I thought I'd put it out to the general conciousness anyway...
-- Rowan Collins BSc [IMSoP]
"Rowan Collins" rowan.collins@gmail.com wrote in message news:9f02ca4c0512210450o9647c30s@mail.gmail.com... On 19/12/05, Erik Moeller erik_moeller@gmx.de wrote: [snip]
One thing that I was pondering when you posted about this before is whether the "special behaviour" of namespaces like "Image:", "Category:", etc could be built into some kind of hooks mechanism. I know it seems silly, but I rather like the idea of modularising the code so that existing features can be treated as extensions, because it means extensions can be written that mimic or replace those features.
This would also likely provide for possible optimisation: modules could simply be replaced in one swell foop.
I imagine that progression towards PHP 5 would make this desirable too, since ISTR there's much more object-oriented facilities in that.
In this case, people sometimes say they want to develop new namespaces for references, or category-like namespaces for blogging, etc; I guess some such things could be done through wikidata, but then again, wikidata could be attached to namespaces via those same hooks. Maybe.
ObAOL: me, too!!!
This would make it possible, maybe, to have separate "category" namespaces for self-referential project-related stuff, to placate the purists who say we're cluttering up the airwaves.
Like most of my ideas, this is complete head-in-the-clouds stuff, but I thought I'd put it out to the general conciousness anyway...
I'm conscious? I suppose that would explain all the pretty colours :-)
On 21/12/05, Rowan Collins rowan.collins@gmail.com wrote:
One thing that I was pondering when you posted about this before is whether the "special behaviour" of namespaces like "Image:", "Category:", etc could be built into some kind of hooks mechanism. I know it seems silly, but I rather like the idea of modularising the code so that existing features can be treated as extensions, because it means extensions can be written that mimic or replace those features.
In this case, people sometimes say they want to develop new namespaces for references, or category-like namespaces for blogging, etc; I guess some such things could be done through wikidata, but then again, wikidata could be attached to namespaces via those same hooks. Maybe.
An excellent idea!
Image: Category: Template: Reference: *Table:* Task: Review: Poll: (AFD etc) Collection: (transclude polls; AFD)
The mind boggles. :)
Tomer Chachamu wrote:
On 21/12/05, Rowan Collins rowan.collins@gmail.com wrote:
One thing that I was pondering when you posted about this before is whether the "special behaviour" of namespaces like "Image:", "Category:", etc could be built into some kind of hooks mechanism. I know it seems silly, but I rather like the idea of modularising the code so that existing features can be treated as extensions, because it means extensions can be written that mimic or replace those features.
In this case, people sometimes say they want to develop new namespaces for references, or category-like namespaces for blogging, etc; I guess some such things could be done through wikidata, but then again, wikidata could be attached to namespaces via those same hooks. Maybe.
An excellent idea!
Image: Category: Template: Reference: *Table:* Task: Review: Poll: (AFD etc) Collection: (transclude polls; AFD)
So perhaps there could be a series of options that the bureaucrat toggles when he activates a namespace.
Ec
Ray Saintonge wrote:
Tomer Chachamu wrote:
On 21/12/05, Rowan Collins rowan.collins@gmail.com wrote:
One thing that I was pondering when you posted about this before is whether the "special behaviour" of namespaces like "Image:", "Category:", etc could be built into some kind of hooks mechanism. I know it seems silly, but I rather like the idea of modularising the code so that existing features can be treated as extensions, because it means extensions can be written that mimic or replace those features.
In this case, people sometimes say they want to develop new namespaces for references, or category-like namespaces for blogging, etc; I guess some such things could be done through wikidata, but then again, wikidata could be attached to namespaces via those same hooks. Maybe.
An excellent idea!
Image: Category: Template: Reference: *Table:* Task: Review: Poll: (AFD etc) Collection: (transclude polls; AFD)
So perhaps there could be a series of options that the bureaucrat toggles when he activates a namespace.
Ec
Hoi, The ease with which new namespaces can be created are in one way really scary. They will affect the behaviour of a project and it will be too easy to do just this. When a language version of a project decides to "go its own merry way" it may mean that the consistency in which Mediawiki works will go away. If there is one thing that should not happen is that a user on any level starts messing with namespaces without prior agreement. Using namespaces is a great way of improving our environment, it is also a sure way of making an absolute mess when this is done without careful deliberation.
The English Wikipedia is "leading" the way and it does not ask itself what the consequences are for the other language versions of the project. People mistake our mission, to create a great encyclopaedia with a stable encyclopaedia or a validated encyclopaedia. They are not necessarily the same thing. The Wiki way is about doing a good thing in a simple way and in a collaborative way. When we make what we do too complicated it loses the attributes what makes it work. Some people are of the opinion that Wikipedia has a "sufficient" size and to those people I want to point out that the sh.wikipedia for instance has *2,321* http://sh.wikipedia.org/wiki/Special:Statistics articles. That does not suffice.
Thanks, GerardM
Gerard Meijssen wrote:
Ray Saintonge wrote:
Tomer Chachamu wrote:
On 21/12/05, Rowan Collins rowan.collins@gmail.com wrote:
In this case, people sometimes say they want to develop new namespaces for references, or category-like namespaces for blogging, etc; I guess some such things could be done through wikidata, but then again, wikidata could be attached to namespaces via those same hooks. Maybe.
An excellent idea!
Image: Category: Template: Reference: *Table:* Task: Review: Poll: (AFD etc) Collection: (transclude polls; AFD)
So perhaps there could be a series of options that the bureaucrat toggles when he activates a namespace.
Ec
Hoi, The ease with which new namespaces can be created are in one way really scary. They will affect the behaviour of a project and it will be too easy to do just this. When a language version of a project decides to "go its own merry way" it may mean that the consistency in which Mediawiki works will go away. If there is one thing that should not happen is that a user on any level starts messing with namespaces without prior agreement. Using namespaces is a great way of improving our environment, it is also a sure way of making an absolute mess when this is done without careful deliberation.
I absolutely agree about the scarriness. In his message Erik speaks of the potential for 100,000 namespaces in a project, but that many would seem horribly counterproductive. The present 256 limit for the number of namespaces in a project seems more than enough, and in welcoming the namespace management concept it was still with that limit in mind. If any project approaches that limit it's in need of serious self-examination. Namespaces need to serve a useful function.
I find the willingness of people to keep designing new templates carry enough. They may very well save a lot of time for their inverntors and a few of their close collaborators. More often when that person leaves the project we are left to wonder just what these templates are doing, particularly if they form a series of nested templates.
The English Wikipedia is "leading" the way and it does not ask itself what the consequences are for the other language versions of the project. People mistake our mission, to create a great encyclopaedia with a stable encyclopaedia or a validated encyclopaedia. They are not necessarily the same thing. The Wiki way is about doing a good thing in a simple way and in a collaborative way. When we make what we do too complicated it loses the attributes what makes it work. Some people are of the opinion that Wikipedia has a "sufficient" size and to those people I want to point out that the sh.wikipedia for instance has *2,321* http://sh.wikipedia.org/wiki/Special:Statistics articles. That does not suffice.
The other side of that is that the en:wikipedia should not need to stand still waiting for everybody else to catch up.
Ec
Ray Saintonge wrote:
I absolutely agree about the scarriness. In his message Erik speaks of the potential for 100,000 namespaces in a project, but that many would seem horribly counterproductive. The present 256 limit for the number of namespaces in a project seems more than enough,
Actually, there's no such limit currently. Since 1.5 the namespace values are stored as 32-bit integers, so you could have a couple billion namespaces if you had the memory and CPU time to define them. ;)
In general though, they're not meant to be very many. Using 8-bit fields unduly limited the *key numbers* which could be used reliably, not so much the total number of namespaces.
-- brion vibber (brion @ pobox.com)
Rowan Collins:
One thing that I was pondering when you posted about this before is whether the "special behaviour" of namespaces like "Image:", "Category:", etc could be built into some kind of hooks mechanism.
Yes. These kinds of hooks are essential to Wikidata and Ultimate Wiktionary (especially the latter). It will be possible to attach different application classes to different namespaces. Wikidata will be one such application, providing versioning, search and user interfaces for arbitrary structured data. The methods in these classes will themselves contain hooks for extensions and customizations.
Besides reducing some of the "magic" of namespaces like NS_IMAGE, and the ability to add arbitrary structured content, Wikidata will have uses even within the default namespaces. NS_IMAGE is an excellent example. It is currently a table containing versioned structured content (the image metadata) that is, however, completely separate from the image description page (and still split in a CUR/OLD way). With Wikidata, this would just be a customized wiki page with some added fields and special hooks,
The best part is that the Wikidata design allows for translations, so you could add something like a default caption to the image page as a separate field, and translate it into all languages. When you type [[Image:Foo.jpg|thumb]] anywhere, it would then use the default caption in whatever language is appropriate. This could also be used on category galleries. And I've posted here before on the uses of Ultimate Wiktionary to translate category names. Commons will therefore be one of the major beneficiaries of Wikidata, with the goal being a move towards powerful, automatically localized tagging as the main method of organizing content.
But even this just scratching the surface. Wikidata and UW are hugely complex projects with enormous potential, if done right. Because they are so complex, we are trying to implement milestones which are independently useful. The namespace manager is one example, more will follow. I'll post further details soon.
One note on namespaces: The namespace manager is _not_ intended to add hundreds of namespaces to a wiki. Namespaces are for very large sets of pages (or special functionality). The Cookbook: namespace on Wikibooks is one example, the abandoned Jokebook: was another - but most books on Wikibooks are probably too small to deserve their own namespace.
Some people will doubtlessly create wikis with hundreds or thousands of namespaces, and run into some limitations. These may be addressed, but in the Wikidata context, we're typically dealing with few namespaces. For example, Ultimate Wiktionary, in spite of having a huge set of tables, will probably only have one or two namespaces. There are additional ways to restrict a set of content, and one idea I'm playing with are link parameters. To get just the "animal" definitions of the word dog in Ultimate Wiktionary, for example, you could use something like [[en:Dog|related to=Animal]].
Erik
wikitech-l@lists.wikimedia.org