I just rediscovered this marvellous page:
http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
Browser stats from a very mainstream, top-5 website, pure and unbiased!
One interesting question missing there: OS breakdown?
Windows/Mac/Linux/various mobiles/other? Would it be feasible to list
these as well?
- d.
Hi,
I am using MediaWiki both for the "collective documentation" of in-house
projects, and as a CMS for the publication of my personal site.
Recently, I needed to publish as a RSS feed both a list of "important" articles
(manually maintained) and the table of content of some (if not all) articles.
There are quite few extensions listed in
http://www.mediawiki.org/wiki/Category:Feed_generator_extensions. But none of
them really does the trick. Mostly because the feed generator was required to be
*non intrusive*. I.e., usage of any special tag in the wikitext was prohibited.
In addition, it would have been preferable to work at *article* (by opposite to
querying the database).
For all there reasons (and well ... also for fun, I must admit;) ) I started to
work on a custom feed generator. In fact, it is mostly a wrapper around an XSLT
stylesheet that build a RSS feed from the /first/ list found in an article
parsed as HTML.
This has the advantage of working both for "in text" lists and for TOCs, since
those are generated as a list before the first heading. So they are likely to be
the first list of an article.
Moreover, since we are using the convention of beginning each article by a short
description (more or less like a Wikipedia article), that text was relatively
easy to extract as the description of the feed.
Of course, this is not 100% bulletproof, but it works most of the time. And
require only to add "?action=tofeed" at the end of the URL to retrieve the feed
of that article (could easily be hidden thought url rewriting).
Now, I think it would be great to share that code with the community. So here I
join the source of this extension and the stylesheet. And I would be glad if
anyone could take time to review that code. And telling me if I'm doing the
things "the right way". Any hint or advice would also been greatly appreciated ;)
Best regards,
Sylvain.
PS/You could try it "live" on my site:
http://www.chicoree.fr/w/Derniers_articles?action=tofeedhttp://www.chicoree.fr/w/Installer_JBoss_AS_5?action=tofeed
Those articles are in French. But at least it should let you have the feeling
how it works.
--
sylvain(a)chicoree.fr
http://www.chicoree.fr
hi Daniel, all,
Jakob Voss informed me that there had been a posting regarding memento
on this list. Since we are very keen on native Memento support for the
mediawiki platform, I felt like responding by giving some perspective
on Memento in general, and on some questions that were raised
regarding its implementation for mediawiki, specifically:
1. As with previous projects we have engaged in (OpenURL, OAI-PMH, OAI-
ORE, SRU/W), Memento is not merely an academic exercise about which we
want to publish papers. Given our status as researchers, we do need
to publish the occasional paper but the real goal of the project is to
make datetime content negotiation for the Web really happen. Doing so
will require a lot more work, at various levels, including:
a. formal specification (we are thinking an Internet Draft => RFC path),
b. promotion,
c. real life implementations,
d. further research.
Currently, we are focusing on (b) and (c) to try and overcome a
chicken and egg situation: we think we propose a nice framework to
integrate archival content seamlessly in regular web navigation, but
in order to demonstrate it we need some adoption. But in order to get
some adoption we need to be able to demonstrate the framework, which
we can't do without adoption. Etc. ;-)
It is in this context that our contact with Jakob Voss, and Daniel's
mail on this list, is really exciting. The ability to demonstrate
Memento at work for mediawiki platform, including the Wikipedia
deployments, would be absolutely fantastic for the Memento cause. That
is why we have immediately engaged in further development of our
initial prototype Memento plug-in for mediawiki, to take into account
remarks made by Jakob, and to make it more robust. The ongoing work is
at http://www.mediawiki.org/wiki/Extension:Memento .
2. Let me describe the actual status and challenges faced in the
Memento plug-in work:
2.1. The plug-in detects a client's X-Accept-Datetime header, and
returns the mediawiki page that was active at the datetime specified
in the header. Same for images, actually. This effectively allows
navigating (as in clicking links) a mediawiki collection as it existed
in the past: as long as a client issues an X-Accept-Datetime header,
matching history pages/images will be retrieved.
2.2. We are looking into addressing this issue raised by Jakob (and
Daniel): Display history pages with the template that was active at
the time the history page acted as the current one. We definitely
think this would be cool, but we don't think it can be achieved by our
plug-in because templates are included at the server side, i.e. they
are not URI-addressed XSL that are rendered at the client-side. Hence,
one can't do datetime content negotiation on them - they are outside
of the memento realm and rather in the realm of the CMS. So, we are
looking at the mediawiki code to see whether a history page, when
rendered, could itself retrieve the appropriate (old) template from
the database. If we are successful, we will share that code also at http://www.mediawiki.org/wiki/Extension:Memento
once available. It will obviously be up to the mediawiki community
whether they are willing to adopt the proposed change to the codebase.
2.3. We have looked into another issue raised by Jakob: Display
deleted pages as they existed at the datetime expressed in X-Datetime-
Accept. We have actually implemented this. There are 2 caveats:
- as is the case with mediawiki in general, deleted pages are only
accessible by those with appropriate permissions;
- as is the case with mediawiki in general, deleted pages show up in
Edit mode.
This code will soon be included at http://www.mediawiki.org/wiki/Extension:Memento
.
2.4. We do not feel that all pages should necessarily be subject to
datetime content negotiation, in the same way that not all URIs are
subject to content negotiation in other dimensions. We feel that the
Special Pages fall under this category, as they do not have History.
2.5. We have ideas regarding how to address the issue raised by
Daniel: the timestamp isn't a unique identifier, multiple revisions
*might* have the
same timestamp. From the perspective of Memento, a datetime is
obviously the only "globally" recognizable value that can be used for
negotiation. If cases occur where multiple versions of a page exist
for the same second, the thing to do according to RFC 2295 would be to
return a "300 Mutliple Choices", listing the URIs (and metadata) of
those version in an Alternates header. The client then has to take it
from there.
2.6. The caching issue is a general problem arising from introducing
Memento in a web that does not (yet) do Memento: when in datetime
content negotiation mode all caches between client and server (both
included) need to be bypassed. As described in our paper, we currently
address this problem by adding the following client headers:
Cache-Control: no-cache => to force cache revalidation, and
If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT' to enforce
validation failure
We very much understand this is not elegant but it tends to work ;-) .
This is an area for further research. As the paper states: "Ideally,
a solution should leverage existing caching practice but extend it in
such a way that caches are only bypassed in DT-conneg when essential,
but still used whenever possible (e.g., to deliver Mementos)."
I hope this helps. Please let us know what we can do to increase the
chances of adoption of the Memento solution for the mediawiki
platform. I hope it is clear that we _really_ would like to see this
happen!
Cheers
Herbert Van de Sompel
==
Hi all
The Memento Project <http://www.mementoweb.org/> (including the Los
Alamos
National Laboratory (!) featuring Herbert Van de Sompel of OpenURL
fame) is
proposing a new HTTP header, X-Accept-Datetime, to fetch old versions
of a web
resource. They already wrote a MediaWiki extension for this
<http://www.mediawiki.org/wiki/Extension:Memento> - which would of
course be
particularly interesting for use on Wikipedia.
Do you think we could have this for Wikimedia project? I think that
would be
very nice indeed. I recall that ways to look at last weeks main page
have been
discussed before, and I see several issues:
* the timestamp isn't a unique identifier, multiple revisions *might*
have the
same timestamp. We need a tiebreak (rev_id would be the obvious choice).
* templates and images also need to be "time warped". It seems like the
extension does not address this at the moment. For flagged revisions
we do have
such a machnism, right? Could that be used here?
* Squids would need to know about the new header, and by pass the
cache when
it's used.
so, what do you think? what does it take? Can we point them to the
missing bits?
-- daniel
==
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
tel. +1 505 667 1267
I am working with some enwiki-{YYYYMMDD}-stub-meta-history.xml dumps and
wanted to get clarification on how certain fields of the articles can
change:
1. What action will make an article get a new pageId? Is it
only move/rename, a redirect, or a deletion and recreation, or are there
other ways this could happen? Can any of these changes be detected from the
stub-meta-history.xml files?
2. Is it possible for just one particular revision of an article to be
deleted, maybe due to a copyright violation? If so, is just the content of
the revision deleted or would this include all the data associated with it,
so that the revision would not even appear in the stub-meta-history.xml
file?
3. Are pageIds recycled? If a page is deleted, could its id number be used
for a completely new page in the future?
Thanks,
Jeff
--
Jeff Kubina
http://google.com/profiles/jeff.kubina
hi,
I just added some code to the MonoBook.php.
function updateBox() {
?>
<div id="p-update" class="portlet">
<h5><label for="updateInput"><?php $this->msg('update') ?></label></h5>
<div id="updateBody" class="pBody">
<form action="..\includes\update\update.php" method="post"
id="updateform"><div>
<input type='submit' name="update" class="updatehButton"
id="updateButton" value="<?php $this->msg('dataupdate') ?>" />
</div></form>
</div>
</div>
<?php
}
This can add a button to the sidebar,but when i clicked the button,it can't
link to the update.php. It shows error instead"You can not access the
specified web page!".
update.php
just has the content of
<?php
echo "hello";
Why do these things happen? If I want to do the right thing that when I
click the button then there'll link to the page that has the same page
performance as wiki.
What should I do?
Hlep me !
Thanks a lot.
vanessa lee
Just wanted to give a heads up aside from the subtitles we hacked on at
the Paris meetup... mwEmbed now supports being called with a uselang
param (so it can be added to other wikis as a gadget to broaden the
mwEmbed / js2 localization testing and or used in your user-language ) ...
(some features are new so the user msgs have not been fully translated yet.)
You can test the other languages by changing your interface language in
you preferences. Then add-media-wizard, firefogg, subtitles, html 5
video player etc should come up in your selected language.
To add to a new wiki gadget list you can:
go to your-> MediaWiki:Gadget-mwEmbed.js
and put the following in:
importScriptURI('http://prototype.wikimedia.org/s-2/js2/remoteMwEmbed.js?urid=58804&uselang='
+ wgUserLanguage );
then go to -> MediaWiki:Gadget-mwEmbed
and add a localized version of the following wikitext:
Add ''mwEmbed'' support for [[mw:Extension:MwEmbedPlayer|video
playback]], [[mw:Extension:Firefogg|Firefogg uploading]] and the
[[mw:Extension:Add_Media_Wizard|"Add-Media-Wizard"]]. (These components
are still evolving; you can help by providing feedback and bug reports
on the respective talk pages.)
and then finally add it to the gadget display list at ->
MediaWiki:Gadgets-definition.
peace,
michael
If there are no objections, I'd like to activate the updated
per-directory access control file shown at:
http://svn.wikimedia.org/authz
I've removed the restrictions on the release branches, as per Aryeh's
comments. Instead only the wmf-deployment branch is restricted to a
small group. The core/extensions split remains. The core access group
is broad, and includes recently-added subversion users who expressed
an interest in contributing to the core.
It's my understanding that such a scheme would have reasonably wide
support.
-- Tim Starling
Back in July, we had a lengthy discussion about the possibility of
switching to HTML5:
http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/043865.html
The conclusion appeared to be that switching to HTML5 was a good idea.
As of July 12 (r53142), MediaWiki has been outputting HTML5
continuously as the default:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/53142
There have been only a few minor problems reported by various trunk
users, all of which were quickly fixed. The current state of HTML5
support is discussed here:
http://www.mediawiki.org/wiki/HTML5
When we had our last scap six weeks ago, $wgHtml5 was disabled on
Wikimedia to reduce the number of variables to keep track of, since a
huge amount of code was changing at once. Although we're currently in
the middle of some organizational issues due to Brion's resignation, I
think it would be safe to experimentally turn on $wgHtml5 and see what
happens. If any problems are reported that can't be fixed
immediately, of course, it could be turned off again, but I think this
is quite unlikely. I'll be available for the next few weeks to work
on any issues that arise. Would this be okay?
Dan Rinkes (tidan): various special page extensions
Matěj Grabovský (mgrabovsky): core, localisation, etc.
Michael Daly (michaeldaly): ImageMapConversion extension
-- Tim Starling