Wikitech-l November 2011

wikitech-l@lists.wikimedia.org

127 participants
144 discussions

A program to simultaneously upload images to two websites (Wikimedia Commons being one)
by James Heilman 30 Nov '11

30 Nov '11

I have been in discussion with two institutions (the University of British Columbia and a military hospital in the USA) who are interested in collaborating with Wikipedia. One of the proposed ideas is to create a program that would simultaneously upload images deemed suitable to both Wikimedia Commons and the other Wiki in question. Are there any programmers interested in taking on this project? -- James Heilman MD, CCFP-EM, Wikipedian

4 3

New committer
by Sumana Harihareswara 30 Nov '11

30 Nov '11

Gunther Zehetner (commitname guz, mediawiki.org User:optimale) now has extensions access. "I created the SemanticQueryFormTool extension (http://www.mediawiki.org/w/index.php/Extension:SemanticQueryFormTool) and would like to make the new MW 1.17 and SMW 1.6 compatible version (which will be rewritten and renamed to SemanticPropertyTools) available via svn.wikimedia.org." Welcome! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 0

Fwd: Open / Wiki Data Hack Day
by aude 30 Nov '11

30 Nov '11

On Saturday, we are co-organizing a hackathon at the Martin Luther King Jr Library in Washington DC, pertaining to open data and anything wiki-data related. I have a bunch of ideas, like maybe finding a way to update US census data to 2010 data. We welcome additional project ideas. If you are in the greater DC region or otherwise can come, we welcome you to join us. Folks from the Sunlight Foundation, Code for America, DC OCTO (DC gov) and other cool hackers will be there and I hope you will too! http://opendatahackdc.eventbrite.com/ Cheers, Katie Begin forwarded message: > From: Aude <aude.wiki(a)gmail.com> > Date: November 30, 2011 8:18:10 AM EST > To: wikimedia-dc(a)lists.wikimedia.org > Subject: International Open Data Hack Day > > On Saturday, Dec 3 at the MLK Jr Library, there will be a hackathon > with focus on open data, including anything related to wiki data. > > http://opendatahackdc.eventbrite.com/ > > Some wiki-related ideas could include: > > * working on a way to get the 2000 census data, in so many articles, > updated > * making use of data sources like data.worldbank.org or from the > federal government (e.g. BLS) to make maps, populate infoboxes, etc. > * working with the National Register of Historic Places data, > possibly in preparation for doing more Wikis Take DC / Baltimore > events or Wiki Loves Monuments here > * working with the Smithsonian Art Inventories data - http://siris-artinventories.si.edu/ > for WikiProject Public Art > * importing DC GIS data (more buildings) into OpenStreetMap -- no > technical skills required > * do you have any additional suggestions? > > Not all projects need to be wiki-related or uber-technical, though > we also need skilled hackers and designers on Saturday. > > Cheers, > Katie

1 0

Torrus down?
by Jay Ashworth 30 Nov '11

30 Nov '11

torrus.wikimedia.org/torrus is 500 tonight; is that expected? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

2 1

Dropping the 'LATER' resolution in Bugzilla
by Diederik van Liere 30 Nov '11

30 Nov '11

Hi folks, Currently, we have a 'LATER' resolution in Bugzilla, it contains 339 bug reports over all the products, see: https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&list_id=57… The question is, when is LATER? Technically, these bugs are not open and so nobody will ever see them again and that's how they will be forgotten. To me, it seems that bugs that are labeled LATER should either be labeled: 1) WONTFIX, which I guess is the majority of these bugs 2) WORKSFORME, I am sure some things have been fixed 3) NEW, it is a real bug / feature request. So why not do a mass change from LATER to NEW, and give them a fresh pair of eyes? and remove the LATER option from Bugzilla. Best, Diederik

10 20

Code review hours
by Brion Vibber 29 Nov '11

29 Nov '11

Due to a schedule conflict I won't be available for review until noonish pacific (around 20:00 UTC) -- brion

