Wikitech-l September 2009

wikitech-l@lists.wikimedia.org

94 participants
76 discussions

Working towards branching MediaWiki 1.16
by Siebrand Mazeland 01 Oct '09

01 Oct '09

Hola, I just created https://bugzilla.wikimedia.org/show_bug.cgi?id=20768 ("Branch 1.16") and Brion was quick to respond that some issues with js2 and the new-upload stuff need to be ironed out; valid concerns, of course. I proposed to make bug 20768 a tracking bug, so that it can be made visible what issues are to/could be considered blocking something we can make a 1.16 out of. Let the dependency tagging begin. Users of MediaWiki trunk are encouraged to report each and every issue, so that what is known can also be resolved (eventually). I'm calling on all volunteer coders to keep an eye on this issue and to help out fixing issues that are mentioned here. Cheers! Siebrand

15 45

Off-topic: Anyone have a Google Wave invite?
by Thomas Dalton 01 Oct '09

01 Oct '09

I apologise for the slightly off-topic email, but does anyone have any Google Wave invites to hand out? If so, I would be very interested in getting one...

1 0

Historical text highlighting wiki gadget
by Aaron L Halfaker 01 Oct '09

01 Oct '09

I'm sure many of you caught the news article(http://www.wired.com/wiredscience/2009/08/wikitrust/) about Adler and Alfaro's research(http://doi.acm.org/10.1145/1242572.1242608) in wiki trustability being applied to live Wikipedia. It just so happens that I have been working on a similar problem from a completely different direction during my research and I'm ready to share this work with the community. I have designed and implemented a user script modification that I call HAPPI and I'm currently running a non-profit/academic analysis of its usefulness. The script adds a couple of new controls that will appear over the edit pane. These controls will allow you to toggle the highlighting of wiki text while you edit it. If you'd like to give it a try, please see the documentation page and consent form for more information. Screenshot: http://upload.wikimedia.org/wikipedia/en/3/37/HAPPI_example.png <http://upload.wikimedia.org/wikipedia/en/3/37/HAPPI_example.png> Documentation: http://en.wikipedia.org/wiki/User:EpochFail/HAPPI Consent form: http://wikipedia.grouplens.org/HAPPI/consent -Aaron Halfaker Grouplens Research University of Minnesota

1 0

mediawiki automation for more then 2000 users with herarchical structure
by Stefano Ronzoni 30 Sep '09

30 Sep '09

Hi. I'm considering mediawiki for a large scale application (more then 2000 users). Main points of the application are: 1) there must be a herarchical users structure such as: GOD > ANGEL1 > REVEREND1 GOD > ANGEL1 > REVEREND2 GOD > ANGEL2 > REVEREND3 REVERENDS can see and edit ONLY their personal contents. ANGELS can see and edit ONLY their personal contents plus the contents of their subordinates (for exemple: ANGEL1 can manage the contents of REVEREND1 and REVEREND2). 2) The structure of the point 1 changes very often. Also users data change very often too. I cannot manage them manually from mediawiki webpages: it costs too much time in costant manteinance. A server process must be developed to daily import and update users data and permissions in background from an excel, a csv or a webservice. Some exemples of changes are: - a new REVEREND such as REVEREND4 appears under ANGEL2 - REVEREND2 boss change from ANGEL1 to ANGEL2 - ANGEL2 disappear - REVEREND2 diasappear - REVEREND3 became ANGEL4 - all the herarchical structure totally change Only created and authorized users form the server process import can login to the applcation. A user cannot register himeself because otherwise it isn't possible to place him in the herarchical structure by default and to check if he has got the correct system login nickname. 3) For point 1 and 2 I checked PermissionsACL extension but it seems this one requires a lot of administrator manual mantainance. For exemple, have I got to create a namespace for every one of my 2000 users? Have I got to update every time LocalSetttings.php? Have I got to create a group for every user? Have I got to write into Localsettings.php all the things a single user can see on mediawiki because PermissionACL protects all? Is there a solution to automate all of this from the server process of the point 2? Considering SQL Injection etc. etc, can PermissionsACL guarantee me a proteceted application where a user can see only his own data in the structure of the point 1. 4) In the structure of the point 1 is possible to redirect a REVEREND user directly to his personal contents after the login? 5) And if I got to import, from excel csv or webservice, some user contents to manage the fact in this way he is not forced to retype it? 6) I've got a development machine and an application machine. When I create on the development machine a release n.2, n.3 etc. etc. of my application: how can I migrate it to the application server considering the fact, on the application server, there are real data and on the development machine data are obviously fake? Have I got to do it manually? 7) is there a way to backup only data or have I got to backup all my easyphp folder to be sure I can restore the application? What have I got to backup to be sure I can restore my mediawiki application? 8) considering more the 2000 users, passwords cannot be changed manually if a user forget it. Too much manteinance. Is it possible to use Windows Authentication? Or is there a way to enable the structure of the point 1 to manage subordiante users passwords (for exemple ANGEL1 can reset the password of the REVEREND1) ? 9) if I've got to export data daily in background not manually (such as REVERENDS contents) to some other system: is it possible to do it considering data into mediawiki database are in mediawiki syntax? 10) considering more then 1500 REVERENDS: they can write their personal stuff in different ways. Is there a way to fix it in a common way so mediawiki can manage links? 11) the idea is to develope the product in my language. It is not eneglish because not all the users actually know english. Apart user imputed data, will be possibile to update my mediawiki application in english one day or to manage it multilanguage? Have I got to re-implement my application from the beginning? Mediawiki is a good product but in my opinion is not the solution for my needs because they are out of mediawiki contents and for what I can see using mediawiki it costs me a lot in regular daily mantainance. Please be honest, is mediawiki the right solution for me? Is there a solution for my points using mediawiki? Or is it better if I look for some other solution more customizable for what I have got to do and less expensive in manteinace and development? ------------------------------------------------------------ Scale Track your weight loss! Click now for precision scales. http://tagline.excite.com/fc/FgElN1gvzpW29HK9NI6Gn6raKyb1pXuFRHGzsFNNmNRc8P…

