Wikitech-l October 2011

wikitech-l@lists.wikimedia.org

117 participants
105 discussions

Fwd: API for Extension:ExpandTemplates?
by Dan Bolser 02 Oct '11

02 Oct '11

I think I sent this to the wrong address initially, here it is again (sorry if I'm just getting confused), Dan. ---------- Forwarded message ---------- From: Dan Bolser <dan.bolser(a)gmail.com> Date: 1 October 2011 10:37 Subject: API for Extension:ExpandTemplates? To: "mediawiki-l(a)lists.wikimedia.org" <mediawiki-l-bounces(a)lists.wikimedia.org> Hi, Can I get the XML parse tree from the MW API using Extension:ExpandTemplates? http://www.mediawiki.org/wiki/Extension:ExpandTemplates Would this ever be core functionality? In general, how should an extension extend the API, and could this be done for Extension:ExpandTemplates? I think it would be very useful for third party client applications to get programmatic access to the MW parse tree (for convenient high level page manipulation, such as trivially checking for a specific value of a specific field of a specific template and updating that template to add a new field, or counting the length of a list in a specific section, etc., etc.) I've been trying to implement such a tool in Perl, but of course, my template parser doesn't (yet) fully agree with the MW template parser, and the latter may change in future, requiring me to constantly maintain my Perl parser. Such an API extension would mean I could just get access to to what I need in Perl via the API. Here is a link to the stuff I've done in Perl in case anyone is interested (constantly changing these days): https://github.com/dbolser/MediaWiki--/tree/master/local-lib/lib/perl5/Medi… (Note, API.pm isn't my work, and I'll remove it from that location soon). Cheers, Dan.

2 1

Blender's new MedaiWiki skin - Naiad
by Erik Moeller 02 Oct '11

02 Oct '11

In case you haven't seen it, there are some interesting ideas in the new skin developed by the Blender community for its wiki: http://wiki.blender.org/index.php/Meta:Skins/Naiad It was clearly designed especially to support structured documentation: http://wiki.blender.org/index.php/Doc:2.5/Manual Among the more interesting ideas employed here are automatic changes to the layout to make the best use of the available screen resolution. Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

2 1

Thanks for supporting WLM 2011!
by Strainu 01 Oct '11

01 Oct '11

Hey guys, I just wanna say a _big_ thank you to all the people that were involved in the design and maintaince of the upload system on Commons! Over 140k of pictures in a month on top of the regular traffic is something. And if we got around to this, can you tell us when were the most pictures uploaded per minute/hour/day? Do you guys have such statistics? Thanks A LOT, Strainu

3 2

serious interwiki.py issues on MW 1.18 wikis
by Merlijn van Deen 01 Oct '11

01 Oct '11

Hello to both the wikitech and pywikipedia lists -- please keep both informed when replying. Thanks. A few days ago, we - the pywikipedia developers - received alarming reports of interwiki bots removing content from pages. This does not seem to happen often, and we have not been able to reproduce the conditions in which this happens. However, the common denominator is the fact it seems to be happening only on the wikipedia's that run MediaWiki 1.18 wikis. As such, I think this topic might be relevant for wikitech-l, too. In addition, there is no-one in the pywikipedia team with a clear idea of why this is happening. As such, we would appreciate any ideas. 1. What happens? Essentially, the interwiki bot does its job, retrieves the graph and determines the correct interwiki links. It should then add it to the page, but instead, /only/ the interwiki links are stored. For example: http://nl.wikipedia.org/w/index.php?title=Blankenbach&diff=next&oldid=10676… http://eo.wikipedia.org/w/index.php?title=Anton%C3%ADn_Kl%C3%A1%C5%A1tersk%… http://simple.wikipedia.org/w/index.php?title=Mettau%2C_Switzerland&action=… 2. Why does this happen? This is unclear. On the one hand, interwiki.py is somewhat black magic: none of the current developers intimately knows its workings. On the other hand, the bug is not reproducible: running it on the exact same page with the exact same page text does not result in a cleared page. It could very well be something like broken network error handling - but mainly, we have no idea. Did anything change in Special:Export (which is still used in interwiki.py) or the API which might cause something like this? I couldn't find anything in the release notes. 3. Reasons for relating it to MW 1.18 To find out on which wikis this problem happens, I used a quick-and-dirty heuristic: select rc_comment, rc_cur_time, rc_user, rc_namespace, rc_title, rc_old_len, rc_new_len from recentchanges left join user_groups on ug_user=rc_user where rc_new_len < rc_old_len * 0.1 and ug_group = 'bot' and rc_namespace=0 limit 10 /* SLOW OK */; This is a slow query (~30s for nlwiki_p on the toolserver), but it gives some interesting results: nlwiki: 9 rows, all broken interwiki bots eowiki: 25 rows, all interwiki bots simplewiki: 3 rows, of which 2 are interwiki bots dewiki: 0 rows using rc_old_len * 0.3: 14 rows, all double redirect fixes frwiki: 9 rows, but *none* from interwiki bots (all edits are by the same antivandalism bot) itwiki: 0 rows ptwiki: 0 rows All ideas and hints are very welcome. Hopefully we will be able to solve this before tuesday... Best regards, Merlijn van Deen

8 12

Re: [Wikitech-l] [openZIM dev-l] Phonegap and Wikimedia mobile apps
by Tomasz Finc 01 Oct '11

01 Oct '11

Awesome work Christian. Where can we find your code to test out? If you don't have a place then I'll carve one out in our depots. On Sep 24, 2011 5:57 AM, "Christian Pühringer" <christian(a)puehringer.net> wrote: > Hi Emanuel, > > Makes sense that images are not compressed in zim file again, thanks for the > clarification. > In particular for windows mobile this increases the probability that with > reducing the cluster size > a sufficient performance is achieved (i.p. if there was a better way to display > images than in android, but I haven't looked into this). > For android I still expect that it it will be better to use a native library. > > Christian > Am 24.09.2011 14:30, schrieb Emmanuel Engelhart: >> On 24/09/2011 14:24, Christian Pühringer wrote: >>> The JAVA liblzma performance is pretty bad: To increase efficiency of >>> compression in the zim-format articles (and also all >>> other data like images) are stored in clusters. Cluster size is apparently about >>> 1 MB. This implies that loading an article >>> which is stored at the end of a cluster involves decompressing the complete >>> cluster. >> Images should not be compressed in ZIM files for the obvious reasons >> they mainly are already compressed. This is the case for all ZIM files I >> made. As far as I know this is also the case for Mediawiki:Collection >> build ZIM files. >> >> Emmanuel >> > > _______________________________________________ > dev-l mailing list > dev-l(a)openzim.org > https://intern.openzim.org/mailman/listinfo/dev-l

3 5

2025

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 October 2011