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
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.
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
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
(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.
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
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
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
>
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]