Wikitech-l September 2011

wikitech-l@lists.wikimedia.org

111 participants
128 discussions

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 24 Sep '11

24 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 24 Sep '11

24 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

USERINFO email
by Ashar Voultoiz 23 Sep '11

23 Sep '11

Hello, As I understand it, the git conversion will require an email address for any commiter in our subversion repository. The way we fill the email address currently is through the USERINFO repository available with subversion at: http://svn.wikimedia.org/svnroot/mediawiki/USERINFO Each file is named according to a svn author and filled with various fields. The email address can be filled under the field "email:" and can be obfuscated. Example for author "hashar": name: Ashar Voultoiz email: hashar at free dot fr url: http://fr.wikipedia.org/wiki/User:Hashar irc: hashar languages spoken: French, English father: yes I have just imported in subversion the list of authors from the code review extension deployed at www.mediawiki.org. It would be great to fill in the email: fields for each of the author that are missing it. It will ease the git migration :-) A shell one liner will get you an up-to-date list of author files which are missing the "email:" field: egrep -c ^email: * | egrep -v '1$' | cut -d\: -f1 | sort In case an author is an alias, you can add an "alias:" field to the new user name. For example gwicke used to commit with the name gabrielwicke hence is "gwicke" author file has the special field: aliases: gabrielwicke The output for the above oneline is below. Please help populating email address :-) abernala abigor aboostani adam adammck adhair ajvol algorithmix angelab axelboldt b_stancescu bachsau balasyum bartek beckr bhagya bradneuberg brezelben diana dschwen emiller erwin85 evanprodromou fabianh flominator fptc fvassard gmaxwell greenreaper gri6507 gslater harddisk hhappel jonwilliford lcrocker mbrad misza13 mulligen nojhan robh root rscheiber sanyamgoyal shaihulud swiftlytilting tgries tor warddr yaauie -- Ashar Voultoiz

4 4

Final Google Summer of Code 2011 roundup
by Sumana Harihareswara 23 Sep '11

23 Sep '11

http://blog.wikimedia.org/2011/09/22/gsoc-students-reach-project-milestones/ Yuvi, Akshay, and Kevin still need some code review and discussion to ensure their code gets to deploy quality. Please help them out if you're not currently in the midst of the 1.18 deployment rush. 7/8 of our students passed, all the WMF-related projects are somewhere on the road to being merged and deployed, and every single student said that their mentors were great and they've learned a lot. Thanks to all the students, mentors, and other community members who made this a pretty darn successful Summer of Code. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

2 1

Re: [Wikitech-l] [Mediawiki-l] Conflict with extension developers in reservation of custom namespaces
by Brion Vibber 22 Sep '11

22 Sep '11

The 100-199ish range has for years been the standard convention for site-specific custom namespaces -- any extension hardcoding in that range does so at its own risk, and for instance can't be deployed on existing Wikimedia sites which already put their site-specific namespaces there. The best thing to do though is to remove the requirement to worry about namespace numbers at all; just as we don't need to enforce any special rules about page and revision id numbers, they should be managed internally to the wiki's database and not enforce any particular meaning on their own. There was some prelim work on this a few years ago ('Namespace Manager') and the idea gets brought up again; here's a recent bugzilla entry which should be a good place to start hanging that: https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 -- brion On Thu, Sep 22, 2011 at 3:18 AM, Gregor Hagedorn <g.m.hagedorn(a)gmail.com>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 > > _______________________________________________ > MediaWiki-l mailing list > MediaWiki-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l >

1 0

Re: [Wikitech-l] Conflict with extension developers in reservation of custom namespaces
by Daniel Friesen 22 Sep '11

22 Sep '11

On 11-09-22 01:13 AM, Michael Allan wrote: > Hello to all, > > I'm posting to request help with a conflict in namespace registration: > http://www.mediawiki.org/wiki/Extension_default_namespaces?oldid=430890 > Wiki admins are looking for a safe range of namespaces to use for > custom, site-specific purposes. A little over a year ago, we floated > the range 500-599 on the registration talk page. There were no > objections, so, a couple of months ago we reserved the range and > amended the manual. You can see the discussion in section 4: > http://www.mediawiki.org/wiki/Talk:Extension_namespace_registration?oldid=4… > > It turns out that an extension had already been using that range. > Apparently the developer forgot to register it (see section 5, above). > I guess he spoke to someone else, because just yesterday: > > * The namespace registration system was replaced with a "default" > system and the page was moved: > http://www.mediawiki.org/wiki/Extension_default_namespaces > > * The range 500-599 is no longer marked as reserved in the same > manner as the extensions are marked. > > * A Liquid Threads extension was enabled on the talk page. (I > mention this because it fails on my Firefox 3.6, so I can't use > the talk page anymore.) > > I guess the issue isn't open for discussion there, anyway. Please > someone else take a thought for the needs of the admins, and: > > 1. Pick a range to reserve for site-specific use. A whole block of > 100 would be ideal, if that's possible. > > 2. Clearly mark the range as reserved, in the same manner as the > extension ranges are marked. For example: > http://www.mediawiki.org/wiki/Extension_default_namespaces?oldid=430890#Sit… > > 3. Update the manual to reflect these changes: > http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces > > The extension developer (the one who forgot to register his namespace) > says this is a "silly" request, but I think it's quite reasonable. > > > PS - Could someone also add a link to this thread from the talk page? > I am no longer able to post there. > http://www.mediawiki.org/wiki/Talk:Extension_default_namespaces Please include wikitech-l in this discussion. Not every developer watches mediawiki-l because it's more of a help list, wikitech-l is our mailing list for development discussion. Jack is not the author of the BlogPage extension. BlogPage is an extension developed for ArmchairGM, Jack has kindly been porting ArmchairGM and Wikia built extensions to be installable in normal MediaWiki. Naturally as he recently ported the BlogPage code that was in an external code repo and put it in our code repo for everyone to use, he went and responsibly added the namespaces that the extension has been using since it was developed (presumably sometime back in 2007) to that page so people would know. There were no 'objections' because practically no-one even knew that discussion existed. That's like walking into a forest, shouting out "I am now king of North America", then walking back into a city and asserting that because no-one objected you're now king. ArmchairGM was founded in 2005, bought by Wikia in 2006, and their code was released in early-mid 2008. That page on MW.org however never existed before mid-2008. So not only is the concept of forcing 3rd party companies to abide by and add information to a wiki page we have on MW.org ridiculous, that page never even existed when BlogPage was developed. 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. That page does NOT list "reservations" or "registrations". It is nothing but a helpful informational page that lists default namespaces currently used by existing extensions and other known practices. The only purpose being so that developers of new extensions who want to try and avoid conflicting with namespaces other people may already be using can do so by avoiding any area of namespace numbers that people are already using. The page itself even lists two extensions using 600-601. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

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

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