Wikitech-l March 2011

wikitech-l@lists.wikimedia.org

122 participants
96 discussions

universal login not always working
by William Allen Simpson 13 Mar '11

13 Mar '11

Recently, I've had a rare need to check interwiki links. I've discovered that many times, the universal login credentials are not working. For example, after login to english, the french link seems to accept the credentials (most of the time), while the german link *never* accepts the credentials. Moreover, there is still the problem with secure, in that following interwiki links doesn't stay with secure, so have to re-login for each site. (Also, secure is slower than ever, and edits sometimes log the IP instead of the user name.)

5 19

a procedure for setting up a prototype Wikimedia wiki
by Amir E. Aharoni 13 Mar '11

13 Mar '11

Is there some kind of a procedure for setting up a prototype Wikimedia wiki for testing? For example, which articles, templates and special pages should be copied there from the corresponding live wiki? In the Arabic prototype ( http://prototype.wikimedia.org/release-ar/ ) there are very few articles and all of them have Arabic titles. It makes it impossible to test Bug 26665. I created an article called ABCDE to test it, but to save time and ensure better testing in the first place, creating articles in various scripts and directionalities must be a part of the standard procedure for creating a prototype. And since i'm mentioning it, http://prototype.wikimedia.org/deployment-ar/ doesn't seem to work at all. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com "We're living in pieces, I want to live in peace." - T. Moore

2 1

MediaWiki Sanitizer and HTML5 Microdata
by Mingli Yuan 11 Mar '11

11 Mar '11

Hi, folks, I am trying to make a wiki template to render some meta data of an article. And I want to use HTML5 Microdata to make these metadate machine-readable. But the problem I found is that XHtml Sanitizer in MediaWiki remove all the attributes needed. The Microdata spec[1] add below global attribute for almost every html tag: * itemscope * itemtype * itemid * itemref * itemprop Sometimes a "meta" tag will be used to express an name-value pair which human can not see it. So, in general, if MediaWiki can use Microdata format, we should relax the Sanitizer for the global attributes and meta tag. For the global attributes, I think it is no harm, and quite easy to fix. But for the meta tag, I am not very sure, I don't know whether the search engine still use it or not. If the search engines do not care about it, why not relax the constraints on it? I know Microformat is compatible with the Sanitizer, but it use the "class" attribute so heavy. You know, class attibute may used for other purpose such as rendering. After comparing, I think microdata is more neat. Above is my personal proposal. Thanks for your consideration. Regards, Mingli [1] http://dev.w3.org/html5/md/

4 7

RFC: MediaWiki Style Guide (Forms)
by Brandon Harris 10 Mar '11

10 Mar '11

One of my goals for the year at the Foundation is "Development of a MediaWiki Style Guide." To that end, I have completed the first draft of one section, focused on Forms and Form elements. This project has multiple goals: * To create consistency across various interfaces * To help modernize the MediaWiki interface * To make the overall user experience more enjoyable * To make writing user interfaces easier for developers In a perfect world, MediaWiki would have a standardized User Interface library where a developer can simply say something like $myInput = UIElements::getTextInput( type => 'text' name => 'elementname', label => 'The Label', helptext => 'Help text string', hint => 'Default value', instructions => 'Instructions string', errorconditions => array(blah blah blah) ); And have that do the needful, knowing how to display itself and handle errors for itself. We don't live in a perfect world, but we can start to get there. Here is the first draft. Attack at leisure, and feel free to ignore my pathetic mewlings as you cut my soul from my bones. http://www.mediawiki.org/wiki/StyleGuide/Forms I'm going to expand this further (with things like "tables" and such) but for now this is a start. You can comment here or on the talk page.

6 5

Fwd: Reg. Research using Wikipedia
by David Gerard 10 Mar '11

10 Mar '11

---------- Forwarded message ---------- From: ramesh kumar <ramesh_chill(a)hotmail.com> Date: 9 March 2011 13:27 Subject: RE: Reg. Research using Wikipedia To: dgerard(a)gmail.com Dear Mr.Gerard, Thanks for your instant response. But is there a time-gap to check between one request into another request. for ex: like 1 sec, or 1 milli sec. If so, I can set a sleep state in my program. At the same, I have 3.1 million (3101144) wiki article titles. So if I set 1 sec between one request, so for 1 day it takes 60(sec)*60(min)*24(hr)=86400 /2= 43200 requests per day(considering 1 sec sleep between 1 request to the other) 3101144/43200=71 days. I feel the program takes 71 days to finish all the 3.1 million article titles. Is there anyway, our university IP address will be given permission or sending a official email from our department head to Wikipedia Server administrator to consider that the program, I run from this particular IP address is not any attack. so, our administrator allows us to do faster request like 0.5 sec. So, I can finish my experiment within 35 days. expecting your positive reply regards Ramesh --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Date: Wed, 9 Mar 2011 10:39:43 +0000 > Subject: Re: Reg. Research using Wikipedia > From: dgerard(a)gmail.com > To: ramesh_chill(a)hotmail.com > > I asked the wikitech-l list, which is where the system administrators > talk, and they said: > > "If they use the API and wait for one request to finish before they > start the next one (i.e. don't make parallel requests), that's pretty > much always fine." > > http://lists.wikimedia.org/pipermail/wikitech-l/2011-March/052137.html > > Hopefully this will put your network administrators' minds at rest :-) > > > - d. > > > > On 9 March 2011 09:47, ramesh kumar <ramesh_chill(a)hotmail.com> wrote: > > Dear Members, > > I am Ramesh, pursuing my PhD in Monash University, Malaysia. My Research is > > on blog classification using Wikipedia Categories. > > As for my experiment, I use 12 main categories of Wikipedia. > > I want to identify " which particular article belongs to which main 12 > > categories?". > > So I wrote a program to collect the subcategories of each article and > > classify based on 12 categories offline. > > I have downloaded already wiki-dump which consists of around 3 million > > article titles. > > My program takes this 3 million article titles and goes to > > online Wikipedia website and fetch the subcategories. > > Our university network administrators are worried that, Wikipedia would > > consider as DDOS attack and could block our IP address, if my program > > functions. > > In order to get permission from Wikipedia, I was searching allover. I could > > able to find wikien-l members can help me. > > Could you please suggest me, whom to contact, what is the procedure to get > > approval for our IP address to do the process or other suggestions > > Eagerly waiting for a positive reply > > Thanks and Regards > > Ramesh

4 3

Registration open for the Hackathon in Berlin, May 13-15
by Daniel Kinzler 10 Mar '11

10 Mar '11

Hi all! Wikimedia Germany invites anyone interested in improving MediaWiki to come and join us at or third developer meet-up. Like the last two years, it's going to be awesome! Unlike the last two years, there will be more hacking and less talking - it'll be a Hackathon, not a BarCamp. We'll meet on May 13 to 15, in Berlin, on the 4th floor of the betahaus coworking space <http://betahaus.de/>. There will not be an entrance fee, but registration is mandatory and now open: <http://de.amiando.com/hackathon2011>. Registration will close on April 10. If you like to attend, please register in time! More information can be found at <http://www.mediawiki.org/wiki/Berlin_Hackathon_2011>. The Berlin Hackathon 2011 is an opportunity for MediaWiki hackers to come together, squash bugs and write crazy new features. Our main focus this time around will probably be: * Improving usability / accessibility * Interactive Maps * Fixing the parser * WMF Ops (new data center, virtualization) * Supporting the Wiki Loves Monuments image hunt * Squashing bugs If you have different ideas, please let us know: <http://www.mediawiki.org/wiki/Berlin_Hackathon_2011#Topics> The Hackathon will be hosting the Language committee and Wiki loves Monuments group. There is a limited number of seats reserved for these groups and if you belong to one of them, you should receive an invitation code soon. If you have any doubts or questions, contact us at <hackathon(a)wikimedia.de>. We’re excited to see you in Berlin, your Hackathon Team Daniel Kinzler (Program Coordinator) Nicole Ebber (Logistics) Cornelius Kibelka (Assistant)

1 0

Parser: the recursiveTagParse equivalent for setTransparentTagHook is?
by Mick P. 10 Mar '11

10 Mar '11

Plese excuse me, I'm trying to implement a "transparent tag hook" which can include other nested transparent hooks. For regular setHook hooks, there is recursiveTagParse() ... but for setTransparentTagHook there does not seem to be an obvious equivalent. The functionality itself seems to be largely undocumented. It was recently suggested to me. recursiveTagParse does not look like a ton of code in and of itself... function recursiveTagParse( $text, $frame=false ) { wfProfileIn( __METHOD__ ); wfRunHooks( 'ParserBeforeStrip', array( &$this, &$text, &$this->mStripState ) ); wfRunHooks( 'ParserAfterStrip', array( &$this, &$text, &$this->mStripState ) ); $text = $this->internalParse( $text, false, $frame ); wfProfileOut( __METHOD__ ); return $text; } If necessary could something like this be improvised for the transparent hook stage? Thanks -- View this message in context: http://old.nabble.com/Parser%3A-the-recursiveTagParse-equivalent-for-setTra… Sent from the Wikipedia Developers mailing list archive at Nabble.com.

1 0

Fwd: Reg. Research using Wikipedia
by David Gerard 09 Mar '11

09 Mar '11

Is there a standard answer to this question - how much researchers are allowed to hammer the site? - d. ---------- Forwarded message ---------- From: ramesh kumar <ramesh_chill(a)hotmail.com> Date: 9 March 2011 09:47 Subject: Reg. Research using Wikipedia To: wikien-l(a)lists.wikimedia.org, wikien-l-owner(a)lists.wikimedia.org Dear Members, I am Ramesh, pursuing my PhD in Monash University, Malaysia. My Research is on blog classification using Wikipedia Categories. As for my experiment, I use 12 main categories of Wikipedia. I want to identify " which particular article belongs to which main 12 categories?". So I wrote a program to collect the subcategories of each article and classify based on 12 categories offline. I have downloaded already wiki-dump which consists of around 3 million article titles. My program takes this 3 million article titles and goes to online Wikipedia website and fetch the subcategories. Our university network administrators are worried that, Wikipedia would consider as DDOS attack and could block our IP address, if my program functions. In order to get permission from Wikipedia, I was searching allover. I could able to find wikien-l members can help me. Could you please suggest me, whom to contact, what is the procedure to get approval for our IP address to do the process or other suggestions Eagerly waiting for a positive reply Thanks and Regards Ramesh

6 6

openZim export now part of collections extension
by Tomasz Finc 09 Mar '11

09 Mar '11

Greetings All, Today we enabled openZim (http://openzim.org/Main_Page) export to the existing PediaPress collections extension on English Wikipedia and numerous others. In addition to PDF and ODF, you will now see a new export option when browsing the Download section of the Manage Book interface. You can then easily take these files and use them with the Kiwix offline reader (http://kiwix.org/index.php/Main_Page). We'd love to get some help testing to find bugs and receive feedback. Give the tool a go and let us know what you think! Bugs can be filed at https://bugzilla.wikimedia.org/ under Product: MediaWiki extensions Component: Collection You can also note your thoughts on http://www.mediawiki.org/wiki/Extension:Collections/openZim and we'll move them over to Bugzilla. For those following our offline developments this is the first part of our push into new tools mentioned at http://techblog.wikimedia.org/2011/01/update-on-offline-wikimedia-projects/ Come help us make the others a success. Thanks to both Heiko and Volker for their work in making this project successful. --tomasz

8 8

Site fixes this week
by Rob Lanphier 08 Mar '11

08 Mar '11

Reposting from techblog: http://techblog.wikimedia.org/2011/03/site-fixes/ ----- Site fixes this week We’re still in the middle of cleaning up some lingering issues from the 1.17 deployment, and despite our best efforts, you may see a little bit of quirkiness in the site: * One problem with the site since the deployment was a problem with our job queue, which meant that emails that were supposed to be sent from the site weren’t. This backlog was removed last night, and a lot of pent-up email was sent. * There were some HTML cache invalidations that caused parts of the site to get overloaded for a few minutes. * Yesterday, we started the deployment of the category sorting improvements. We deployed some modifications to the database today. This resulted in a few hiccups on the site that we’ve since mostly recovered from. Category collation One key set of improvements in the MediaWiki 1.17 release is the [1]category sorting work spearheaded by Aryeh Gregor. This code will eventually improve the sorting of categories in different languages, allowing us to choose the most appropriate sort order for the language. For now, we’re at least switching over to a more sensible sorting algorithm ([2]Unicode Collation Algorithm (UCA)), and have made other improvements to sorting. This set of changes required a modification of the database that we didn’t believe was risky, but was irreversible. Given [3]how complicated the initial 1.17 deployment was, we decided to hold back on deploying this work. There are still some maintenance scripts left to run before this work is fully-deployed, but most parts of this are done. Other fixes We’re also aware of and working on [4]other problems with the job queue. We’re investigating these problems and hope to have these fixed soon. 1. http://www.mediawiki.org/wiki/MediaWiki_1.17/Category_sorting 2. http://en.wikipedia.org/wiki/Unicode_collation_algorithm 3. http://techblog.wikimedia.org/2011/02/main-deployment-of-mediawiki-1-17-to-… 4. https://bugzilla.wikimedia.org/show_bug.cgi?id=27727

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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