I've been considering using it, so I'd be interested too.
On 04/24/2012 11:52 AM, wikitech-l-request(a)lists.wikimedia.org wrote:
> From: Chris Steipp<csteipp(a)wikimedia.org>
> Subject: [Wikitech-l] HTMLPurifier
>
> Hello Everyone,
>
> Does anyone know if mediawiki has ever used HTMLPurifier (
> http://htmlpurifier.org/) as a library? Or if any extensions have used it?
>
> I'm looking at adding in a library for svg cleaning that depends on it, but
> not sure if that's something that can be added in, or if I
> should re-implement those features.
>
> Thanks,
>
> Chris
https://blog.wikimedia.org/2012/04/23/wmf-selects-9-students-for-gsoc/
Ankur Anand, integrating Flickr upload and geolocation into
UploadWizard. Mentor: WMF engineer Ryan Kaldari
Harry Burt, TranslateSvg ("Bringing the translation revolution to
Wikimedia Commons"). Mentor: WMF engineer Max Semenik
Akshay Chugh, making a convention/conference extension for
MediaWiki. Mentor: volunteer developer Jure Kajzer
Ashish Dubey, realtime collaboration in the upcoming visual editor.
Mentor: WMF engineer Trevor Parscal
Suhas HS, improvements to the OpenStackManager extension. Mentor:
WMF engineer Ryan Lane
Nischay Nahata, optimizing the performance of the Semantic MediaWiki
extension. Mentor: volunteer developer Markus Krötzsch
Aaron Pramana, watchlist grouping and workflow improvements. Mentor:
volunteer developer Alex Emsenhuber
Robin Pepermans, working on Incubator improvements and language
support, Mentor: WMF engineer Niklas Laxström
Platonides, a desktop application for mass-uploading files to
Wikimedia Commons. Mentor: me (as project manager and mentor of record;
Platonides will consult with technical experts)
Congratulations. You are the most promising students among the 63 who
applied, so we chose you to participate in our Google Summer of Code
program. Please consult your mentor to discuss what you ought to do
during the community bonding period (now till May 21).
Students whom we did not accept: please don't despair. As you can see,
you had a lot of very strong competition, and we only had nine slots.
We encourage you to keep learning about open source, use our IRC
channels and mailing lists, and even work on your projects as
volunteers! Most of us got into this hobby without GSoC, and you can
too. :-)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
I am wondering about releasing many hundreds of Africa educational videos
under creative commons.
They are the videos currently at www.our-africa.org which is a child
generated reference site about Africa.
There is a lot of material in the videos which could be edited and used to
improve Wikipedia article (a solar kettle in operation, a maize plant
grinding maize, a variety of musical instruments in use, different
religious festivals, cocoa plantations etc etc)
However at present Wikipedia does not seem to support or want video
material.
Does anyone have a feel whether this is likely to change?
Andrew
Hey all,
There have recently been a high number of complaints to OTRS about emails
recieved, supposedly from Wikipedia. I believe these to be spam, but I just
wanted to double check on the very small chance it is something gone wrong
somewhere :) The emails relate to account details and appears to be phising
(I think).
Here's an example:
Wikipedia
Someone (probably you, from IP address <IP REMOVED>) requested a reminder
of your
account details for Wikipedia. The following user account is associated
with this e-mail
address: <Address Removed>
This reminder will expire in 7 days.
If you didn't initiate the request on Wikipedia, feel free to cancel this
message and
uncheck the "Reminder" checkbox in your account.
Thanks, and once again Welcome!
Can someone just confirm this isn't a problem our end.
Cheers,
Tom
Hello,
Some people have reported that since the new version of git-review the
had issue submitting patches. The symptom is:
<someone hack>
<attempt to send the work by using `git-review`>
Complaint:
You have more than one commit that you are about to submit.
The oustanding commits are:
<some changes you never did :-]>
The issue is because your last commit has been done based on a remote
named 'origin' whereas git-review use the remote named 'gerrit'. Since
most people update only the origin remote with git pull, the gerrit
remote is lagging behind. So technically, git-review attempt to submit
any commit between origin/master and gerrit/master hence the long message.
There are three ways to fix it:
1) always update all remotes by using either:
- git fetch --all
- git remote update
Side effect: you have to remember to use those commands instead of 'git
fetch' or 'git pull origin'.
2) delete the remote named 'origin':
- git remote rm origin
Side effect: 'git pull origin' does not work anymore :-) You need to
use 'git pull gerrit'.
3) Tell .gitreview to use 'origin' by adding the following line:
defaultremote=origin
Make sure you have a remote named origin, if not rename the one named
gerrit :D
Side effect: I can not think of any.
I use (2) aka a remote named 'gerrit'.
I recommend (3) make git-review use 'origin' and I think we should
modify our .gitreview file to add that line. That will avoid confusion.
cheers,
--
Antoine "hashar" Musso
Hello,
This morning the CIA-89 IRC bot started sending notifications in
#mediawiki about unrelated projects mandriva and KDE.
I have not been able to find any documentation about this bot or any
generic login / password to alter it. So I have just banned it :-D
Ban has been made against: *!*(a)cia.atheme.org.
According to folks on #cia, one hs to login on http://cia.vc/ and remove
KDE and mandriva from announcing list.
cheers,
--
Antoine "hashar" Musso
Hi all!
The wikidata team has been discussing how to best make data from wikidata
available on local wikis. Fetching the data via HTTP whenever a page is
re-rendered doesn't seem prudent, so we (mainly Jeroen) came up with a
push-based architecture.
The proposal is at
<http://meta.wikimedia.org/wiki/Wikidata/Notes/Caching_investigation#Proposa…>,
I have copied it below too.
Please have a lot and let us know if you think this is viable, and which of the
two variants you deem better!
Thanks,
-- daniel
PS: Please keep the discussion on wikitech-l, so we have it all in one place.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
== Proposal: HTTP push to local db storage ==
* Every time an item on Wikidata is changed, an HTTP push is issued to all
subscribing clients (wikis)
** initially, "subscriptions" are just entries in an array in the configuration.
** Pushes can be done via the job queue.
** pushing is done via the mediawiki API, but other protocols such as PubSub
Hubbub / AtomPub can easily be added to support 3rd parties.
** pushes need to be authenticated, so we don't get malicious crap. Pushes
should be done using a special user with a special user right.
** the push may contain either the full set of information for the item, or just
a delta (diff) + hash for integrity check (in case an update was missed).
* When the client receives a push, it does two things:
*# write the fresh data into a local database table (the local wikidata cache)
*# invalidate the (parser) cache for all pages that use the respective item (for
now we can assume that we know this from the language links)
*#* if we only update language links, the page doesn't even need to be
re-parsed: we just update the languagelinks in the cached ParserOutput object.
* when a page is rendered, interlanguage links and other info is taken from the
local wikidata cache. No queries are made to wikidata during parsing/rendering.
* In case an update is missed, we need a mechanism to allow requesting a full
purge and re-fetch of all data from on the client side and not just wait until
the next push which might very well take a very long time to happen.
** There needs to be a manual option for when someone detects this. maybe
action=purge can be made to do this. Simple cache-invalidation however shouldn't
pull info from wikidata.
**A time-to-live could be added to the local copy of the data so that it's
updated by doing a pull periodically so the data does not stay stale
indefinitely after a failed push.
=== Variation: shared database tables ===
Instead of having a local wikidata cache on each wiki (which may grow big - a
first guesstimate of Jeroen and Reedy is up to 1TB total, for all wikis), all
client wikis could access the same central database table(s) managed by the
wikidata wiki.
* this is similar to the way the globalusage extension tracks the usage of
commons images
* whenever a page is re-rendered, the local wiki would query the table in the
wikidata db. This means a cross-cluster db query whenever a page is rendered,
instead a local query.
* the HTTP push mechanism described above would still be needed to purge the
parser cache when needed. But the push requests would not need to contain the
updated data, they may just be requests to purge the cache.
* the ability for full HTTP pushes (using the mediawiki API or some other
interface) would still be desirable for 3rd party integration.
* This approach greatly lowers the amount of space used in the database
* it doesn't change the number of http requests made
** it does however reduce the amount of data transferred via http (but not by
much, at least not compared to pushing diffs)
* it doesn't change the number of database requests, but it introduces
cross-cluster requests
Magnus Manske wrote:
> In continuation of the recent discussion, might this work for showing
> SVGs directly in browsers that can do so, etc.?
>
> Magnus
>
I would argue that SVGs are a poor use case here (a better one being
high-density JPGs such as those used by Retina displays).
Specifically, there are two main reasons in favour of serving PNGs over
SVGs:
* Uniformity. Instead of having to optimise against many different
browsers' implementations of SVG specifications, SVG users only have to
optimise against one (rsvg).
* SVG capability. Some browsers won't badly render SVG images, they'll just
refuse to show them at all (this is a receding factor bbut obviousl one of
historical importance).
Bandwidth considerations come in a poor third (especially considering some
PNGs are larger than their SVG equivalents).
That said, it's interesting stuff, if incredibly bleeding-edge at the
moment.
Regards,
Harry (User:Jarry1250)
Antoine "hashar" Musso wrote:
> Are we reinventing the wheel once again or is that a project
> to select and integrate an existing tool?
I'm open to using something existing: did you have something
specific in mind? I didn't see anything out there that would
be less trouble to customize than rolling our own.
--
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8