Wikitech-l April 2012

wikitech-l@lists.wikimedia.org

152 participants
188 discussions

Re: [Wikitech-l] HTMLPurifier
by Lee Worden 24 Apr '12

24 Apr '12

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

1 0

GSoC announcement of students for 2012
by Sumana Harihareswara 24 Apr '12

24 Apr '12

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

4 4

Release of educational videos under creative commons
by Andrew Cates 24 Apr '12

24 Apr '12

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

3 2

Wikimedia Spam
by Thomas Morton 23 Apr '12

23 Apr '12

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

5 9

git-review wanting to submit lot of changes
by Antoine Musso 23 Apr '12

23 Apr '12

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

9 9

CIA IRC bot kicked out
by Antoine Musso 23 Apr '12

23 Apr '12

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

5 10

Request for Comments: Cross site data access for Wikidata
by Daniel Kinzler 23 Apr '12

23 Apr '12

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

7 13

Re: [Wikitech-l] Multiple image versions with fallback
by Harry Burt 23 Apr '12

23 Apr '12

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)

1 0

Re: [Wikitech-l] Abstract schema work
by Greg Sabino Mullane 23 Apr '12

23 Apr '12

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

2 1

Multiple image versions with fallback
by Magnus Manske 23 Apr '12

23 Apr '12

Found this nice hack to show normal and high-res images on mobile depending on bandwidth: http://arstechnica.com/business/news/2012/04/javascript-package-offers-a-sm… In continuation of the recent discussion, might this work for showing SVGs directly in browsers that can do so, etc.? Magnus

1 0

← Newer
1
2
3
4
5
6
7
8
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l April 2012