I was looking at pages on wiki and couldn't find where to submit
proposals for presentations or cons that would take place on Lyon's
hackathon, so I will post it here.
I don't know how many people who do or have done some antivandalism
(see [[w:WP:VAND|Vandalism]] for info) work in any way are going to be
at Lyon, but if there was at least a small group of people who would
be interested in following topics, it might do to set up some
mini-conference there where we could have some presentations and
The topics would be:
* Definitions of what kind of issues we are dealing with every day (eg
what is vandalism, how much does it actually affect wikipedia,
statistics and so on)
* Overview of current technologies and tactics used to deal with
vandalism on Wikipedia add sister sites
* Collaboration - how can we connect existing tools we have in order
to make them significantly more efficient
* Future of anti-vandalism: what challenges are there going to be?
What all can we do and improve?
* Presentations of various tools we already have: application based
and web based as well as fully automated tools (ClueBot and other
tools living on labs etc) how they work and what could be improved?
* Drinking? Oh yes! let's get drunk and use our vandalism knowledge to
blow up the wikipedia! :P
* Is there any vandalism on small 3rd sites and would there be any use
for a tool to deal with it?
* Effective dealing with spam and robots
Is there someone who would be interested in hacking / talking about
this? Is it worth of having some mini-con on this topic at Lyon this
I would like to announce the release of MediaWiki Language Extension
Bundle 2015.03. This bundle is compatible with MediaWiki 1.23.x and
MediaWiki 1.24.x releases.
Next MLEB is expected to be released in 3 months. We are trying less
frequent releases due to low number of changes per month in the
included extensions. If there are major changes or important bug
fixes, we will do intermediate release. Please give us your feedback
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2015.03.tar…
* sha256sum: 938444aecd01df92d340e69b0f1c341de7085269bf5e6bbb28b82f41e816cc6d
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
* Report bugs to: https://phabricator.wikimedia.org/
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel ==
* Improved compatibility by using UserGetReservedNames hook.
== CLDR and CleanChanges ==
* Localisation updates only.
== LocalisationUpdate ==
* A bug that prevented extension and skin i18n files to be updated is fixed now.
* Additional MediaWiki core i18n locations such as api messages are
also included now.
* Known issues:
** T93039: There is a known issue that prevents using
LocalisationUpdate if you have VisualEditor and are using the default
== Translate ==
* Improvements in the message group selector:
** T54703: Now shows correct list of groups in Special:SearchTranslations
** The group selector now always appears below the trigger that opens it.
* ttmserver-export.php has new option --reindex to update index
mappings. There are no changes to index mappings at this time though.
* Improved compatibility by using UserGetReservedNames hook.
* Various display improvements in right-to-left languages on
* Known issues:
** T94548: ULS language selector is not properly accessible when
opened within the translate group selector
== UniversalLanguageSelector ==
* Fixed issues related to the tooltip for ULS cog (trigger icon at the
sidebar interlanguage position):
** T52743: Consistent tooltip style.
** When changing language first time, instead of language code,
language autonym is shown.
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
This is a notice that on Tuesday, March 31st between 21:00-22:00 UTC (2-3pm
PDT) Wikimedia Foundation will release security updates for current and
supported branches of the MediaWiki software. Downloads and patches will be
available at that time.
I’m pleased to announce that Michael Holloway joins Wikimedia today as
a Software Engineer for the Mobile App Team. Michael is based in Ann
Arbor, Michigan, and will be working with us remotely. He'll join
Dmitry & Bernd to push our native Android development forward .
Michael has longstanding interests in the technical and social aspects
of information technology, and turned to software development
professionally after several years in the legal field. He believes
passionately in the revolutionary potential of free and open access to
information, and in Wikimedia’s vision of a world in which all can
share freely in the sum of human knowledge. Michael looks forward to
delighting users of the Android app, and to helping grow and diversify
Wikimedia’s user base.
When he’s not behind a keyboard, Michael spends his time bicycling,
cooking curries, and sampling craft brews.
Please welcome Michael!
 - https://play.google.com/store/apps/details?id=org.wikipedia
