I've written a simple MediaWiki extension that uses an instance of the
W3C Validator service (via the Services_W3C_HTMLValidator
<http://pear.php.net/package/Services_W3C_HTMLValidator> PEAR package)
to validate SVG images hosted on a wiki. It is meant to replace the
current system on Commons, that relies on individual contributors adding
templates (e.g. InvalidSVG
<https://commons.wikimedia.org/wiki/Template:InvalidSVG>) by hand to
file description pages.
It exposes a simple API (and a Scribunto module as well) to get the
validation status of existing SVG files, can emit warnings when trying
to upload invalid ones, and is well integrated with MediaWiki's native
ObjectCache mechanism.
I'm in the process of publishing the code, but have some questions I
think the community could help me answer.
* Given that the W3C Validator can also parse HTML files, would it be
useful to validate wiki pages as well? Even if sometimes the
validation errors appear to be caused by MediaWiki itself, they can
also depend on malformed templates.
* Does storing the validation status of old revisions of images
(and/or articles) make sense?
* Do you think the extension should use the extmetadata property of
ApiQueryImageInfo instead of a its own module?
* Is it advisable to store validation data permanently in the database?
Thanks to some hard and awesome work by This, that and the other (a.k.a
TTO), the long-requested feature of allowing users to add and remove change
tags (see T20670 <https://phabricator.wikimedia.org/T20670>) has been
merged and should be rolled out with 1.26wmf3.[1]
Tags defined by MediaWiki or extensions, such as "HHVM", "visualeditor", or
"mobile edit", cannot be added or removed by this feature. Only tags
specifically activated for the purpose may be added, and only those tags or
tags that are unknown to MediaWiki beyond being on some existing revisions
may be removed.
Management of such tags is already available to users with the
'managechangetags' right (admins by default) via Special:Tags.
Tagging and untagging of individual revisions and log entries will come
with 1.26wmf3. Tags may be applied by users with the 'applychangetags'
right when making an edit,[2] and existing revisions and log entries may be
tagged and untagged by users with the 'changetags' right via an interface
much like that for revision deletion. Both of these rights are granted to
all logged-in users by default.
If the default assignment of these rights is a concern for the community of
any WMF-hosted wiki, please follow the procedure at
https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes to
request the necessary configuration change.
For API users, the relevant modules include action=managetags, action=tag,
and action=query&list=tags.[3]
[1]: See https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the
schedule
[2]: By default there is no UI provided on the edit screen, but gadgets
may add a 'wpChangeTags' field with a comma-separated list of tags. API
users may use the new 'tags' parameter to action=edit.
[3]: See
http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=manageta…
for help, and post questions to mediawiki-api
<https://lists.wikimedia.org/mailman/listinfo/mediawiki-api>.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
T35235 <https://phabricator.wikimedia.org/T35235> has been around since
2011, and it's now fixed with the merge of Gerrit change 183315
<https://gerrit.wikimedia.org/r/#/c/183315/>. For the effects this will
have for bots and other API clients, see the announcement on
mediawiki-api-announce
<https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-April/000…>
.
For developers, this means that it's much easier to provide formatting for
your log entry parameters: it's now *possible* for extensions, and no
longer hard-coded in ApiQueryLogEvents for core.
If anyone is looking at updating existing log entries or creating new ones
for improved parameter formatting, you should be able to get the general
idea from the core formatters I did in that Gerrit change. But don't
hesitate to ask me for help if necessary, and please do add me as a
reviewer on relevant changesets.
Thanks!
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
I am writing to invite you to preview and hopefully contribute to
Gather [1], a new MediaWiki extension that allows users to create,
share, and discover lists of articles. Gather is currently available
for all users of the mobile site who have opted in to beta. This
launch was primarily for the community to test it and to pardon the
pun... gather... some data. We would love for you to try it out and
share your feedback with us.
The best way to explain what Gather lists are is to contrast them with
existing facilities for grouping articles: categories and list
articles. Categories and list articles exist in subject namespaces,
and their goal is to provide navigational links for articles whose
subjects share some common, defining property. Gather lists have a
similar goal of facilitating content discovery but differ in that they
allow users the ability to group articles on the basis of any
criterion, whether this be overtly subjective and irreverent
("articles I enjoy"); curated on the basis of cultivated tastes and
informed opinions ("the most groundbreaking discoveries in
chemistry"); educational at a more localised level ("Pages that Mr
Robson's A-level chemistry students should read") or simply a
personal todo list ("articles i want to edit/read today").
The Gather lists you create are currently your own [A] and you decide
whether or not they are visible to others [B].
To see some example lists check out:
https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/23https://en.m.wikipedia.org/wiki/Special:Gather/by/Jdlrobson/35https://en.m.wikipedia.org/wiki/Special:Gather/by/Sonasonic/71
If you want to have a go at making your own lists you have two options
(both require a mediawiki account):
1) Opt in to mobile site beta:
https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto…
and then interact with the watchstar
2) Try it out on Vector [C]:
https://en.m.wikipedia.org/wiki/User:Jdlrobson/vector.js
To build this we have looked at the existing watchlist code, the
Collections extension, the multiple lists in core RFC and the many
feature requests around watchlist that span the lifetime of this
project. Apologies in advance for lack of documentation, sometimes
talking and back and forth over IRC/coffee is more productive then
writing extensive documentation, but I promise you the team has been
listening to all sorts of use cases.
As a result I think now we have the first essential building block -
the ability for a user to store and access a structured public or
private list.
We have APIs that will allow you to:
* create new lists that are private or public
* edit lists
* add and remove pages to those lists
* query lists
* moderators to hide troublesome lists
* manipulate the watchlist which has special handling to turn it into
a collection
Next up on the immediate roadmap for those that are interested:
* Fixing up API bugs, missing documentation
* Pagination was sorely missing from the first release. Code for that
has merged so that's coming soon.
* Polishing the existing user experience and working out how to port
that to desktop
* Improving on moderation tools
* The ability for multiple users to share and manage a list
* Combining the data inside a list with other data e.g. recent changes
to make multiple watchlists. I have a first version of this patch
ready for review [3] and working towards the goal of public/private
watchlists [4].
We have a long way to go and I guess this is the main reason I'm
writing this mail - I'm hoping to collect more help from across our
community.
If you are interested in helping feel free to reach out to me off list
on irc (user jdlrobson) or poke around Phabricator [5].
Thanks for the read!
Jon
[1] https://www.mediawiki.org/wiki/Extension:Gather
[2] http://en.wikipedia.beta.wmflabs.org/w/api.php?action=help&modules=editlist…
[3] https://gerrit.wikimedia.org/r/#/c/200181/
[4] https://phabricator.wikimedia.org/T9467
[5] https://phabricator.wikimedia.org/tag/gather/
[A] In the future we would love to support collaborative editing of
collections. Any one interested in helping?
[B] ... Although currently the UI only supports public lists... API
supports both. Help us build that out.
[C] Highly experimental - this is still a WIP and may have lots of
kinks. I would love a volunteer full time to help me with the desktop
experience. It should be noted that the Gather extension works on
desktop, but we've de-scoped the work there whilst UX standardisation
is ongoing and to limit the workload so we can actually get things
done quickly. There is currently a dependency on MobileFrontend for
convenience but we hope to drop that very soon
(https://phabricator.wikimedia.org/T94100).
[D] (albeit badly documented - patches welcomed!
I
am very pleased to welcome Neil P. Quinn as the latest member of the Editing
team <https://www.mediawiki.org/wiki/Editing>, as our product analyst
working alongside me.
I
n his own words:
I was born and raised in North Carolina—specifically the lovely, humid,
famous-for-NASCAR city of Concord
<https://en.wikipedia.org/wiki/Concord,_North_Carolina> (pronounced
*kon-KORD*, not *KON-kerd* like the place in New Hampshire, thank you very
much)—although my dad is originally from Cleveland and my mom from Gujarat
<https://en.wikipedia.org/wiki/Gujarat> by way of Chicago. I have one older
brother <http://davenquinn.com/>, who's putting me to shame by doing a PhD
in geology at Caltech, and two younger sisters who were adopted from India.
I went to college at Georgetown University
<https://en.wikipedia.org/wiki/Georgetown_University> in Washington, DC. I
originally studied Middle Eastern history, which took me to Jordan for an
eight-month study abroad program, but about halfway through, after I
decided that life in a think tank wasn't for me, I switched my major to
international economics. I spent some internships trying out marketing,
including one in a "boutique thought leadership consultancy" located half a
block from K Street
<https://en.wikipedia.org/wiki/K_Street_%28Washington,_D.C.%29>, where I
did things like help the United States Travel Association
<https://www.ustravel.org/> scheme to get people to travel more. I
eventually found my way to software product stuff, including an internship
at Appcelerator <https://en.wikipedia.org/wiki/Appcelerator>, which I have
to say I liked a lot better.
I graduated this past December. I'm a longtime Wikipedian
<https://en.wikipedia.org/wiki/User:Neil_P._Quinn>, so when I happened to
notice that the foundation was hiring, I made that the very first
application I sent out. The process did take 9 interviews and 70 days, but
it was worth the wait! I'm very excited to meet you all, and to hang out in
a place where I can talk about Wikimedia arcana without sounding like a
dork.
Obligatory listing of hobbies: biking, cooking, tennis, social science, and
foreign languages (I speak Spanish and Arabic; Gujarati
<https://en.wikipedia.org/wiki/Gujarati_language> is next up).
Please join me in welcoming Neil, who started on Monday.
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
James,
I just want to say a public "thank you" for VE saving my sanity by doing
something that I didn't know was possible. I was able to copy a table from
Word onto Meta using VisualEditor, and much to my surprise it mostly
worked. I must have tried at least five other ways to get one of Cascadia
Wikimedians' annual plan tables copied from Google Docs onto Meta, all with
poor results. While VisualEditor only copied part of the formatting into
MediaWiki, the results were far better than anything else I had tried for
the past few hours. So thank you very much for supporting this
copy-and-paste functionality with VisualEditor.
Pine
*This is an Encyclopedia* <https://www.wikipedia.org/>
*One gateway to the wide garden of knowledge, where lies The deep rock of
our past, in which we must delve The well of our future,The clear water we
must leave untainted for those who come after us,The fertile earth, in
which truth may grow in bright places, tended by many hands,And the broad
fall of sunshine, warming our first steps toward knowing how much we do not
know.*
*—Catherine Munro*
We had an RFC meeting today about an RFC
(https://www.mediawiki.org/wiki/Requests_for_comment/Watch_Categorylinks) regarding
watching categorization changes.
The original proposal was to use Echo. However, there were some
concerns regarding that, regarding performance and UX (this seems more
consistent with the watchlist's UX).
The decision at the end was to use the recentchanges table. There are
two many remaining design questions:
1. Should categorization changes (on pages using the template) due to a
template change be ignored? This would simplify implementation, but
limit the usefulness of the feature.
If template changes are reflected, there were some suggestions on
implementation.
One was to create a single bulk event when the template is edited. The
problem with this is the template can have different effects on
different pages using it.
So it would somehow need to keep track of the effects, and create an RC
entry (with the relevant info either in, or pointed to by, rc_params) at
the end of the template processing.
Gabriel Wicke suggested an alternate approach that might be easier:
Point from the RC entry to an ID, and keep updating the list of pages
affected by that categorization batch as it progresses. It could maybe
use the revid of the template/underlying page change as this ID.
2. Whether to allow watching only the category page (i.e. the
description of the category), or require watching both that and
categorization/decategorization together. If the latter, filtering
(e.g. "ignore categorization/decategorization" view) could be done on
the watchlist page.
The RFC will be updated.
Matt Flaschen
---------- Forwarded message ----------
From: Rachel Farrand <rfarrand(a)wikimedia.org>
Date: Mon, Apr 13, 2015 at 4:37 PM
Subject: 2016 European Hackathon: Looking for Proposals
To: chapters(a)wikimedia.ch, wikitech-l-request(a)lists.wikimedia.org
Hello!
Is your chapter interested in hosting the 2016 European Hackathon? We are
looking for proposals!
We have put together some information for potential hackathon organizers
here <https://www.mediawiki.org/wiki/Hackathons#Proposing_a_hackathon> and
some general information about hackathon objectives here
<https://www.mediawiki.org/wiki/Hackathons>.
This years Wikimedia Hackathon 2015
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2015> will be held in
Lyon, France in May. Ideally we will announce the host for 2016 in Lyon. If
multiple chapters are interested, we will work together to figure out the
the best solution.
If you are interested in hosting or have any questions about the process
you have a few options:
1) Create a Phabricator task and associate it with the
Engineering-Community project. Include as much information as possible from
the first step section of the proposing a hackathon
<https://www.mediawiki.org/wiki/Hackathons/Proposing_a_hackathon> wiki
page.
2) Email me at rfarrand(a)wikimedia.org with any questions or concerns
Looking forward to hearing from you!
Rachel Farrand
Events Coordinator
Engineering Community Team
Wikimedia Foundation
In the next RFC meeting, we would like to discuss the following RFC:
* Watch Categorylinks
<https://www.mediawiki.org/wiki/Requests_for_comment/Watch_Categorylinks>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 22:00
* Australia AEST: Thursday 07:00
-- Tim Starling