Wikitech-l July 2013

wikitech-l@lists.wikimedia.org

158 participants
162 discussions

Possibly malicious script inside "United_Kingdom" article
by Sergey Grass 08 Jul '13

08 Jul '13

Dear ladies and gentlemen! Every time when I go to this page: http://en.wikipedia.org/wiki/United_Kingdom, the following script causes my browser (Firefox) to freeze. Script, which causes harm: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&mod… This occured only on aforementioned web page. All other pages work normally. Sort this thing out, please! Sincerely yours, Sergey G

4 3

IRC office hour on Tue July 16th, 1600 UTC, about Bug management
by Andre Klapper 08 Jul '13

08 Jul '13

Hi everybody, on Tuesday 16th 16:00 UTC[1], you are invited to an IRC Office Hour in #wikimedia-office about Wikimedia's issue tracker[2] and Bug management[3] in general. Add it to your calendar and come to ask how to better find information in Bugzilla that interests you, and to share ideas and criticism how to make Bugzilla better! I'm going to answer your questions and discuss ideas about bug management and Bugzilla, plus explain what's on the to-do list[4]. Looking forward to talking to you! andre [1] https://meta.wikimedia.org/wiki/IRC_office_hours [2] https://bugzilla.wikimedia.org [3] https://www.mediawiki.org/wiki/Bug_management [4] https://www.mediawiki.org/wiki/Bug_management/Task_list -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Re: [Wikitech-l] [Xmldatadumps-l] Suggested file format of new incremental dumps
by Ariel T. Glenn 08 Jul '13

08 Jul '13

Στις 07-07-2013, ημέρα Κυρ, και ώρα 21:09 -0700, ο/η Randall Farmer έγραψε: > Sorry, reading back over this thread late. > > > > What I hope for is a format that allows dumps to be produced much > more > > rapidly, where the time to produce the incrementals grows only as > the > > number of edits per time frame grows > > > Curious: what's happening currently that makes the time to produce > incrementals grow more quickly than that? > We don't produce true incrementals now; we produce 'adds/changes' dumps which don't acocunt for deletions, oversights, page moves, etc. And you can't add them onto a full to get a new full. When they are produced, I want them to behave as described above. Ariel

1 0

Bugzilla Weekly Report
by reporter 07 Jul '13

07 Jul '13

1 0

Moving on from Doxygen?
by Yuvi Panda 07 Jul '13

07 Jul '13

Hello! Our current generated documentation[1] uses doxygen, and leaves... a number of things to be desired - such as: 1. Not be tortoise slow 2. Have usable search 3. Prettier interface I was looking around for alternatives, and ran into phpdocumentor2[2]. The project still seems active (latest commit was 3 days ago, and for vagrant support!), and the demo was quite pretty: http://demo.phpdoc.org/Responsive/namespaces/phpDocumentor.html Is there any particular reason we are still sticking with doxygen? Or is it just 'someone needs to find the time to move things over to the new system'? [1]: https://doc.wikimedia.org/mediawiki-core/master/php/html/ [2]: http://www.phpdoc.org/ -- Yuvi Panda T http://yuvi.in/blog

8 10

Proposed RFC process
by Tim Starling 06 Jul '13

06 Jul '13

Rob Lanphier has asked that the WMF architects -- namely Brion Vibber, Mark Bergsma, Asher Feldman and myself -- take a leading role in accepting or rejecting RFCs, or delegating that decision as appropriate. Along these lines, I'd like to add an header template to every RFC indicating its status as determined by one of these architects or the people to whom they delegate authority. The header would indicate not only status (mirroring the index page) but also the name of the person who chose that status. Seeking consensus has always been a key part of my work on MediaWiki. I expect that a large part of assigning a status to an RFC will simply be to evaluate the comments of the participants, or to seek comments from specific domain experts where none have been given. Many RFCs are just "good ideas", often attracting no comment because there is no obvious criticism of the feature at the level of detail given by the proposer. This raises the question of whether an RFC is a feature request (like a Bugzilla enhancement) or a design document. If an RFC is a design document, then we might ask for more detail about feature implementation, and close the RFC if none is given. This may lead to the closure of RFCs which have no interest or support from developers. I'm inclined to think that this is an appropriate path to take, i.e. that RFCs should be design documents, but I am interested to hear comments on the subject. Please comment here or on <https://www.mediawiki.org/wiki/Talk:Requests_for_comment> -- Tim Starling

6 6

Recommending some minimum documentation practices
by Ryan Kaldari 05 Jul '13

05 Jul '13

Please see the proposal at: http://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/PHP#Recommendi… Ryan Kaldari

1 0

Re: [Wikitech-l] [Xmldatadumps-l] Suggested file format of new incremental dumps
by Petr Onderka 04 Jul '13

04 Jul '13

I'm writing it in C++. If you want, you can follow my progress in the operations/dumps/incremental repo, branch gsoc [1] (but there isn't almost anything there yet). And I don't have any computers with non-x86 architecture, so I won't be able to test that. [1]: https://git.wikimedia.org/log/operations%2Fdumps%2Fincremental/refs%2Fheads… On Wed, Jul 3, 2013 at 10:13 PM, Byrial Jensen <byrial(a)vip.cybercity.dk>wrote: > At 03-07-2013 18:29, Petr Onderka wrote: > >> I'm primarily a Windows guy, so I'm trying to write the code in a >> portable way and I will make sure the application works on both Linux >> and Windows. >> > > That sounds good. Just remember that portable not only means that it works > on different operating systems on the same computer architecture, but also > on different architectures. What programming language do you intend to use? > > > > ______________________________**_________________ > Xmldatadumps-l mailing list > Xmldatadumps-l(a)lists.**wikimedia.org <Xmldatadumps-l(a)lists.wikimedia.org> > https://lists.wikimedia.org/**mailman/listinfo/xmldatadumps-**l<https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l> >

2 2

Proposal regarding a distinct Extension infobox status color for status "unmaintained"
by Thomas Gries 04 Jul '13

04 Jul '13

Someone proposed to have a _distinct color for status "unmaintained"._ Status "unmaintained" is currently signalled with gray color, the same as for status "unknown" The current color scheme can be found at the lower part of page: https://www.mediawiki.org/wiki/Extension_status The proposal was added here: http://www.mediawiki.org/w/index.php?title=Template_talk:Extension&offset=2… and somehow related is https://www.mediawiki.org/w/index.php?title=Template_talk:Extension&offset=… Because such a color scheme change can have a wide impact and unwanted side-effects, I cross-post the proposal here.

3 3

The image URL vs. AdBlockPlus
by Strainu 04 Jul '13

04 Jul '13

Hi, I've hit an interesting problem with the URL of an image (not the description page) on the OSM wiki. I could not see the image from http://wiki.openstreetmap.org/wiki/File:731.jpg until I actually clicked on the "full resolution" link. The reason for that was that the image URL was http://wiki.openstreetmap.org/w/images/a/ad/731.jpg , and one adblock rule was blocking "/ad/". That particular rule was from my personal list, but I've noticed that EasyList, the "basic" subscription for AdBlockPlus users, is also blocking lots of strings that start with /ad/. Has someone else notice such a problem on WMF wikis? Do you think it would be worth it to change MediaWiki so that it doesn't generates URLs containing /ad/, /ads/ or something else along these lines? Thanks, Strainu

3 2

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 July 2013