Enhanced media player goodies like embedding have been slowly coming along,
with a handy embedding option now available in the fancy version of the
media player running on Commons. This lets you copy a bit of HTML you can
paste into your blog or other web site to drop in a video and make it
playable -- nice! Some third-party sites will also likely be interested in
standardish ways of embedding offsite videos from Youtube, Vimeo, and other
There's a lightweight standard out in the wild called oEmbed which I've
previously worked with on StatusNet: identi.ca uses it to show thumbnails
for flickr photos, youtube & vimeo videos, and other such things that get
called out in posts. Basically it specifies a discovery system for
automating the embedding process, so you can get a thumbnail image and/or
inline player HTML fragment that fits a reasonable size.
I'm interested in bringing oEmbed provider and consumer support to
MediaWiki, but there are a couple limitations: currently there's no exposed
license metadata (highly desired for Wikimedia's usage, obviously) and
cross-site embedding for videos currently requires the consuming site to
either drop raw HTML into their site (dangerous!) or maintain a second
domain for iframe content (difficult).
There's a discussion going on on the oEmbed list about updating the
standard, so if any of you out there have an interest in the wonderful world
of on-web media embedding and how we can make it work better for MediaWiki,
do feel free to pop your nose in. :)
there are two empty files in the distribution. Are they of any usage?
Weberhofer GmbH, Austria, Vienna
On 05/02/11 15:30, wikitech-l-request(a)lists.wikimedia.org wrote:
> Date: Tue, 03 May 2011 00:29:51 +0200
> From: Platonides<Platonides(a)gmail.com>
> Subject: Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong
> with Wikia's WYSIWYG?)
> Content-Type: text/plain; charset=ISO-8859-1
> Magnus Manske wrote:
>> > So, why not use my WYSIFTW approach? It will only "parse" the parts of
>> > the wikitext that it can turn back, edited or unedited, into wikitext,
>> > unaltered (including whitespace) if not manually changed. Some parts
>> > may therefore stay as wikitext, but it's very rare (except lists,
>> > which I didn't implement yet, but they look intuitive enough).
>> > Magnus
> Crazy idea: What if it was an/extensible/ editor? You could add later a
> module for enable lists, or "enable graphic<ref>", but also instruct it
> on how to present to the user some crazy template with a dozen parameters...
Seems like it will need to be extensible, to allow authors of MW
extensions to add support for cases where they've changed the parser's
We are happy to announce the general availability of the first public
release of the Sweble Wikitext parser, available from http://sweble.org.
The Sweble Wikitext parser
* can parse all complex Wikitext, incl. tables and templates
* produces a real abstract syntax tree (AST); a DOM will follow soon
* is open source made available under the Apache Software License 2.0
* is written in Java utilizing only permissively licensed libraries
You can find all relevant information and code at http://sweble.org –
this also includes demos, in particular the CrystalBall demo, which lets
you query a Wikipedia snapshot using XQuery.
The Sweble Wikitext parser intends to be a complete parser for Wikitext.
That said, plenty of work remains to be done.
At this stage, we are hoping for your help. You can help us by
* playing with the CrystalBall demo and pointing out to us wiki
pages that look particularly bad or faulty
* simply using the parser in your projects and telling us what
works and what doesn’t (bug reports)
* getting involved in the open source project by contributing
code, documentation, and good humor
If you have questions, please don’t hesitate to use the sweble.org
facilities or send email to info(a)sweble.org.