LiquidThreads (LQT) has not been well-supported in a long time. Flow
is in active development, and more real-world use-cases will help
focus attention on the higher-priority features that are needed. To
that end, LQT pages at mediawiki.org will start being converted to
Flow in the next couple of weeks.
There are about 1,600 existing LQT pages on Mediawiki, and the three
most active pages are VisualEditor/Feedback, Project:Support_desk, and
Help_talk:CirrusSearch. The Collaboration team has been running
test conversions of those three pages, and fixing issues that have
come up. Those fixes are almost complete, and the team will be ready
to start converting LQT threads to Flow topics soon. (If you’re
interested in the progress, check out phab:T90788 and linked
tasks.) The latest set is visible at a labs test server. See an
example topic comparison here: Flow vs LQT.)
The VisualEditor/Feedback page will be converted first (per James'
request), around the middle of next week. We’ll pause to assess any
high-priority changes required. After that, we will start converting
more pages. This process may take a couple of weeks to fully run.
The last page to be converted will be Project:Support_desk, as that is
the largest and most active LQT Board.
LQT Threads that are currently on your watchlist, will still be
watchlisted as Flow Topics. New Topics created at Flow Boards on your
watchlist will appear in your Echo notifications, and you can choose
whether or not to watchlist them.
The LQT namespaces will continue to exist. Links to posts/topics will
redirect appropriately, and the LQT history will remain available at
the original location, as well as being mirrored in the Flow history.
There’s a queue of new features in Flow that will be shipped over the
next month or so:
* Table of Contents is done
* Category support for Flow Header and Topics is done
* VE with editing toolbar coming last week of March (phab:T90763) 
* Editing other people’s comments coming last week of March (phab:T91086)
* Ability to change the width & side rail in progress, probably out in
* Search is in progress (no ETA yet) (phab:T76823)
* The ability to choose which Flow notifications end up in Echo,
watchlist, or both, and other more powerful options, will be coming up
next (no ETA yet)
That being said -- there are some LiquidThreads features that don’t
exist in Flow yet.
We’d like to hear which features you use on the current LQT boards,
and that you’re concerned about losing in the Flow conversion. At the
same time, we’d like further suggestions on how we could improve upon
that (or other) features from LQT.
Please give us feedback at
https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it
centralized, and test freely at the sandbox.
Much thanks, on behalf of the Collaboration Team,
 https://www.mediawiki.org/wiki/VisualEditor/Feedback and
 http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and
 http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and
 https://phabricator.wikimedia.org/T90763 ,
Nick Wilson (Quiddity)
The application deadline for GSoC and Outreachy has passed. We have
- 44 GSoC applications from 43 candidates
- 10 Outreachy applications from 10 candidates including 5 who have also
applied for GSoC
Several of the projects have received multiple proposals, making it hard
for out mentors to choose the best from all the applicants. Everyone is
invited to join in the selection process and actively ask the candidates
questions about their proposals.
The GSoC proposals submitted can be found at
The Outreachy proposals submitted can be found at
For our students:
If you have not yet created a task for your project proposal on Phabricator
yet, we encourage you to do that as soon as you can. If your proposal is
complete and you have completed one or more relevant microtasks, you can
sit back and relax now. If not, you should complete your application as
soon as possible.
For the mentors:
All mentors must join the GSoC/Outreachy review websites (
https://outreachy.gnome.org respectively) in order to privately evaluate
I want to take the opportunity to remind all our mentors that under no
circumstances are we allowed to reveal the results of the selection process
before April 27th 1900 UTC when the official list will be out on Melange.
Hence, no hints or resolutions must be given out on the Phabricator tasks
or on Melange.
Some resources for the mentors:
- Guidelines for possible mentors:
- Our selection process:
- Lessons learned from the previous rounds:
By April 13 we need to decide how many slots we want to request in both
programs. In GSoC we request a number of slots to Google which we might or
might not get. In Outreachy, we fund some slots, we might request more and
then we might or might not get them.
Questions? Just ask.
Earlier this morning, we made some good progress towards a faster
VisualEditor experience by loading the HTML from https://rest.wikimedia.org/,
the REST content API that entered beta production a bit over a week ago
. Preliminary data shows a drop of mean client HTML load times by close
to 40% from about 1.9 seconds to 1.2 seconds.
The reasons for this speed-up are primarily
a reduction in HTML size by 30-40%, achieved by storing page metadata
separately in RESTBase , and
storing (rather than caching) the HTML of all Wikipedia articles, thus
eliminating expensive cache misses.
So far we have enabled this optimization on all Wikipedias. Other projects
with VisualEditor support will follow over the next week. There are also a
lot more optimizations in the pipeline. Eventually, we hope to completely
eliminate the need to re-load the page for editing by using the same
Parsoid-generated HTML for regular page views.
While many people helped to make RESTBase and the content API a reality
(see the original announcement ), I want to specially call out Marko
Obrovac for doing much of the integration work with MediaWiki and the
I hope that you enjoy the newly faster VisualEditor experience as much as
Principal Software Engineer, Wikimedia Foundation