Since the video discussion has come up elsewhere, I thought I'd
forward this old message here where someone might find it of interest.
Since I never heard back on this I went ahead and coded an external
tools which extracts ogg metadata and image page data from files on
our system and outputs a [[json]] blob.
Example: http://tools.wikimedia.de/~gmaxwell/cgi-bin/mediainfo.py?url=http%3A%2F%2Fu…
It extracts all the ogg tags, including the width and height from
videos that some players need in order to correctly size the output.
It also grabs the HTML on the images pages for embedding
description/licensing material in the player pop up window.
I did this so I'd have something to code the below proposed new
mediaplayer design stuff against. It would still be much better to
have the metadata extraction in mediawiki, however.
---------- Forwarded message ----------
From: Gregory Maxwell <gmaxwell(a)gmail.com>
Date: May 14, 2007 4:04 AM
Subject: Mediaplayer specs
To: tstarling(a)wikimedia.org
Sorry I didn't have more time to talk to you this evening regarding
media player stuff.
I wanted to drop you a quick note in case you decide to start coding
something, I don't want you going down the wrong path.
Increasingly I've been convinced that the Right Way(tm) to handle
audio/video player launching is largely through client side
javascript.
I can argue this from three primary angles:
#1 It's how most everyone else does it. Youtube, and a zillion other
sites that make video their business actually handle launch the player
(be it flash or whatever) via client side JS.
#2 It's the only reasonable way to handle inline players in articles .
We don't want articles with inline multimedia content spawning java
interpreters/plugins/etc until the users demand it. If we cause the
players to load as soon as the user loads the page we'll waste
bandwidth, cause performance problems, and risk crashing browsers (a
user with a broken browser that crashes when he clicks something he
can easily avoid is much better off than pages that crash as soon as
he loads them)
#3 It's the only reasonable way to handle detection of playback
methods. Today there are four distinct ways of playing video that I'm
supporting:
* <video/> tag. Part of WhatWG's HTML5 draft, includes support for
Theora+Vorbis as the baseline. Already supported by Opera 9.5 beta,
expected in FF3 (under active development).
* Application/Ogg support. Generic pluging handling ogg files, works
on most modern linux desktops, and for some folks who have QT + XiphQT
codecs installed.
* VLC plugin, works for people with the VLC plugin installed (Linux,
Windows, Mac?)
* Java works for almost anyone with almost any working Java VM.
The native players work better than the java player, and that will
continue to be the case for the future. A lot of folks also don't like
Java. Even once the video tag is widely supported in Firefox and opera
browsers we'd still need to keep java support around.
The only way to handle the auto-switching between playback methods is
with JS on the client side... at least the only way that doesn't break
the ability to cache pages served to readers.
So with all that in mind, I think the best way to support playback
would be something like this:
We adjust [[Media:iewjqiek.ogg|largebutton|loop|This is my title]] so
that it produces a link directly to the file like usual, but the
anchor tagt smuggles in the metadata the player needs to work well.
<a href="http://upload.wikimedia.org/whatever/iewjqiej.ogg"
class="media media_type_video media_width_352 media_height_288
media_loop media_largebutton" title="This is my
title">Image:iewjqiek.ogg</a>
Then, javascript is provided to the client. Initially we could place
it in the site-customized monobook.js for easy development by
javascript mavens, but ultimately it would get migrated into the
skin's JS. (I can't see how to easily solve some issues like
localization via the standard localization interface without moving it
into the skin)
The javascript would, onload, scan the document for anchor tags with
class="media", extract the media URL and metadata, replace the link
with a 'play' icon which is hooked up to the machinery which handles
detecting a player and starting it when the user clicks.
Users without JS support end up seeing a nice friendly link directly
to the file... which they can hopefully use with some locally
installed player software. Playback on the image page would be
handled by having a media style anchor tag directly in the page.
Thoughts?
Is there any plans on how to extract the edits which are
reverts/anti-vandalism only out of the article history? so that when you
want to know the authors of a certain article...you just choose to get
all edits..
I was thinking of adding a tick box like that of the 'minor edit' that
people use (along with anti-vandal bots) when they are just
reverting...that box should mark these edits I presume...what do you think?
On 7/20/07, amidaniel(a)svn.wikimedia.org <amidaniel(a)svn.wikimedia.org> wrote:
> Revision: 24283
> Author: amidaniel
> Date: 2007-07-20 08:38:06 +0000 (Fri, 20 Jul 2007)
>
> Log Message:
> -----------
> Add really simple extension for restricting read/write access by namespace, an oft-requested
> utility. Works with 1.9.0+, possibly with older too.
Have you looked at the Lockdown extension?
http://www.mediawiki.org/wiki/Extension:Lockdown
Also, doesn't that transclusion hook break due to the parser cache?
We have $wgNonincludableNamespaces for this.
How can we redirect the MediaWiki 'create account' page to a different
self registration page?
At the SFPIRG (sfpirg.ca), we're installing several online tools
(MediaWiki, Drupal, Koha, etc.) Each web app is integrated with our LDAP
directory to maintain consistent accounts. We use the MediaWiki LDAP
extension: http://www.mediawiki.org/wiki/Extension:LDAP_Authentication
We don't want users to create separate accounts for MediaWiki, we want
the MediaWiki 'create account' link to point to our LDAP self
registration page. I can do this with mod_rewrite, matching
Special:Userlogin&type=signup, but wonder if there's a better way?
Thanks! Jack
> We have received a request from 171.65.76.136 for subscription of your
> email address...
And it isn' t my IP. Spammers registering me for the list, or some
automated purging of inactive subscribers?? Arin says the IP is from
Stanford...where I was last Fall (as well as many, many years ago as
an undergrad). Weird.
=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Python Wikipedia robot framework project is moving hosting from
SourceForge CVS to Wikimedia's SVN server. This is a second repository
alongside the MediaWiki repository but separate from it.
ViewVC on the repo:
http://svn.wikimedia.org/viewvc/pywikipedia/trunk/pywikipedia/
Anonymous checkout:
http://svn.wikimedia.org/viewvc/pywikipedia/trunk/pywikipedia/
Commit mails go to the new mailing list:
http://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
The following committers have been added:
Andre Engels (a_engels)
Jason Y. Lee (allyunion)
Bryan (btongminh)
Cyde Weys (cydeweys)
Gerrit Holl (gerrit)
Rob W.W. Hooft (hooft)
Leonardo Gregianin (leogregianin)
Misza13 (misza13)
Anton (quistnix)
Rik Wade (rikwade)
Russell Blau (russblau)
siebrand (siebrand)
Merlijn S. van Deen (valhallasw)
Warddr (warddr)
Daniel Herding (wikipedian)
Welcome all!
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGn84gwRnhpk1wk44RAjH8AKC03uEciLlNvpKuw3Qaa+XGumEDDgCgj013
5cCUFFj2xZqUHvBhU0WsQQw=
=PB7n
-----END PGP SIGNATURE-----
I'm building a math site based on MediaWiki and I want a "Solution" link
(connect to Solution: namespace) to be displayed between "Problem" and
"Talk" link for all the pages in main namespace. I tried diving into the
code but it doesn't make sense to me. Can anyone help me?
Minh Le.
Proposed for discussion:
We need to start thinking about IPv6 and blocking. Also, IPv6 and IP
users in general, but specifically blocking.
We will probably want to be able to extend block syntax to be able to
block any combination of Routing Goop (top 64), RG + subnet (64 + 16),
or MAC address (lower 48).
Being able to block on IPv6 MAC address allows us to conveniently
block a persistent vandals specific computer, even if they move it or
change ISPs. Unless they're bright enough to mangle the MAC
address...
--
-george william herbert
george.herbert(a)gmail.com
> The user also mentioned that there was no clear place to contact about this
> type of problem. He now knows to contact Wikitech-l, but we may wish to
> advertise that more. (But that is a separate discussion entirely.)
I thought the procedure was to report it to
http://meta.wikimedia.org/wiki/Live_mirrors
My goal is to display my own page in wikipedia using third party software.that
party will be designed by me as a developer.
In that software i users will enter a searched word,this word must be searched
in wikipedia website particularly in my own page.And display it.
Can i do this,if yes how to do it?