Renaming of uploaded files has been disabled for the last couple of
months pending software updates; as of today it is now re-enabled for
admins on all Wikimedia sites.
Local admins can now rename files as well as deleting them; this makes
it easier to track history for images and other media that need to be
moved to another name.
-- brion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
I’m Ireas (Robin) from the German Wikipedia (this is the reason for my
perfect English ;)) and I’d like to help coding, patching, building
extensions, etc. Of course I read the help page “How to become a
hacker”, but actually it didn’t really help me as I have no ideas what
to do. But I read a “lack of ideas” is no problem and that there were
enough things to do. I didn’t find a list of these tasks, so I’d be
pleased if you could give me some tips and hints what to do.
Thank you!
Robin (aka ireas)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJKt8LwAAoJEEQBhvJegfqjvjYH/jIjtntmnAVF9ZJuahoAK3GC
FZ4KZAo79VXvo5BCemJLssf/HyXwNHqSDOhs5m4DM8QxPKQlqkXY356DVK4xL48+
WijO8HpoRkIehhqJ4f9HyTEnSxPObhxKxJtLBq0VV1vR+Ube86HUOEvQcSjnx1p6
9X3TQYOO/HUVwyyIh5SzGCeRh5Qfsc6Qat80AKb2mhjE2pYk89AOdpoh/L33K2ye
ivQTy9AGpN/UB++0+3vYvjABt/SAIZjCrw63sskPEcp5CaQJc0W5l7a/o4pcIKH6
vHEP1cAmQm92jqE8aa9hIrVfVtmtRG9zl9dDE9GTz8hb8qGNTqE10n66C9CceII=
=9u4e
-----END PGP SIGNATURE-----
I am looking at bug 1310, which involves parser behavior such that
when given nested tag extensions, i.e.:
<tag>
AAA
<tag>BBB</tag>
CCC
</tag>
The parser selects the tag block as running from the first open tag to
the FIRST close tag, i.e. in the example it gives:
AAA
<tag>BBB
as the inner text of the first tag. It should be fairly
straightforward to modify this to handle nested tags by checking for
additional open tags in the inner string.
However, since this is parser behavior going back to the dawn of time
(first reported in MW 1.4), I wanted to ask if there are known use
cases where the current behavior is actually the expected behavior?
In other words, are there any use cases in the current code base or
extensions that would necessarily break if the parser were changed to
allow nested tags? I can't think of any right now, but I wouldn't
want to modify an old parser quirk without giving it a good look. For
the record, my particular interest is related to nested refs.
-Robert Rohde
I think it is extremely important to keep these files for later analysis by
historians and others.
Mathias Schindler also keep an archive or at least did till April (Berlin
conference).
He even bought a dedicated external drive for it.
I collect files daily and merge 24 hourly files into one daily file.
That saves a lot on disk space and makes processing faster.
Titles with less than 10 requests per day are discarded that also saves a
lot.
For the remainder instead of 24 comma separated values I use a 'sparse
array' as follows:
B2D15G2 means 2 views in 2nd hour (0100-0200), 15 in 4th, 2 in 7th
The string starts with total for whole day
(redundant but eases processing for some purposes)
So actually it is 19B2D15G2
Example:
de Berlie_Doherty 9L2O1Q1R2T3
de Berliet 20E2F1K1M1N2O3P3Q4R2X1
de Berliet_GBC_8_KT 17B1E1J3M2N1O1P1Q1R2S1T1U1V1
de Berlin
8488A116B56C32D56E21F43G98H172I316J531K636L675M601N533O524P508Q510R576S426T4
92U530V508W328X200
I have files from August 2008. Roughly 3 Gb per month now.
And yes a more permanent, fail-safe and more accessible storage location
would be great.
Erik Zachte
> -----Original Message-----
> From: Frédéric Schütz [mailto:schutz@mathgen.ch]
> Sent: Thursday, September 17, 2009 22:34
> To: toolserver-l(a)lists.wikimedia.org
> Cc: wikitech-l(a)lists.wikimedia.org; Erik Zachte
> Subject: Re: [Toolserver-l] Archive of visitor stats
>
> Lars Aronsson wrote:
>
> > Are visitor stats (as produced by Domas) safely archived
> > somewhere, for example on the toolserver, where development
> > projects can easily access them for analysis? I have made my own
> > copies of the files (I guess my plan was to use them, but this
> > hasn't started yet), but now I'm running out of disk and I
> > urgently need to clear some space on that server.
> >
> > I just deleted September 2009 (last 2 weeks) and that freed 9 GB.
> >
> > The oldest I have is pagecounts-20071209-180000.gz
>
> As Platonides mentioned, they are in /mnt/user-store/stats on the
> toolserver; however, I would not call that "safely archived": one of my
> cron jobs just copies them from Domas server, and that's it.
>
> At the moment, there should be everything starting from 1 January 2009
> (although part of it disappeared at some point, but I managed to
> recover
> it).
>
> However, this is definitively not a sustainable solution in the long
> run: the files currently take 335 Gb (out of a 1.5 Tb total space).
>
> Erik Zachte stores archives of visitor stats in a better format,
> aggregating some of the older data and storing several days of data in
> one file. I started looking into these files earlier this year,
> planning
> to spend some time playing with this data. One of my ideas was to
> replicate the statistical data that is on the WMF stats server
> somewhere
> on the toolserver -- and do it "officially" and not just by copying
> files using a personal cron job. Unfortunately, "real life" took over
> and I did not manage to continue this (and still can't). However, if
> there is any interest in improving the situation, I'd be glad to look
> into it as soon as I can.
>
> I cc' Erik who may have more to say.
>
> Cheers,
>
> Frédéric
Hi all,
After recently being granted commit access to MediaWiki SVN (thanks!) I have
added my two extensions. Unfortunately although it's been about 48 hours, the
ExtensionDistributor page is still reporting them as unknown extensions:
http://www.mediawiki.org/wiki/Special:ExtensionDistributor/MassEditRegex
However the link to browse SVN in the same template works fine:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/MassEditRegex/
>From the ExtensionDistributor docs it looks like an hourly cronjob is meant to
run to add/remove extensions - is this working, or do I need to do something
else to add my extensions into the list?
Many thanks,
Adam.
Are visitor stats (as produced by Domas) safely archived
somewhere, for example on the toolserver, where development
projects can easily access them for analysis? I have made my own
copies of the files (I guess my plan was to use them, but this
hasn't started yet), but now I'm running out of disk and I
urgently need to clear some space on that server.
I just deleted September 2009 (last 2 weeks) and that freed 9 GB.
The oldest I have is pagecounts-20071209-180000.gz
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
[cc commons-l, please keep the discussion on wikitech-l]
As you may know we use ugly uselang hacks on Commons to create our own
distinct upload forms. I want this functionality in MediaWiki.
HTMLForm provides a great way to abstractify form construction by
providing a descriptor that can be transformed into an HTML
presentation. What I want is to have allow Commons admins to create
custom uploads forms by providing a descriptor suitable for HTMLForm,
which is then translated to HTML and accessable via
Special:Upload/formname.
The question is how to allow admins to edit this descriptor. In PHP
this is simply an array. We could allow input as JSON or XML in a
MediaWiki: namespace message, which is then translated to an array and
then fed to HTMLForm. Or it could be only GUI editable via a Special
page and the forms can be stored elsewhere in the database.
Opinions, ideas?
Cheers,
Bryan
Due to compatibility problems on Internet Explorer after yesterday’s
code update, I’ve temporarily disabled the Usability Initiative’s beta
advanced toolbar. If you’ve had it enabled, you’ll just get the regular
old edit toolbar until we re-enable it.
Hopefully we should have this resolved within a day or so, and it’ll be
back on for all our happy testers!
If you want to follow the fix:
https://bugzilla.wikimedia.org/show_bug.cgi?id=20668
-- brion
Hi all,
In order to enable the easy tracking of regressions caused by code
updates, I've added the code-update-regression tag to bugzilla.
From now on, regressions caused by a general code update should have
this keyword. We might want to, next time, stick a link to the "Enter
bug" form with this keyword pre-filled in a centralnotice when doing
code updates.
Tip: Here's a bugzilla search showing the bugs tagged with this
keyword: http://bit.ly/3SVlLp
Hope this helps out.
--
Andrew Garrett
agarrett(a)wikimedia.org
http://werdn.us/