1. I modified http://www.mediawiki.org/wiki/Template:Extension
which renders the Infobox to include three instead of two links:
list open bugs - list all bugs - report a bug
This makes it easier to file a bug and avoids mistakes, as "report a
bug" now directly brings users to the correct bug component
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…<Extensionname>
If this has not been set up, Extension maintainers with their extensions
in SVN can simply add
bugzilla=<componentline>
e.g. add
bugzilla=LiquidThreads
to the template call on their extension page.
2. Started to make extensive use of {{shortcut | <shortcutname> }} on
Extension pages,
and would like to encourage you to help adding such markers for
important extensions or extensions you maintain, too.
Will find a way to make that case-insensitive. Currently, shortcutnames
are uppercase. Personally, I would prefer to have the shortcuts working
case-insensitively, and also printed the shortcutnames in lower-case,
but this is more a style and guideline question.
3. Published a third book in http://www.mediawiki.org/wiki/MVL :
MediaWiki Interwiki and Interlanguage Guide
<http://en.wikipedia.org/wiki/User:Wikinaut/Books/MediaWiki_Interwiki_and_In…>
( MVL = MediaWiki Virtual Library )
As I like the books very much, perhaps you can help to publish about
that MVL in other places. I will contact the SignPost Editor to write
something about the MVL.
Tom
Greetings all.
We're moving into our first testing stage for the new mobile extension
and we'd love your help. You can find all the details on todays blog
post at http://blog.wikimedia.org/2011/06/10/testing-mobile-prototype/
Come help test, develop, or just ask about our mobile efforts on irc
freednode #wikimedia-mobile.
For those new to the mobile projects check out
http://meta.wikimedia.org/wiki/Mobile_Projects for background.
--tomasz
There has been some talk among developers and others about bundling some
extensions with the tarball. The new installer supports enabling
extensions during installation, so if we're going to do it, I would like
to start bundling them with the 1.18 tarball.
Part of my motivation is that many people seem to install MediaWiki and
expect a wiki that acts very similar to Wikipedia, with which they are
more familiar. Now, part of the problem is documentation — these people
don't understand how the functionality of MediaWiki is partitioned. But
in addition to documentation, we can start providing the most expected
functionality in the tarball.
Immediately, the objection of “bloat” would be raised. To alleviate
this concern, we can still provide a “MediaWiki-lite” tarball with only
the contents of phase3 as before.
Assuming that we are going to put *some* extensions in, we need to
decide which ones. Based on the problem reports in Bugzilla, I think at
least Cite and ParserFunctions should be bundled. Others would be
Gadgets and WikiEditor.
So my list would be:
Cite
ParserFunctions
Gadgets
WikiEditor
Have a look at http://en.wikipedia.org/wiki/Special:Version or
http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and
see which you would recommend we include.
Mark.
Amir Aharoni is planning two developer days just before this year's
Wikimania -- August 2nd and 3rd in Haifa, Israel. If you're planning on
being there, add your name!
http://wikimania2011.wikimedia.org/wiki/Developer_Days#Attendees
This developers' meeting is an opportunity for Wikimedia's software
developers to come together, test software in diverse languages and on
diverse devices, squash bugs and write awesome new features.
It's a perfect opportunity to work on right-to-left language support, of
course, but what else would you like to work on? Please add your
ideas. This'll help recruit attendees, and help us knock out any
dependencies in the eight weeks between now and the hackfest.
http://wikimania2011.wikimedia.org/wiki/Developer_Days#Topics
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
I am looking at the WOM extension, but I am not sure if it is the correct extension for us. We want is an api call that takes a wiki page - either parses the wiki markup (or removes wiki markup) then sends back an xml of the page content. The regular wiki api gives us pages with wiki markup within it.
We tried something like this:
api.php?action=womget&page=Somepage&xpath=//*
It did not seem to do what we expected.
Do you mind letting me know if we are looking at the correct extension?
We have a Java application that works with the page content that we get back.
Thanks,
Mary Beebe
Hello,
I've looked around for methods to manipulate the cache duration for a
given article. There are methods to facilitate the expiration of an
article, and there are extensions that can disable caching for articles
via convenient management interfaces. What seems to be lacking though,
is a way to expire the article after some duration. For instance, I'm
working with embedded RSS feeds... from what I'm finding I have 3 options:
1. Live with the RSS feed being cached.
2. Immediately invalidate the article cache so that the next
request causes the article to be rebuilt.
3. Tell users to use action=purge (or provide a button to
manually do this (or invalidate the cache).
The first option is not really an option :) The second option is
inefficient. The third option is unpalatable.
So the question becomes-- Would it be possible to have a new field added
to the page database table that determines the duration of the cache?
This would be optimal because extensions could then auto determine the
maximum duration of the article either by directly manipulating the
table entry, or preferably via a hook when the article is saved.
Failing a change to the MediaWiki core, I guess I could create a service
extension that uses it's own database table to track durations and
checks for expirations via the job system at which time it could
invalidate articles. But that seems roundabout for something that
strikes me as better supported in the core.
Thoughts?
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
Hi all,
MediaWiki has a user setting to add a CSS class to article links whose length is
below a certain threshold (preferences/appearance/advanced options/threshold for
stub link formatting). Is it possible to enable this by default on a Wikimedia
wiki? Some of the advantages:
- a lot of editors seem to use it already to find articles which need some care,
and currently it slows down page loading for them because it breaks caching, so
they could work quicker.
- like red links, it could bring in new editors by making readers realize that
some of the linked articles need help.
- it could make readers waste less time because they could realize the article
is a stub without clicking at it.
On the other hand, I suppose it would raise database load because the length of
all linked pages would need to be queried at HTML generation. (Or is that query
already already necessary to see which links are red?)