https://blog.wikimedia.org/2012/09/25/page-curation-launch/
Please check this out -- there's a video tour, a tutorial, and more --
and ask your wiki communities for their thoughts.
"Every day, thousands of new pages are created on Wikipedia, requiring
hundreds of volunteer editors to check them for quality -- a process
called 'New Page Patrol.' To help these patrollers do their important
work, we are pleased to announce the launch of Page Curation, a new
suite of tools for reviewing articles on Wikipedia.
Current page patrol tools like Special:NewPages and Twinkle can be hard
to use quickly and accurately, and have led to frustration for some
users. Page Curation aims to improve that page patrol experience by
making it faster and easier to review new pages, using two integrated tools:
the New Pages Feed
the Curation Toolbar
...."
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Forwarded as this is of potentially wider interest. This may be a
breaking change for some older bots that haven't been maintained.
---------- Forwarded message ----------
From: Sam Reed <reedy(a)wikimedia.org>
Date: Wed, Sep 5, 2012 at 3:06 PM
Subject: [Wikitech-l] HTML5, it's a coming (again)!
To: wikitech-l(a)lists.wikimedia.org
It's been a long time coming (for the nth time..), but we're scheduling a
deployment of HTML5 across the Wikimedia cluster [1]. This is set for Monday
17th September at 18:00-20:00 UTC [2].
The intention is to set $wgHtml5 [3] to true everywhere. It's been running
on MediaWiki.org and our 2 test wikis for quite a while, and other sites
like translatewiki.net with no issues.
The intention is to leave it enabled unless it causes major problems. If
you're running an application that screen scrapes, shame on you; you've had
enough notice to get it fixed! ;)
Now is the time to fix up your scripts and programs (where necessary), tell
your friends!
Sam
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
[2] http://wikitech.wikimedia.org/view/Software_deployments#Week_of_Sept_17
[3] https://www.mediawiki.org/wiki/Manual:$wgHtml5
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
---------- Forwarded message ----------
From: Tim Starling <tstarling(a)wikimedia.org>
Date: Fri, Sep 21, 2012 at 4:07 AM
Subject: [Wikitech-l] #switch limits
To: wikitech-l(a)lists.wikimedia.org
Over the last week, we have noticed very heavy apache memory usage on
the main Wikimedia cluster. In some cases, high memory usage resulted
in heavy swapping and site-wide performance issues.
After some analysis, we've identified the main cause of this high
memory usage to be geographical data ("données") templates on the
French Wikipedia, and to a lesser extent, the same data templates
copied to other wikis for use on articles about places in Europe.
Here is an example of a problematic template:
<https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Donn%C3%A9es_PyrF1-2…>
That template alone uses 47MB for 37000 #switch cases, and one article
used about 15 similarly sized templates.
The simplest solution to this problem is for the few Wikipedians
involved to stop doing what they are doing, and to remove the template
invocations which have already been introduced. Antoine Musso has
raised the issue on the French Wikipedia's "Bistro" and some of the
worst cases have already been fixed.
To protect site stability, I've introduced a new preprocessor
complexity limit called the "preprocessor generated node count", which
is incremented by about 6 for each #switch case. When the limit is
exceeded, an exception is thrown, preventing the page from being saved
or viewed.
The limit is currently 4 million (~667,000 #switch cases), and it will
soon be reduced to 1.5 million (~250,000 #switch cases). That's a
compromise which allows most of the existing geographical pages to
keep working, but still allows a memory usage of about 230MB.
At some point, we would like to patch PHP upstream to cause memory for
DOM XML trees to be allocated from the PHP request pool, instead of
with malloc(). But to deploy that, we would need to reduce the limit
to the point where the template DOM cache can easily fit in the PHP
memory limit of 128MB.
In the short term, we will be working with the template editors to
ensure that all articles can be viewed with a limit of 1.5 million.
That's not a very viable solution in the long term, so I'd also like
to introduce save-time warnings and tracking categories for pages
which use more than, say, 50% of the limit, to encourage authors to
fix articles without being directly prompted by WMF staff members.
At some point in the future, you may be able to put this kind of
geographical data in Wikidata. Please, template authors, wait
patiently, don't implement your own version of Wikidata using wikitext
templates.
-- Tim Starling
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
All,
This fortnight's update for VisualEditor[0] - I'm skipping the one
for Parsoid based on your feedback, but it is available here[1]:
The VisualEditor was updated as part of the wider MediaWiki 1.20wmf12
branch deployment[2] on Monday 17 September.
The last two weeks included the annual Wikimedia Engineering all-tech
meeting and the Wikimedia Foundation all-staff meeting, so this
iteration was in effect shorter than others. The team have continued
to spend most of the coding time over the two weeks since 1.20wmf11
working on how the code integrates together. This work will provide
cleaner interfaces between components of the VisualEditor, so new
developers can re-use and extend VisualEditor to support new 'node
types' like categories or tables when we work on these later.
Beyond the API work, there have been a few minor changes to the user
interface made this iteration. Firstly, the link inspector now checks
for invalid titles like "Foo{}bar" (bug 33094 [3]), and long titles in
the suggestions box are replaced with ellipses in the middle rather
than the end so they can be distinguished (bug 39591[4]). The save
dialog's length down-counter has been labelled to indicate it counts
the number of bytes rather than characters, as that is what the
database holds (bug 40035[5]); longer-term, we may wish to find a
better way to show this to users. Finally, we fixed a bug where the
table of contents was restored wrongly if a user edited and then
cancelled without saving (bug 39753[6]).
A complete list of individual code commits is available in the
1.20/wmf12 changelog[7], and all Bugzilla bugs closed in this period
on Bugzilla's list[8].
[0] - https://www.mediawiki.org/wiki/VisualEditor/status#2012-09-17_.28MW_1.20wmf…
[1] - https://www.mediawiki.org/wiki/Parsoid/status#2012-09-17
[2] - https://www.mediawiki.org/wiki/MediaWiki_1.20/wmf12
[3] - https://bugzilla.wikimedia.org/show_bug.cgi?id=33094
[4] - https://bugzilla.wikimedia.org/show_bug.cgi?id=39591
[5] - https://bugzilla.wikimedia.org/show_bug.cgi?id=40035
[6] - https://bugzilla.wikimedia.org/show_bug.cgi?id=39753
[7] - https://www.mediawiki.org/wiki/MediaWiki_1.20/wmf12#VisualEditor
[8] - https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&bug_status…
Yours,
--
James D. Forrester
Product Manager for Visual Editor and Flagged Revisions
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester | +1 415-839-6885 x6844
Hi everyone,
We've reverted MediaWiki from 1.20wmf11 to 1.20wmf10 in order to fix a
problem with watchlists failing:
https://bugzilla.wikimedia.org/show_bug.cgi?id=40103
The root cause of this problem is a compatibility issue with jQuery
1.7.2. We can't yet cleanly upgrade to jQuery 1.8. There are pending
changes that might make this possible.
We may also try reverting all wikis to 1.20wmf10, and then moving
forward with 1.20wmf12 on Monday. Still all TBD.
Rob
Forwarding from wikitech-l.
-------- Original Message --------
Subject: [Wikitech-l] HTML5, it's a coming (again)!
Date: Wed, 5 Sep 2012 23:06:15 +0100
From: Sam Reed <reedy(a)wikimedia.org>
Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
To: <wikitech-l(a)lists.wikimedia.org>
It's been a long time coming (for the nth time..), but we're scheduling a
deployment of HTML5 across the Wikimedia cluster [1]. This is set for Monday
17th September at 18:00-20:00 UTC [2].
The intention is to set $wgHtml5 [3] to true everywhere. It's been running
on MediaWiki.org and our 2 test wikis for quite a while, and other sites
like translatewiki.net with no issues.
The intention is to leave it enabled unless it causes major problems. If
you're running an application that screen scrapes, shame on you; you've had
enough notice to get it fixed! ;)
Now is the time to fix up your scripts and programs (where necessary), tell
your friends!
Sam
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
[2] http://wikitech.wikimedia.org/view/Software_deployments#Week_of_Sept_17
[3] https://www.mediawiki.org/wiki/Manual:$wgHtml5
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l