Wikitech-l September 2011

wikitech-l@lists.wikimedia.org

111 participants
132 discussions

Bugzilla Weekly Report
by reporter 26 Sep '11

26 Sep '11

MediaWiki Bugzilla Report for September 19, 2011 - September 26, 2011 Status changes this week Bugs NEW : 217 Bugs ASSIGNED : 14 Bugs REOPENED : 32 Bugs RESOLVED : 173 Total bugs still open: 6090 Resolutions for the week: Bugs marked FIXED : 95 Bugs marked REMIND : 0 Bugs marked INVALID : 20 Bugs marked DUPLICATE : 27 Bugs marked WONTFIX : 18 Bugs marked WORKSFORME : 9 Bugs marked LATER : 7 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 9 Semantic MediaWiki 8 BookManager 7 Babel 6 SemanticForms 4 New Bugs Per Product MediaWiki 22 Wikimedia 18 MediaWiki extensions 49 Wikimedia Mobile 3 Top 5 Bug Resolvers sam [AT] reedyboy.net 23 brion [AT] wikimedia.org 20 mah [AT] everybody.org 14 niklas.laxstrom [AT] gmail.com 11 tfinc [AT] wikimedia.org 10

1 0

Extension Support
by Olivier Beaton 26 Sep '11

26 Sep '11

I am trying to get more steam behind proper support of our extension community from both the mediawiki documentation and core developers. http://www.mediawiki.org/wiki/Manual:Extension_support This is a landing page for support, the idea is that core developers will document changes that affect extension devs in the subpages for each version, both in new classes/functions/variables exttensions should be using now (Upgrading), and if they use the new functions what they should be using if they want to support a version or two back (Downgrading). These should not read as full guides or documentation, but point people in the right direction to class reference pages and Manual: pages where more extensive documentation can be outlined. As time moves on, your documentation with supporting new versions will become the support docs for older versions, so not only does it help our current authors stay current, but it helps in bringing much older extensions (often unmaintained) up to date, and helps extension authors retain support a bit behind the bleeding edge. I hope that others around can show their support and help out with this task now and in the future. Thanks! Olivier Finlay Beaton

1 0

What is the best way to sync a remote (on the web) wiki with a localhost wiki
by Frank 26 Sep '11

26 Sep '11

I recently installed Mediawiki 1.16 on a wikifarm and also on a flash drive. What I would like to do is develop content on the localhost and then sync it with the global wiki. I have looked at both the WikiSync and Push extensions. Push would be my preference for a number of reasons but have been having problems getting it to work. Contacted the author and after a few emails he suggested I come here since he is not really doing development on that extension any more. Is there another way to do it that is relatively simple? Any help would be greatly appreciated... Frank

1 0

Re: [Wikitech-l] Counting revisions in 2011090
by melvin_mm 25 Sep '11

25 Sep '11

Bryan Tong Minh <bryan.tongminh <at> gmail.com> writes: > On Sun, Sep 25, 2011 at 9:09 PM, melvin_mm <melvin_mm <at> gmx.de> wrote: > > > > Are some revisions, e.g. minor edits not included in the dump? > > > Deleted revisions? > If deleted revisions sum up to ~70.000.000 - could I add this information to http://en.wikipedia.org/wiki/Wikipedia:Database_download ? What would you advice to do if I wanted to verify the counter result?

2 1

Counting revisions in 20110901
by melvin_mm 25 Sep '11

25 Sep '11

Hi there, I counted the "<revision" tags in the current 20110901 pages-meta-history (bzip2) and got the result 412,482,641. Using http://www.wikistatistics.net/wiki/en/edits/90 for verification (which works fine for smaller dumps), there should be around 482,500,000 edits, however. Are some revisions, e.g. minor edits not included in the dump? Kind regards, K. Mueller

3 3

Enhanced Spreadsheet to WikiMedia table Converter proposed
by Mariano López Gappa 25 Sep '11

25 Sep '11