3 2

empty pages list
by Amir E. Aharoni 30 Sep '09

30 Sep '09

Hello, Is there a special page that lists pages which are completely blank? I was looking for it and couldn't find it. In user space it is usually not important, but in Category, Image or Main space it is definitely important - Categories should have a parent, Images should have a license and a category, and articles should have content. There's "Short pages", but no "Blank pages". Was it ever considered? Is there, maybe, some bot that creates such a list? I accidentally found quite a lot of pages of this kind while analyzing a dump for a different reason and wondered about it. -- Amir Elisha Aharoni http://aharoni.wordpress.com "We're living in pieces, I want to live in peace." - T. Moore

2 2

Announce: Brion moving to StatusNet
by Brion Vibber 29 Sep '09

29 Sep '09

I'd like to share some exciting news with you all... After four awesome years working for the Wikimedia Foundation full-time, next month I'm going to be starting a new position at StatusNet, leading development on the open-source microblogging system which powers identi.ca and other sites. I've been contributing to StatusNet (formerly Laconica) as a user, bug reporter, and patch submitter since 2008, and I'm really excited at the opportunity to get more involved in the project at this key time as we gear up for a 1.0 release, hosted services, and support offerings. StatusNet was born in the same free-culture and free-software community that brought me to Wikipedia; many of you probably already know founder Evan Prodromou from his longtime work in the wiki community, launching the awesome Wikitravel and helping out with MediaWiki development on various fronts. The "big idea" driving StatusNet is rebalancing power in the modern social web -- pushing data portability and open protocols to protect your autonomy from siloed proprietary services... People need the ability to control their own presence on the web instead of hoping Facebook or Twitter always treat you the way you want. This does unfortunately mean that I'll have less time for MediaWiki as I'll be leaving my position as Wikimedia CTO sooner than originally anticipated, but that doesn't mean I'm leaving the Wikimedia community or MediaWiki development! Just as I was in the MediaWiki development community before Wikimedia hired me, you'll all see me in the same IRC channels and on the same mailing lists... I know this is also a busy time with our fundraiser coming up and lots of cool ongoing developments, so to help ease the transition I've worked out a commitment to come into the WMF office one day a week through the end of December to make sure all our tech staff has a chance to pick my brain as we smooth out the code review processes and make sure things are as well documented as I like to think they are. ;) We've got a great tech team here at Wikimedia, and we've done so much with so little over the last few years. A lot of really good work is going on now, modernizing both our infrastructure and our user interface... I have every confidence that Wikipedia and friends will continue to thrive! I'll start full-time at StatusNet on October 12. My key priorities until then are getting some of our key software rollouts going, supporting the Usability Initiative's next scheduled update and getting a useful but minimally-disruptive Flagged Revisions configuration going on English Wikipedia. I'm also hoping to make further improvements to our code review process, based on my experience with our recent big updates as well as the git-based workflow we're using at StatusNet -- I've got a lot of great ideas for improving the CodeReview extension... Erik Moeller will be the primary point of contact for WMF tech management issues starting October 12, until the new CTO is hired. I'll support the hiring process as much as I can, and we're hoping to have a candidate in the door by the end of the year. -- brion vibber (brion @ wikimedia.org) CTO, Wikimedia Foundation San Francisco

