Fellows,
This is Google's cache of http://en.wikipedia.org/wiki/Devo. It is a
snapshot of the page as it appeared on 28 Sep 2011 09:22:50 GMT. The
current page could have changed in the meantime. Learn more ...
Like why is it so much faster than the real thing? Even when not logged in.
Nope, you may be one of the top ranked websites, but no by speed.
So if you can't beat 'em join 'em. Somehow use Google's caches instead
of your own. Something, anything, for a little more speed.
Hi everyone!
I would like to hold a brown bag lunch on Selenium Unit Testing for
Mediawiki extensions.
I have been using phpunit and Selenium for a few years.
Selenium Unit Testing in the core has been put on hold until we get our new
QA Lead.
I have attached an event to this email for Wednesday, September 7th from
12:30pm - 1:00pm
There will be a small presentation on how we may use Selenium on the
Fundraising extensions.
Discussion/questions will follow.
Thanks!
--
Jeremy Postlethwaite
jpostlethwaite(a)wikimedia.org
515-839-6885 x6790
Backend Software Developer
Brown bag - Selenium Unit Testing
Selenium Unit Testing on Mediawiki
*When*
Wed, September 7, 12:30pm – 1:00pm GMT-07:00
*Where*
SF Office Sixth floor
*Who*
•
Jeremy Postlethwaite
•
wikitech-l(a)lists.wikimedia.org
Wikimedia Foundation <http://wikimediafoundation.org/>
Hey guys,
I just wanna say a _big_ thank you to all the people that were
involved in the design and maintaince of the upload system on Commons!
Over 140k of pictures in a month on top of the regular traffic is
something.
And if we got around to this, can you tell us when were the most
pictures uploaded per minute/hour/day? Do you guys have such
statistics?
Thanks A LOT,
Strainu
Hello to both the wikitech and pywikipedia lists -- please keep both
informed when replying. Thanks.
A few days ago, we - the pywikipedia developers - received alarming
reports of interwiki bots removing content from pages. This does not
seem to happen often, and we have not been able to reproduce the
conditions in which this happens.
However, the common denominator is the fact it seems to be happening
only on the wikipedia's that run MediaWiki 1.18 wikis. As such, I
think this topic might be relevant for wikitech-l, too. In addition,
there is no-one in the pywikipedia team with a clear idea of why this
is happening. As such, we would appreciate any ideas.
1. What happens?
Essentially, the interwiki bot does its job, retrieves the graph and
determines the correct interwiki links. It should then add it to the
page, but instead, /only/ the interwiki links are stored. For example:
http://nl.wikipedia.org/w/index.php?title=Blankenbach&diff=next&oldid=10676…http://eo.wikipedia.org/w/index.php?title=Anton%C3%ADn_Kl%C3%A1%C5%A1tersk%…http://simple.wikipedia.org/w/index.php?title=Mettau%2C_Switzerland&action=…
2. Why does this happen?
This is unclear. On the one hand, interwiki.py is somewhat black
magic: none of the current developers intimately knows its workings.
On the other hand, the bug is not reproducible: running it on the
exact same page with the exact same page text does not result in a
cleared page. It could very well be something like broken network
error handling - but mainly, we have no idea. Did anything change in
Special:Export (which is still used in interwiki.py) or the API which
might cause something like this? I couldn't find anything in the
release notes.
3. Reasons for relating it to MW 1.18
To find out on which wikis this problem happens, I used a
quick-and-dirty heuristic:
select rc_comment, rc_cur_time, rc_user, rc_namespace, rc_title,
rc_old_len, rc_new_len from recentchanges left join user_groups on
ug_user=rc_user where rc_new_len < rc_old_len * 0.1 and ug_group =
'bot' and rc_namespace=0 limit 10 /* SLOW OK */;
This is a slow query (~30s for nlwiki_p on the toolserver), but it
gives some interesting results:
nlwiki: 9 rows, all broken interwiki bots
eowiki: 25 rows, all interwiki bots
simplewiki: 3 rows, of which 2 are interwiki bots
dewiki: 0 rows
using rc_old_len * 0.3: 14 rows, all double redirect fixes
frwiki: 9 rows, but *none* from interwiki bots (all edits are by the
same antivandalism bot)
itwiki: 0 rows
ptwiki: 0 rows
All ideas and hints are very welcome. Hopefully we will be able to
solve this before tuesday...
Best regards,
Merlijn van Deen
Awesome work Christian. Where can we find your code to test out?
If you don't have a place then I'll carve one out in our depots.
On Sep 24, 2011 5:57 AM, "Christian Pühringer" <christian(a)puehringer.net>
wrote:
> Hi Emanuel,
>
> Makes sense that images are not compressed in zim file again, thanks for
the
> clarification.
> In particular for windows mobile this increases the probability that with
> reducing the cluster size
> a sufficient performance is achieved (i.p. if there was a better way to
display
> images than in android, but I haven't looked into this).
> For android I still expect that it it will be better to use a native
library.
>
> Christian
> Am 24.09.2011 14:30, schrieb Emmanuel Engelhart:
>> On 24/09/2011 14:24, Christian Pühringer wrote:
>>> The JAVA liblzma performance is pretty bad: To increase efficiency of
>>> compression in the zim-format articles (and also all
>>> other data like images) are stored in clusters. Cluster size is
apparently about
>>> 1 MB. This implies that loading an article
>>> which is stored at the end of a cluster involves decompressing the
complete
>>> cluster.
>> Images should not be compressed in ZIM files for the obvious reasons
>> they mainly are already compressed. This is the case for all ZIM files I
>> made. As far as I know this is also the case for Mediawiki:Collection
>> build ZIM files.
>>
>> Emmanuel
>>
>
> _______________________________________________
> dev-l mailing list
> dev-l(a)openzim.org
> https://intern.openzim.org/mailman/listinfo/dev-l
Ariel T. Glenn<ariel<at> wikimedia.org> writes:
> Στις 26-09-2011, ημέρα Δευ, και ώρα 02:20 +0200, ο/η melvin_mm έγραψε:
> > Ok, thanks! So in pages-meta-history, those ~33.000.000 archived /
> > deleted revisions are not included. Probably this number consists of
> > content from all Namespaces.
> > What about the 37.000.000 revisions that are left now?
> >
>
> I guess that the wikistatistics.net page must get its values from
> Special:Statistics, since I see today that total number of edits as of
> Mon 26 Sept 2011 05:47:31 am UTC is 487,971,977, which is not far off
> from wikistatistics' value of 487 914 061. However, this number is not
> guaranteed to be accurate. The real number is
>
> mysql> select max(rev_id) from revision;
> +-------------+
> | max(rev_id) |
> +-------------+
> | 452476647 |
> +-------------+
> 1 row in set (0.00 sec)
>
> Ariel
Thanks! Summing up:
412.482.641 counted "<revision" tags in 20110901
+
33.263.574 deleted revisions not included in pages-meta-history
+
5.391.296 revisions from September 1st to September 26th (according to
wikistatistics.net, with 482.522.765 on September 1st)
we get to
451.137.511
.
About 1.339.136 left from the current rev_id from the database. Where
could the missing ones be? Incorrect wikistatistics.net results?
Best,
Katja Müller
Hi, I was wondering if someone out there could please point out a
better way to store some data I'm using in this extension.
The basic premise is to display a header or footer for all pages
within a given namespace or category (it also allows a global one, or
page specific). I decided to leverage MediaWiki's ability to edit
pages to store the actual headers and footers, which made a lot of
sense because they are wikitext.
I obviously don't want them searched, so at first I put them in
NS_MEDIAWIKI. The urls look something like:
MediaWiki:HeadersFooters/Cat/<catname>/Header
Alphos and bawolff pointed out in IRC that if I was going to use
NS_MEDIAWIKI I should make them more message like... so I've converted
to: MediaWiki:headersfooters-cat-<catname>-header
And I'm checking if the message exists before fetching the contents
using wfMsgForContentNoTrans. This is interesting because technically
an administrator could make some multi-langual messages in the i18n
file manually. A potential problem is that as far as I know messages
aren't really supposed to be mixed case, and a category name inserted
into <catname> could definitely have some uppercase letters in it.
Reedy in IRC mentioned this was all awful, but didn't offer any
suggestions when I asked.
Another idea I had was to store these messages as pages in a custom
namespace, like HeadersFooters:Cat/<catname>/Header -- although I have
no clue how I would go about making my extension add a new custom
namespace without the admin having to go and make them herself, so
some information about this would be much appreciated.
Yet another would be to store them in a new database table, but this
sounds really clunky and icky, but maybe I'm wrong and it's slick? It
would necesitate I create all these editing and management pages for
the new table.
I'm designing a SpecialPage to make sure users can make these headers
and footers more easily.
Does anyone have any suggestions for me? Anything would be appreciated,
- Olivier Finlay Beaton
This past Wednesday, I held a triage focused on issues from the
Wikibooks an Wikisource projects
** https://bugzilla.wikimedia.org/18861 - Search should give transcluded
text for the page
First, a confession. I'm not an experienced Wikipedian. So when I
saw this bug, I didn't understand the benefit. "Wouldn't you
just need to add namespaces to the search index?" I thought.
Luckily, Roan was in this triage and offered a simple use case:
Wiktionary does crazy things like
{{buildATableOfAllInflections|word|inflectioncase}} — which will
produce a table of all inflections of "word", based on which case
applies to it. So then if you search for an inflection of "word",
say "words", you won't find it.
With the help of this explanation, I was able to understand the
usefulness and what was needed. MWSearch needs to index *expanded*
Wikitext rather than just raw Wikitext.
This would probably also fix that annoying bug where incategory:foo
queries don't work properly with categories from templates
This has been proposed as a Summer of Code idea for 2012.
** https://bugzilla.wikimedia.org/28277 - Error when importing pages from
English Wikipedia to Portuguese Wikibooks
This strange bug caused problems on the Portuguese Wikibooks project,
and we were able to reproduce it during triage. I put Helder.wiki's
steps for reproducing this on the bug and hope to find a developer to
work on it soon.
** https://bugzilla.wikimedia.org/189 - please find a solution for a
music module
After some discussion, I decided to close this bug (which has gotten
over 115 comments) and focus any new effort on action items derived
from it like "Make [[mw:Extension:LilyPond]] safe against DoS attacks"
(https://bugzilla.wikimedia.org/29630).
Sumana is already using this issue as a possible area for volunteers
to work on.
Side note: prior to this triage, the LilyPond Extension existed only
on a MediaWiki page. After the triage, I committed the LilyPond code
to SVN and, almost immediately, it began getting valuable reviews and
updates. http://hexm.de/80
I think this really shows the value of our code review process —
especially as we've improved it over the past year or so.
** https://bugzilla.wikimedia.org/27256 - Correcting content page count at
en.wikibooks and pt.wikibooks
It looks like we spent a bit of time discussing this bug without any
of us being aware of 1.18's new $wgArticleCountMethod. I've updated
the bug with the necessary information.
** https://bugzilla.wikimedia.org/22911 - Install
extension:SubpageSortkey on wikibooks
Bawolff has created an extension to solve Helder.wiki's original
request ("Default 'sort key' for namespaces should be more namespaces
with subpages should be customisable"). At this point it simply needs
to be reviewed and deployed.
** https://bugzilla.wikimedia.org/15071 - Wikibooks/Wikisource needs
means to associate separate pages with books.
** https://bugzilla.wikimedia.org/2308 - ability to watch "bundles" of
sub-pages
These two bugs and Raylton's Extension:BookManager revolved around
these projects' desire to treat books as entities that can be
manipulated in the same way as wiki pages. They'd like the ability to
watch, delete, or move books as well as a have pages like
Special:RandomBook.
Adding some of these features (watching, for example) to all pages in
a category, might help admins in other projects besides these.
** https://bugzilla.wikimedia.org/30666 - Show subpages on page deletion
As Bawolff said, this looks like a sane feature request in general, not
just for wikibooks. Adrignola gave a couple of gadgets that enable
subpage deletion, but the gadgets didn't provide a clean way to undelete
sub pages en-masse.
This sparked a discussion on some other enhancements that would be
good to have. For example the ability to watch all articles in a
category (https://bugzilla.wikimedia.org/1710)
** https://bugzilla.wikimedia.org/26881 - noinclude tag breaks Proofread
under Internet Explorer
This was a on the wishlist for wikibooks and included a patch. I
committed it (http://mediawiki.org/wiki/Special:Code/MediaWiki/98422).
** https://bugzilla.wikimedia.org/12130 - Edit form eats heading CRs
(leading blank newlines/whitespace) on save/preview
This bug keeps popping up and, while there are work-arounds, the
behavior is non-intuitive. Mediawiki erases the first (and only the
first) blank like each time you click submit or preview. After
everyone in the triage meeting confirmed this, I showed the problem to
Krinkle who agreed that this should be fixed and left a comment with
an idea of how to fix it.
Next Triage: October 5th -- focus on Fund-raising issues http://hexm.de/81
Bug Triage calendar: http://hexm.de/TriageCal
--
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
mhershberger(a)wikimedia.org
717.271.1084