I've developed this minimalist tool originally for personal use (I have an offline MediaWiki): https://github.com/MarianoLopezGappa/Spreadsheet-to-MediaWiki-table-Convert… This tool offers similar functionality as http://excel2wiki.net/ proposed at http://meta.wikimedia.org/wiki/Help:Table, but it offers enhanced styling features I really needed. Some highlights: - The project is GPL licensed, OO and thoroughly documented. - It defaults to Wikipedia styling. - Provides a checkbox for first row heading, absent in the current tool. - Provides support for even-odd pattern styling, seen on many Wikipedia articles, also absent in the current tool. The catch being: I don't own any decent hosting service for the GUI, nor the means for acquiring it and keeping it for years to come. It's only about 20KB and it's not CPU intensive. If anyone finds it useful, you are free to publish it somewhere where people can use it. Thanks, Mariano Lopez-Gappa.

2 1

Upcoming Triages
by mhershberger＠wikimedia.org 25 Sep '11

25 Sep '11

I've been trying to maintain a list of upcoming Triages on <http://www.mediawiki.org/wiki/Bug_management/Triage> and, for those who find Twitter or Identi.ca feeds useful, you should check out Sumana's new @meediawikimeet feed (http://identi.ca/mediawikimeet, http://twitter.com/mediawikimeet). >From the page on MediaWiki.org, here is a list of the next three triages planned: * September 28: wikibooks * October 5th: (planned) fund-raising * October 19th: (planned) mobile Thanks, Mark.

2 2

1.18 and Pre design
by K. Peachey 25 Sep '11

25 Sep '11

I'm no SVN user so i'm emailing instead... As the 1.18 users may have noticed (eg: For example a common place would be CodeReview) the new designs for pre. In r87173[1] the layout was changed and based on consensus in review that was reverted and then 1.18 was rebranched at r92475 so I thought they would be back to normal, So has this been changed in another revision? (and if so, what revision) Also this is slightly broken for me (although this could be my browser (chrome)), in which if I click and drag my middle button (scroll wheel) you can ∞ scroll in all directions

3 3

Re: [Wikitech-l] [Mediawiki-l] Conflict with extension developers in reservation of custom namespaces
by Michael Allan 23 Sep '11

23 Sep '11

Daniel Friesen wrote: > The sentiment that the site-specific reservation added is "silly" > seams to be shared by Jack, ^demon, and me at the least. For the > record, all three of us are core developers. Core developers, no less! Well, you have a right to be proud.... MediaWiki is fine software. I guess I'm a core administrator, one of the appreciative folks you've been developing it for. Gregor Hagedorn wrote: > However, I think the basic request to NOW communicate widely which > namespace range should be reserved for site-specific purposes is very > reasonable. > > Of course their will be not contract, but the present situation is > unsatisfactorily. On > http://www.mediawiki.org/wiki/Extension_default_namespaces their is > no recommendation where to set up your site-specific namespaces. The > page says that 100-199 is often used, and extensions should avoid > it, but actually some of the most important extensions happily > invent their namespaces there. > > I don't believe it has to be a 100-block, but a clear commication to > all devs: in the future, at all cost, avoid x-y would be welcome. Maybe it's more difficult for the extension developer (Jack) to move his namespaces, than it would be for us to move ours? In that case, it looks like 900-999 is still free territory: http://www.mediawiki.org/wiki/Extension_default_namespaces If it were clearly marked as a sanctuary - avoid at all costs, as Gregor says - then we'd never have to spend time on this again. A further suggestion: either we 1) pick a large block in the high numbers and mark as *definitely* safe for custom, site-specific use; or 2) do the opposite, and mark the whole high area as off limits, "talk to us first". The worst thing is to leave it as it stands now, because it invites future conflicts of the sort that happened in the 100-199 range. It currently says: For now it would be best to avoid using this range to give sites room to define their custom namespaces without fear of conflict. And later after those namespaces are defined, the rules may change? -- Michael Allan Toronto, +1 416-699-9528 http://zelea.com/ Gregor Hagedorn wrote: > I agree with Daniel on the mechanics of failed communication, and > think any blaming of either side is wrong as well as > counterproductive. > > However, I think the basic request to NOW communicate widely which > namespace range should be reserved for site-specific purposes is very > reasonable. > > Of course their will be not contract, but the present situation is > unsatisfactorily. On > http://www.mediawiki.org/wiki/Extension_default_namespaces > their is no recommendation where to set up your site-specific > namespaces. The page says that 100-199 is often used, and extensions > should avoid it, but actually some of the most important extensions > happily invent their namespaces there. > > I don't believe it has to be a 100-block, but a clear commication to > all devs: in the future, at all cost, avoid x-y would be welcome. > > Gregor

4 5

UploadWizard triage report
by mhershberger＠wikimedia.org 23 Sep '11

23 Sep '11

(This bug triage summary is two weeks overdue.) On 2011-09-07, I held a triage covering open issues in Bugzilla for UploadWizard. Unlike previous triages, I didn't try to cull any particular bugs from all of the bugs filed against UploadWizard. Instead, I attempted to find different groups of bugs by symptom and focus on those groups during triage. Some rearrangement of the categories I gave has happened since the triage, but you can follow all the original work on the Etherpad: http://hexm.de/7m Link to complete list of bugs covered here: http://hexm.de/7l There were 44 open bugs in the triage. In the past two weeks, 17 have been closed, leaving 27 issues still to be resolved. In the following summary, only the bugs that were dealt with in IRC are mentioned. Bugs marked with asterisk have been closed. ==Wiki Loves Monuments bugs== *https://bugzilla.wikimedia.org/29293 UploadWizard: License Tutorial should be optional *https://bugzilla.wikimedia.org/30762 Overwrite of the copyright owner in campaigns has no effect *https://bugzilla.wikimedia.org/30644 UploadWizard campaigns are deleted on GET, should use POST https://bugzilla.wikimedia.org/30645 No history for upload campaigns Strainu from Romania's Wiki Loves Monuments (http://wikilovesmonuments.ro/) showed up with to ask for help on their use of UploadWizard in some campaigns. #29293 was closed immediately by Jeroen who said it was one of the first things he did. Jeroen also claimed #30762 and #30644 and has, as of now, committed fixes for them. The one remaining one (#30645) now has a plan of attack that should lead to a solution. == Licensing == https://bugzilla.wikimedia.org/29249 UploadWizard: add custom license wikitext option Most of the bugs I had in the licensing section were not discussed, except for #29249 by Erik on the etherpad. I had asked if this was a WONTFIX. Erik however pointed out that some advanced users want this ability. Neil posted a spec for the implementation (http://hexm.de/7p) and then asked for comments (http://hexm.de/7q). == Muggle behavior (Anti-wizard) == *https://bugzilla.wikimedia.org/24758 Upload wizard: API errors that block progress on description page submission https://bugzilla.wikimedia.org/29594 Upload wizard: no way back when trying to upload a file that already exists *https://bugzilla.wikimedia.org/30423 In Upload Wizard, bad file name leads to a dead-end. https://bugzilla.wikimedia.org/30687 Implement backwards navigation in UploadWizard (tracking) Neil said #24758 is fixed, but the way it was defined is too broad. He closed the bug and gave instructions for creating new, more discrete bugs instead of reopening the bug. I suggested #29594 and #30687 be merged, but Neil pointed out that the first was a specific problem and the next was a broader issue. As a result, we made #30687 a tracking bug and included #29594 as an issue it tracks. At the meeting, #30423 was still unconfirmed — Erik hadn't been able to replicate it — but shortly after the submitter confirmed that the issue was no longer present. == Browser == https://bugzilla.wikimedia.org/24720 Upload wizard: Upload link not changing cursor to a hand *https://bugzilla.wikimedia.org/26186 Select a file to upload button pointer inconsistent https://bugzilla.wikimedia.org/29767 Uploads complete without description in ie6/ie8 https://bugzilla.wikimedia.org/25902 Icons for stashed audio files are broken Neil pointed out that #24720 was just a cosmetic issue that didn't stop people from using UploadWizard. I dropped priority appropriately. #26186 duped to #30807 -- UploadWizard big "upload a file" button half-clickable in some browsers -- which was solved. Neil said that #29767 was "kinda high priority because it allows submission without description." See my next email for upcoming triages.

1 0

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

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 2011