1 0

Header Tabs mediawiki 1.16.4
by Michael Maraya 29 Nov '11

29 Nov '11

Hello there, I'm trying to get this to work on mediawiki version 1.16.4. I am having issues with the tabs showing up. They come out as bulleted text instead of tabs. I have read around about possible solutions but there are not working for me, I've installed yui 2.8, used Header Tabs version 8.3, 6.6, 7.0 to no avail and I'm basically stuck. Any help or guidance would be greatly appreciated. Thank you.

2 1

Proper use of LogPage->addEvent without watchlist notifications?
by Daniel Barrett 29 Nov '11

29 Nov '11

Seeking help with Special:Log and the LogPage class... I recently created a custom log and am writing information to it as follows: $log = new LogPage('mylog'); $log->addEntry('mylog', $wgTitle, wfMsg('my-message', $wgTitle->getFullText(), $otherstuff), array(), $wgUser); However, each time this code runs, everybody watching the article $wgTitle gets a bogus "page created" watchlist notification email for the article, with the wfMsg(...) string as the (bogus) edit summary. How do I prevent these notifications from happening when I write to the log? (MediaWiki 1.17.0) Thanks, DanB

1 0

MediaWiki security release 1.17.1
by Sam Reed 29 Nov '11

29 Nov '11

I would like to announce the release of MediaWiki 1.17.1. Two security issues were discovered. Alexandre Emsenhuber discovered an issue where page titles on private wikis could be exposed bypassing different page ids to index.php. In the case of the user not having correct permissions, they will now be redirected to Special:BadTitle. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=32276 The second issue was found by Tim Starling, who discovered that action=ajax requests were dispatched to the relevant function without any read permission checks being done. This could have led to data leakage on private wikis. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=32616 ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.1.tar.gz Patch to previous version (1.17.0), without interface text: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.15.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.17/mediawiki-i18n-1.17.1.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.1.tar.gz.sig http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.1.patch.gz.sig http://download.wikimedia.org/mediawiki/1.17/mediawiki-i18n-1.17.1.patch.gz. sig Public keys: https://secure.wikimedia.org/keys.html

2 1

Re: [Wikitech-l] RFC: Should we drop the rendering preferences for math?
by Lee Worden 29 Nov '11

29 Nov '11

On 11/28/2011 05:46 PM, wikitech-l-request(a)lists.wikimedia.org wrote: > Date: Mon, 28 Nov 2011 15:16:55 -0800 > From: Brion Vibber<brion(a)pobox.com> > > On Mon, Nov 28, 2011 at 3:05 PM, MZMcBride<z(a)mzmcbride.com> wrote: > >> > Brion Vibber wrote: >> > > [snip my notes about removing the non-PNG non-source options, wanting > higher-resolution renderings] > >> > Did you have a chance to evaluate MathJax?<http://www.mathjax.org/> I >> > know >> > it's come up in past math discussions and that a lot of math folks think it >> > looks promising. A technical analysis of its feasibility on Wikimedia wikis >> > would be great. Killing the less-used, ancient math options is great, but >> > perhaps adding one wouldn't be too bad to do too. :-) >> > > That's an excellent thing to bring up -- MathJAX*does* look very > promising, and things seem to render pretty nicely. Need to make sure that > we can either do that type of rendering cleanly with the PNG fallback > (older browsers will still need the PNGs, so it may still be worth spending > the time to fix baselines). Not sure, but you might get better performance by translating the tex to mathml on the server, and having MathJax render the mathml on the client... > Size of the library, and compatibility, could be an issue for mobile but is > worth checking on. (Looks like it*does* work in Android and iPhone > browsers, so has a good chance of being something we could use as a > progressive enhancement.) > > It's actually probably a better idea to go ahead in that direction than to > worry about high-resolution renderings from texvc for now. (Other image > types, including icons in the UI, will still need high-resolution versions > though.) > > -- brion >

1 0

Jump to page:

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