Wikipedia has hundreds of wonderful portals on every imaginable topic. These are perhaps one of the most underexposed treasures on the site. It would be lovely if people could subscribe to a portal feed, or individual "boxes" (typical portal arrangement is into rectangles with different content). Example: http://en.wikipedia.org/wiki/Portal:Free_software
How could this be achieved? One way would be to support an RSS extension that would operate as follows:
1) You put something like
<makefeed> title=Selected article on free software addto=freesoftware.xml addto=freesoftware-sel.xml </makefeed> <feedicon> feed=freesoftware-sel.xml </feedicon>
inside a template, or indeed any page.
2) When a user edits a page, the extension checks for the presence of <makefeed> in the wikitext. If it is present, it adds a
( ) Add as new item to RSS feed ( ) Update most recent RSS feed item for this page (x) no change
selection to the page, below where the minor edit checkbox is. This selection should only be available to users with a definable permission level (e.g. autoconfirmed).
3) The feeds could be directly updated/written on the disk, in the images/ directory. In any case, the <feedicon> tag would generate a pretty link to a feed with a given name.
The feed content would be the action=render output for the page where the <makefeed> instruction is found (ideally sans noinclude). It could also include the edit summary.
Given that a feed could be accessed from multiple pages, you could build aggregated feeds (in the above example, freesoftware.xml would be a feed for the whole free software portal) and individual ones (freesoftware-sel.xml would only be the selected article box). You'd have to do some clever scanning of the file on disk to make safe updates, but it shouldn't be too hard.
Any conceptual flaws? Any takers? I think this could really make a big difference for content re-use, not just in the context of Wikipedia. But the portals seem like a particularly attractive target application to me.
I've written an extension that does something similar to what you're asking. It's called WikiArticleFeeds:
http://www.mediawiki.org/wiki/Extension:WikiArticleFeeds
It's not exactly what you want - but the syntax is really easy (I'm combining an example with a description of what it does, hope it makes sense):
---------------------------------------------- Text in page before feed - ignored for RSS/Atom purporses. <startFeed />
Any text before the first Heading becomes the description of the feed (this text).
== Item Two ==
Typically it's good practice to list feed items in reverse chronological order (newest on top).
--[[User:Someuser|Someuser]] 08:52, 5 December 2006 (MST)
== Item One ==
The extension picks out the "highest" level Heading as the Item level.
=== So this third-level heading ===
And this text both belong to Item One.
--[[User:Someuser|Someuser]] 08:42, 4 December 2006 (MST)
<endFeed />
Note that both startFeed and endFeed are self-closing tags with no internal text or arguments.
This text (and the preceding note) are again ignored by the extension since they're not in the start/end blocks.
<startFeed /> == Item Three ==
Since this page has two startFeed/endFeed pairs, the resulting RSS/Atom feeds will contain all items from both sections.
This means that you could have a series of disperate feeds that you transclude together on one page for aggregation.
--[[User:Someuser|Someuser]] 18:42, 6 December 2006 (MST)
== Item Four ==
The publication dates and authors for feed items are taken from the first instance of ~~~~ in the item.
Also, you may know that RSS/Atom feeds can have associated URLs. WikiArticleFeeds will look for the first link (internal or external, as long as it's not part of a ~~~~ segment) and use that URL as its own link.
If your feed item has no links, it defaults to [[#ITEM TITLE]] which in this case would be "Item Four".
--[[User:Someuser|Someuser]] 08:48, 7 December 2006 (MST) <endFeed /> ----------------------------------------------
Also, please note that the parsing for feed Items that WikiArticleFeeds does occurs AFTER mediawiki has converted the wikitext into HTML. This means that it (should be) totally agnostic towards templates and custom parser functions (though I haven't extensively tested this yet).
If you decide to use it, I'd love to hear your feedback. Thanks!
btw - if you want to see an example site, I'm currently using this to power my Blog:
http://jimbojw.com/wiki/index.php?title=Blog
-- Jim R. Wilson (jimbojw)
On 2/17/07, Erik Moeller erik@wikimedia.org wrote:
Wikipedia has hundreds of wonderful portals on every imaginable topic. These are perhaps one of the most underexposed treasures on the site. It would be lovely if people could subscribe to a portal feed, or individual "boxes" (typical portal arrangement is into rectangles with different content). Example: http://en.wikipedia.org/wiki/Portal:Free_software
How could this be achieved? One way would be to support an RSS extension that would operate as follows:
- You put something like
<makefeed> title=Selected article on free software addto=freesoftware.xml addto=freesoftware-sel.xml </makefeed> <feedicon> feed=freesoftware-sel.xml </feedicon>
inside a template, or indeed any page.
- When a user edits a page, the extension checks for the presence of
<makefeed> in the wikitext. If it is present, it adds a
( ) Add as new item to RSS feed ( ) Update most recent RSS feed item for this page (x) no change
selection to the page, below where the minor edit checkbox is. This selection should only be available to users with a definable permission level (e.g. autoconfirmed).
- The feeds could be directly updated/written on the disk, in the
images/ directory. In any case, the <feedicon> tag would generate a pretty link to a feed with a given name.
The feed content would be the action=render output for the page where the <makefeed> instruction is found (ideally sans noinclude). It could also include the edit summary.
Given that a feed could be accessed from multiple pages, you could build aggregated feeds (in the above example, freesoftware.xml would be a feed for the whole free software portal) and individual ones (freesoftware-sel.xml would only be the selected article box). You'd have to do some clever scanning of the file on disk to make safe updates, but it shouldn't be too hard.
Any conceptual flaws? Any takers? I think this could really make a big difference for content re-use, not just in the context of Wikipedia. But the portals seem like a particularly attractive target application to me. -- Peace & Love, Erik
DISCLAIMER: This message does not represent an official position of the Wikimedia Foundation or its Board of Trustees.
"An old, rigid civilization is reluctantly dying. Something new, open, free and exciting is waking up." -- Ming the Mechanic
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, 17 Feb 2007 08:06:03 +0100, Erik Moeller erik@wikimedia.org wrote:
Wikipedia has hundreds of wonderful portals on every imaginable topic. These are perhaps one of the most underexposed treasures on the site. It would be lovely if people could subscribe to a portal feed, or individual "boxes" (typical portal arrangement is into rectangles with different content). Example: http://en.wikipedia.org/wiki/Portal:Free_software
How could this be achieved? One way would be to support an RSS extension that would operate as follows:
<snip>
This is not exactly what you asked, but if you don't mind manualy editing the feed (you can use templates to ease the work). It's perfectly possible to create custum RRS feeds within the existing MediaWiki software. Just create a page (or subpage) somewhere with the raw XML code for the feed, then link to it with the options:
&action=raw&ctype=application/rss+xml
added to the end of the URL. See for example the "podcast" RRS put togeter by the English Wikipedia spoken articles project: http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Spoken_Wikipedia/rss&action=raw&ctype=application/rss+xml
The "normal" version of the page is here http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Spoken_Wikipedia/rss, the XML looks like crap in HTML view naturaly, but with the added raw and content type parameters set it works like a charm (asuming you have a OGG capable software that can subscribe to feeds (I use Winamp)).
On 2/17/07, Sherool jamydlan@online.no wrote:
&action=raw&ctype=application/rss+xml
I get
Content-Type: text/x-wiki; charset=utf-8
as header. This might cause some RSS clients to fail.
Bryan
On 2/17/07, Erik Moeller erik@wikimedia.org wrote:
Wikipedia has hundreds of wonderful portals on every imaginable topic. These are perhaps one of the most underexposed treasures on the site.
True. Some wikipedias (like FR) show a link to the relevant portal on article pages. For example: http://fr.wikipedia.org/wiki/Chimie
That would also be an improvement.
Steve
On Saturday 17 February 2007 14:35:03 Steve Bennett wrote:
True. Some wikipedias (like FR) show a link to the relevant portal on article pages. For example: http://fr.wikipedia.org/wiki/Chimie
That would also be an improvement.
I don't want to talk much about Wikipedia and content here on this technical list but I had to comment that.
Links from article namespace into other namespaces are EVIL.
Why?
MediaWiki introduced namespaces in order to separate content and content management. Portals are content management not core content themselves. That's why portals were moved into their own namespace. And yes we even have an own special page in order to find such wrong page links: Special:CrossNamespaceLinks
Now imagine a Wikipedia DVD with lots of strange links into other namespaces. I certainly want a DVD that does not contain the online Wikipedia specific portal pages (which contain things such as news, calls for reviews and not et existing articles).
So BURN all portal links in article namespace NOW. Portals are useful but not everyhwere.
Arnomane
On 2/17/07, Daniel Arnold arnomane@gmx.de wrote:
Links from article namespace into other namespaces are EVIL.
[...]
So BURN all portal links in article namespace NOW. Portals are useful but not everyhwere.
Check out the main pages of en: (top-right), de:, fr:, it: and so on... the most prominent links are portal links.
Ciao, Alfio
On Saturday 17 February 2007 18:06:35 Alfio Puglisi wrote:
On 2/17/07, Daniel Arnold arnomane@gmx.de wrote:
Links from article namespace into other namespaces are EVIL.
[...]
So BURN all portal links in article namespace NOW. Portals are useful but not everyhwere.
Check out the main pages of en: (top-right), de:, fr:, it: and so on... the most prominent links are portal links.
The main pages are an exception and should be moved into project namespace anyways.
What about moving the mainpage in mediawiki to project namespace by default (it is just one change in MessagesXX.php)?
Arnomane
On 2/18/07, Daniel Arnold arnomane@gmx.de wrote:
Links from article namespace into other namespaces are EVIL.
So you reject links to categories as well, presumably. And disambiguation links to mediawiki and wikipedia namespaces?
MediaWiki introduced namespaces in order to separate content and content management. Portals are content management not core content themselves.
This is not an argument against linking from one space to another. If you're worried about downstream content reusers, the easy solution is to use a template like {{selfref}} to indicate that a link is not part of the encyclopaedic content.
Now imagine a Wikipedia DVD with lots of strange links into other namespaces. I certainly want a DVD that does not contain the online Wikipedia specific portal pages (which contain things such as news, calls for reviews and not et existing articles).
There's a huge amount of processing that needs to be done before we could put out a top quality Wikipedia DVD. Stripping out cross-namespace links is the least of our worries.
So BURN all portal links in article namespace NOW. Portals are useful but not everyhwere.
Um, as pointed out, currently there aren't any. Or are you talking about fr and other languages?
Steve
On Sunday 18 February 2007 01:44:47 Steve Bennett wrote:
On 2/18/07, Daniel Arnold arnomane@gmx.de wrote:
Links from article namespace into other namespaces are EVIL.
So you reject links to categories as well, presumably. And disambiguation links to mediawiki and wikipedia namespaces?
I was waiting for this answer.
A [[Category:Foobar]] link can *easily* be stripped out of the text. In every stage of the artice it is clear that it cannot be embedded into text (just because it is always displayed outside the text) so none will come to the idea making removal of a category hard ([[:category:foobar]] is something different and is evil in articles).
A template does not generate an endless chain of links. A template embedding always comes to an end. And disambiguation is a template (although specially treated by mediawiki).
But a link like [[Wikipedia:foobar]] *never* comes to and end. You can follow the links of the linked page and so on.
This is not an argument against linking from one space to another. If you're worried about downstream content reusers, the easy solution is to use a template like {{selfref}} to indicate that a link is not part of the encyclopaedic content.
I am not interested in inventing yet another meta content template. It is hard enough handling the existing ones (like navigation bars and this is a $foobar stub and foobar-display-problems) already.
There's a huge amount of processing that needs to be done before we could put out a top quality Wikipedia DVD. Stripping out cross-namespace links is the least of our worries.
Cross namespace links are one problem but surely not the only one. I know what I am talking about as I have done such work myself and did produce a real world result. See http://de.wikipedia.org/wiki/Wikipedia:WikiReader/Sonnensystem. Also cross wiki links in articles about Wikipedia itself are a common problem. They should be done as usual weblinks also in order to reflect distance to oneself.
So BURN all portal links in article namespace NOW. Portals are useful but not everyhwere.
Um, as pointed out, currently there aren't any. Or are you talking about fr and other languages?
I have seen such links in any larger Wikipedia edition language be it in en, de or fr.
Anyways this is off-topic on this list...
Arnomane
So you reject links to categories as well, presumably. And disambiguation links to mediawiki and wikipedia namespaces?
I was waiting for this answer.
A [[Category:Foobar]] link can *easily* be stripped out of the text. In every stage of the artice it is clear that it cannot be embedded into text (just because it is always displayed outside the text) so none will come to the idea making removal of a category hard ([[:category:foobar]] is something different and is evil in articles).
I was talking about [[:Category:...]] links. Since we were talking about "evil" links across namespaces. Let's take an example: http://en.wikipedia.org/wiki/Administrative_divisions_of_Connecticut
Note the links: * See also: Category:Villages in Connecticut
This is obviously a useful link. It takes the user to a dynamic, always-up-to-date list of every article in Wikipedia that is about a village in Connecticut. There's nothing remotely "evil" about it.
Here's another one: http://en.wikipedia.org/wiki/List_of_ski_areas The category links effectively tell the reader "this page may not be up to date. click here for a guaranteed up to date list".
This is not an argument against linking from one space to another. If you're worried about downstream content reusers, the easy solution is to use a template like {{selfref}} to indicate that a link is not part of the encyclopaedic content.
I am not interested in inventing yet another meta content template. It is hard enough handling the existing ones (like navigation bars and this is a $foobar stub and foobar-display-problems) already.
How does "use a template like {{selfref}}" equate to "invent yet another meta content template"?
http://de.wikipedia.org/wiki/Wikipedia:WikiReader/Sonnensystem. Also cross wiki links in articles about Wikipedia itself are a common problem. They should be done as usual weblinks also in order to reflect distance to oneself.
Wait, so now it's ok to make links to articles about Wikipedia, as long as they're formatted as [http:// ] links rather than [[ ]] links. And yet you really don't want to use templates? You're clearly trying to encode a semantic distinction ("distance to oneself"), so why not use a semantic template?
Steve
On 18/02/07, Steve Bennett stevagewp@gmail.com wrote:
So you reject links to categories as well, presumably. And disambiguation links to mediawiki and wikipedia namespaces?
[snippety snip]
Hang on, hang on; this thread started out with Erik posting a brainstorm for a new extension. How the hell did this turn into a debate about cross-namespace links, and the evilness of portals? Change the thread subject, at the least, please. Better still, get it off our mailing list.
Rob Church
wikitech-l@lists.wikimedia.org