5 5

Template editing
by Magnus Manske 29 Sep '09

29 Sep '09

IMHO the question, in this case, is not "how to build the perfect wikitext grammar/parser", but how to ease editing of wikitext through editor enhancements. For that, it seems sufficient to cover the vast majority of cases instead of writing a perfect solution, as long as it falls back to "ugly" wikitext when in doubt. Having 1% of templates appear in all their ugliness is better than 100%. To that end, I have just written some proof-of-concept JavaScript: http://en.wikipedia.org/wiki/User:Magnus_Manske/tmpl.js It is not a solution, but shows a possible approach (example text to use: [[Picopict]]): * On edit start, it finds all templates in wikitext * It does so only in namespace 0, so no template variables need to be considered (otherwise, move the damned text out of article namespace! ;-) * It will not touch templates that have no parameter - {{reflist}} is easy enough * It will replace all other templates with strings like ##TEMPLATEnumber:name##, e.g., ##TEMPLATE1:Infobox VG## * These will be replaced with the original text again on save/preview/diff * Double-clicking on, say, TEMPLATE1 will select that entire word. If it is a template placeholder, an action is performed. For this demo, it only shows the original text of the template (note that nested templates are left as wikitext). Obviously, this can be expanded to call up an editor of some kind. I don't want to write one now that JQuery is around the corner :-) And yes, I am introducing new syntax. That's not the point here; could just as well be some other, pretty placeholder in a wysiwyg editor. As to the issue of getting possible template variable names: Why not * load the wikitext of the template in the background * remove all nowiki, noinclude, etc * get everything that looks like "{{{NAME|" or "{{{NAME}}}" * remove known magic words * Profit! Cheers, Magnus

4 4

Software updates Wednesday morning
by brion＠wikimedia.org 28 Sep '09

28 Sep '09

I've been spending much of the last few work days tidying up an update to our deployed codebase, which has been several weeks behind development for most components. I'll want to start deploying this in the morning (Pacific time), so we'll have most of the day to poke around and fix up any problems on the sites... it's gonna be fun! This'll primarily bring a lot of under-the-hood improvements, which'll let us start rolling out other fun things over the coming days/weeks including: * Daily updates of interface translations (LocalisationUpdate) * Updated PDF collection/book UI * major cleanup of maintenance scripts * foundation work for improved uploading support * foundation work for new UI stuff (JS2 / add media wizard / cool stuff from Usability team) For those of you poking at the code, I've got the pre-deployment code currently sitting in the wmf-deployment-work branch; this'll get folded back over wmf-deployment when we're ready to go. I believe all custom hacks from the current wmf-deployment branch have been either copied over or generalized and merged via trunk... Note I've held back updates on ProofreadPage and OggHandler for the moment, and we won't deploy the new JS2 code yet until we've shaken things down some more. If there are any *critical* trunk fixes from the last few days (since r55160 trunk branch point) that need to be forward-ported before we start, or any other surprises, let's make sure we know about it soon. :) -- brion

5 13

"js2" coding style for html output
by Michael Dale 28 Sep '09

28 Sep '09

My attachment did not make it into the JS2 design thread... and that thread is in summary mode so here is a new post around the html output question. Which of the following constructions are easier to read and understand. Is there some tab delimitation format we should use to make the jquery builder format easier? Are performance considerations relevant? (email is probably a bad context for comparison since tabs will get messy and there is no syntax highlighting) Tim suggested that in security review context "dojBuild" type html output is more strait forward to review. I think both are useful and I like jquery style building of html since it gives you direct syntax errors rather than html parse errors which are not as predictable across browsers. But sometimes performance wise or from a quick "get it working" perspective its easier to write out an html string. Also I think tabbed html is a bit easier on the eyes for someone that has dealt a lot with html. Something thats not fun about jquery style is there are many ways to build that same html string using .wrap or any of other dozen jquery html manipulation functions ... so the same html could be structured very differently in the code. Furthermore jquery chain can get pretty long or be made up of lots of other vars, potentially making it tricky to rearrange things or identify what html is coming from where. But perhaps that could be addressed by having jquery html construction conventions (or a wrapper that mirrored our php side html construction conventions? ) In general I have used the html output style but did not really think about it a-priori and I am open to transitioning to more jquery style output. here is the html: you can copy and paste this in... on my system Firefox nightly str builder hovers around 20ms while jquery builder hovers around 150ms (hard to say what would be a good target number of dom actions or what is a fair test...) ...jquery could for example output to a variable instead of direct to dom output shaving 10ms or so and many other tweaks are possible. <html> <head> <title>Jquery vs str buider</title> <script type="text/javascript" src="http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js"></script> <script type="text/javascript"> var repetCount = 200; function runTest( mode ){ $('#cat').html(''); var t0 = new Date().getTime(); if( mode =='str'){ doStrBuild(); }else{ dojBuild(); } $('#rtime').html( (new Date().getTime() - t0) + 'ms'); } function doStrBuild(){ var o = ''; for(var i =0 ;i < repetCount;i++){ o+=''+ '<span id="' + escape(i) + '" class="fish">' + '<p class="dog" rel="foo" >' + escape(i) + '</p>' + '</span>'; } $('#cat').append(o); } function dojBuild(){ for(var i =0 ;i < repetCount;i++){ $('<span/>') .attr({ 'id' : i, 'class' :'fish' }) .append( $('<p/>') .attr({ 'class' :'dog', 'rel' : 'foo' }) .text( i ) ).appendTo('#cat'); } } </script> </head> <body> <h3>Jquery vs dom insert</h3> Run Time:<span id="rtime"></span></div><br> <a onClick="javascript:runTest('str');" href="#">Run Str</a><br> <a onClick="javascript:runTest('dom');" href="#">Run Jquery</a><br> <br> <div id="cat"></div> </body> </html> --michael

3 3

Bugzilla Weekly Report
by reporter＠isidore.wikimedia.org 28 Sep '09

28 Sep '09

MediaWiki Bugzilla Report for September 21, 2009 - September 28, 2009 Status changes this week Bugs NEW : 113 Bugs ASSIGNED : 12 Bugs REOPENED : 21 Bugs RESOLVED : 124 Total bugs still open: 3875 Resolutions for the week: Bugs marked FIXED : 72 Bugs marked REMIND : 0 Bugs marked INVALID : 13 Bugs marked DUPLICATE : 27 Bugs marked WONTFIX : 14 Bugs marked WORKSFORME : 7 Bugs marked LATER : 5 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 6 General/Unknown 3 Page rendering 3 DumpHTML 2 FCKeditor 2 New Bugs Per Product MediaWiki 20 Wikimedia 10 MediaWiki extensions 12 mwEmbed 2 MediaWiki Feature Request 1 Top 5 Bug Resolvers rhalsell [AT] wikimedia.org 21 alex.emsenhuber [AT] bluewin.ch 19 roan.kattouw [AT] gmail.com 19 brion [AT] wikimedia.org 17 innocentkiller [AT] gmail.com 8

1 0

2026

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 September 2009