I was asked by a volunteer for help getting stats on the gender gap in
content on a certain Wikipedia, and came up with simple Wikidata Query
Service queries that pulled the total number of articles on a given
Wikipedia about men and about women, to calculate *the proportion of
articles about women out of all articles about humans*.
Then I was curious about how that wiki compared to other wikis, so I ran
the queries on a bunch of languages, and gathered the results into a table,
(please see the *caveat* there.)
I don't have time to fully write-up everything I find interesting in those
results, but I will quickly point out the following:
1. The Nepali statistic is simply astonishing! There must be a story
there. I'm keen on learning more about this, if anyone can shed light.
2. Evidently, ~13%-17% seems like a robust average of the proportion of
articles about women among all biographies.
3. among the top 10 largest wikis, Japanese is the least imbalanced. Good
job, Japanese Wikipedians! I wonder if you have a good sense of what
drives this relatively better balance. (my instinctive guess is pop culture
4. among the top 10 largest wikis, Russian is the most imbalanced.
5. I intend to re-generate these stats every two months or so, to
eventually have some sense of trends and changes.
6. Your efforts, particularly on small-to-medium wikis, can really make a
dent in these numbers! For example, it seems I am personally
responsible for almost 1% of the coverage of women on Hebrew Wikipedia!
7. I encourage you to share these numbers with your communities. Perhaps
you'd like to overtake the wiki just above yours? :)
8. I'm happy to add additional languages to the table, by request. Or you
can do it yourself, too. :)
 Yay #100wikidays :) https://meta.wikimedia.org/wiki/100wikidays
Wikimedia Foundation <http://www.wikimediafoundation.org>
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us make it a reality!
Being put together by Eliezer Yudkowsky of LessWrong. Content is
cc-by-sa 3.0, don't know about the software.
Rather than the "encyclopedia" approach, it tries to be more
pedagogical, teaching the reader at their level.
Analysis from a sometime Yudkowsky critic on Tumblr:
(there's a pile more comments linked from the notes on that post,
mostly from quasi-fans; I have an acerbic comment in there, but you
should look at the site yourself first.)
No idea if this will go anywhere, but might be of interest; new
approaches generally are. They started in December, first publicised
it a week ago and have been scaling up. First day it collapsed due to
load from a Facebook post announcement ... so maybe hold off before
announcing it everywhere :-)
(this is an announcement in my capacity as a volunteer.)
Inspired by a lightning talk at the recent CEE Meeting by our colleague
Lars Aronsson, I made a little command-line tool to automate batch
recording of pronunciations of words by native speakers, for uploading to
Commons and integration into Wiktionary etc. It is called *pronuncify*, is
written in Ruby and uses the sox(1) tool, and should work on any modern
Linux (and possibly OS X) machine. It is available here, with
I was then asked about a Windows version, and agreed to attempt one. This
version is called *pronuncify.net <http://pronuncify.net>*, and is a .NET
gooey GUI version of the same tool, with slightly different functions. It
is available here, with instructions.
Both tools require word-list files in plaintext, with one word (or phrase)
per line. Both tools name the files according to the standard established
in [[commons:Category:Pronunciation]], and convert them to Ogg Vorbis for
you, so they are ready to upload.
In the future, I may add OAuth-based direct uploading to Commons. If you
run into difficulties, please file issues on GitHub, for the appropriate
tool. Feedback is welcome.
Hi, how about a wikipedia about objects?
Instead of generic articles of , for example, "Ballpoint pen" or "Bic
cristal" it would be "Ballpoint pen Bic cristal 2014"
Doing these for millions of objects would allow people to have an open,
free, universal and central place to refer specific objects.
*Some possible applications:*
- Creating neutral and standard lists:
Nowadays if anyone create, for example, a tutorial for building
something (DIY projects, receipts, ...) they have to link all items to a
comercial or no-neutral web which could change its url in the future or
redirect it to adds or whatever.
Lists could be created in external webpages linking wikimedia objects
webpage or/and could be created as category pages in Wikipedia. For
example, currently, https://en.wikipedia.org/wiki/Car_of_the_Year
article lists cars which won COTY award but not links to the specific car
(AUDI A3 Hatchback 2012 - Present) but generic serie (Audi A3).
The good thing at this point it's that to start creating object
lists only item name is necessary, no infoboxes or description needed.
- Universal repository for inventories:
Lot of business fill their inventories again and again with same data
("cardboard box 50x30x15", "step by step nema motor 17", ... ) they should
be able to import this data from a open website with their corresponding
info like GTIN , SKU , Barcode... and more in the future weight, size,
- Encourage Recycling and Reutilitation:
Imagine if we use wikidata properties (
"has part" and "part of" , people will find other uses for objects, or
discover were to find
- Social activism and Corporate Social Responsibility (CSR)
Companies have info and metrics about their costumers (habits, location,
...) why not costumers have info about companies products, who manufacture
what?, what products have a good carbon footprint
<https://en.wikipedia.org/wiki/Carbon_footprint>?, what products have
been retired from some problem?, what are Fair Trade?. This also can moved
companies do better.
*Very rough roadmap*:
1. At the very begining, using wikidata infrestructure, objects would
only have common info like "name", " image", "related links"
First use cases could be doing lists or grouping objects by categories.
2. Step by step new fields could be added like "manufacturer" , "tags",
3. A separated website could be created. wikiobject.org isn't availiabe
so url could be something like objects.wikpedia.org
4. In a long-term in order to explote all the possibilities of this
project more complex fields and relations would have to be managed, like
for example "fridges with energy class A+++ and width less than 80 cm",
which could be easy if all always were similar but nothing further from
A friend of mine and me tried to build a demo version in an home-made
apache cassandra cluster four years ago, but we don't have enough resources
and knowledge for that.
In my humble opinion, problem with wikipedia funding It's that most part of
its users don't see culture as a need (sorry for that, I am a sporadic
donor). In Wikiobject case I think it could rather be different.
If part of companies business lies on this project, companies will be very
inclined to donate to improve performace, usability, etc.. maybe similar to
what happens in Linux.
Where came this need from? Data needed for some software to run, product
vissibility, costumer requests, etc ... , no advertisement needed, It could
be a need and standart.
I trully believe that world need something like this, and the correct
people to do it, to warranty openness and independence, are you.
thanks for your time and attention,
TL;DR: The Editing Department is working to make the content editing
software better. The big work areas are improving the visual editor and
editing wikitext. We will bring in a wikitext mode inside the visual editor
for simpler, faster switching. We will experiment with prompts to give
users ideas for what they might want to make as they edit. We will do other
things as well. Your feedback is welcome.
I thought it would be helpful to send an update about editing software.
It's been over a year since my last, and things change (and it's easy to
lose track). We set out some higher-level objectives for Editing in the
Wikimedia Foundation's annual plan for the coming financial year. This
gives a little more detail on that, with particular emphasis on the team
working on content editing tools directly. There's also a brief, more
feature-focussed roadmap available on MediaWiki.org if you are
In Editing, we're continuing to work on our commission from the 2010
community strategy to create a rich visual editor which makes it
possible to edit all our content, and participate in our workflows, without
knowing or having to learn wikitext. This is a work in progress; as with
all our improvements to the software, we will never be "done", and
hopefully you notice improvements over time. Each week, new features,
improvements, and bug fixes are released, often led, altered or supported
by our volunteer developers and community pioneers; my thanks to you all.
We are now roughly five years into this visual editor work, and have made
good progress on a credible content editor for many users' workflows,
helping editors spend more time on what they're editing instead of how.
First and foremost, not having to think about the vagaries of wikitext and
instead focus on the content of their writing is something that many new
and experienced volunteers alike have mentioned they appreciate. The
automatic citations tool makes adding new references to websites or DOIs
much more quickly and thoroughly, improving the quality of the content. The
visual media searching tool makes it simple to find and add more of the
great images and other media on Commons and add to a page. Visual table
editing helps make changes to tables, like moving columns or parts of
tables around, much more easily than in wikitext, saving time of our
volunteers to focus on their work making the wikis better.
The visual editor supports many (but not yet all) of our content languages,
and thanks to community support and engagement the editor is available by
default on over 235 Wikipedias (and for opt-in use on the remaining 55),
including almost all of our largest Wikipedias. It is on by default for
logged-out users and new accounts on 233 of these, and on for new accounts
(but not yet for logged-out users) on two, English and Spanish. As of this
week, this now includes representatives from each of the "CJK" language
group, with four different Chinese script languages (Classical, Cantonese
and Wu, as well as Min Nan), Korean and Japanese. We're currently working
our way through each of the remaining communities asking them if it's OK to
switch; the next groups will be the thirteen Arabic script Wikipedias and
the twenty-three Indic Wikipedias. You can see specific details at the
rollout grid if you're interested.
We have recently been working with the non-Wikipedia sister projects. As
you might imagine, each project has different needs, workflows and
concerns, and it's important to us that we ensure the tools we provide are
tweaked as appropriate to support, not undermine, those requirements to the
extent justifiable by demand. Per community request, the visual editor is
already available to all users on several different sister projects, but we
think there is more to do for some before we encourage this more widely.
Recently, we have been working with the communities on the Wikivoyages,
which are quite similar to the Wikipedias in needs from the visual editor;
our thanks to the patience and assistance from the Wikivoyagers. We're also
working with User:tpt and other volunteers who create and maintain the
software used by Wikisources to adapt the visual editor to work with those
features; our thanks to them, and to Wikisourcerers more widely.
Core and maintenance work
Despite this progress, there are still several areas in which the core
functionality of the editing software needs extensions, improvements and
fixes. In many places within the visual editor software we have to work
around browsers' bugs, missing features and idiosyncrasies, and nowhere is
that more problematic than the critical areas of typing, cursoring, and
related language support. There continue to be irritating, occasionally
serious bugs related to these, for which we continue to partner with
browser vendors and experts around the Web to try to develop workarounds
Another important area related to language support is coming up with a
solution for the nine languages in the Wikimedia family which use content
language variants, biggest amongst them Chinese, which poses some very
large challenges as it is fundamentally incompatible with a visual editing
method. If you're interested in discussing how this might work we would
love to discuss with you what possible options you think would work out,
even more so if you wish to work on support for this.
The performance of the software is not yet as good as we would wish, in
terms of speed, network use, and load on users' browsers. This is a
usability issue for all users, but is especially critical for users of
lower-powered devices (like older machines) and more powerful but
limited-resource ones (like most mobile phones and tablets), where in some
cases it can be not merely awkward to use, which is disrespectful of
volunteers' time, but prohibitive, excluding community members from
volunteering their time. We have several strategies lined up to tackle this
basket of issues, from editing only small parts of a document at once –
sometimes called "sentence-level editing" – to loading smaller bits of the
editor at first and then larger, less-used bits as needed whilst retaining
a consistent interface without changes in interface which can be confusing
and distracting. More widely, working to let the software include as many
possible volunteers in the community if they wish to join also covers
accessibility in all its forms, making sure editors who have learning
impairments or physical disabilities are supported as much as possible.
Many of our communities have put in significant effort over the past
fifteen years to come up with specialised workflows on their wikis.
Sometimes these efforts have involved complicated extensions and gadgets,
like the use of the "inputbox" button to start a new article based on a
template, as used on several wikis. Others provide additional tools inside
the wikitext editor, like the English Wikipedia's tool to automatically
created references based on a link, some of which we provide inside the
visual editor now, but many of which are not yet there, and which we at the
Foundation can never scale to provide the individual attention for each of
our hundreds of wikis. For the visual editor to be successful, pleasant and
as un-confusing as possible, it is vital that we help communities provide
gadgets as appropriate, and duplicate or extend the integration with the
various other editors. We look forward to helping you help others.
A big technical change we're hoping to achieve this year, as we set out
directly in the annual plan, is to re-engineer how MediaWiki supports
content. We want to allow multiple "parts" of content, of different parts,
to be stored as revisions of pages. This is a much-needed feature already,
most obvious with file pages – each file's upload history is shown separate
from its description page, and videos' subtitles are stored in a different
namespace rather than shown on the page. This also is an issue in other
areas, making workflows more complicated, like the common documentation
sub-page of templates rather than having a combined template and
documentation page needing two edits to improve a template and document how
it now works. With Wikimedia Deutschland's work on moving Commons' file
meta-data into a proper structure linked to Wikidata, addressing this need
is now acute. We look forward to driving forward the technical discussion
and implementation of multi-part content revisions in the back-end, and
we have some hopes with how it can be used to do new things which we
Finally with regards to core work, our intent right from the beginning of
our work on the visual editor has been to operate as the core 'platform'
for all kinds of editing in MediaWiki, and not just to be another single
editor. Depending on how you count them, there are currently six pieces of
editor software beyond the visual editor installed on most of our wikis,
which gives us six different interfaces by which to confuse users, six
different sets of bugs to track down, and six different places where
features can interact in unexpected ways and which need to be tested.
Our goal is to gradually reduce the number of pieces of software with
equivalents based on the single platform. This has already been done for
example in Flow, where it uses the visual editor for rich content editing
rather than re-inventing its down, and we are planning to work with our
colleagues in the Language Engineering team to do the same for the Content
Translation tool. We are experimenting with providing a more modern
wikitext editor which can provide a consistent experience between the
visual and wikitext editors, and between desktop and mobile; there's a
video of our work to date on this, still incomplete, which some of you may
have seen. Naturally, any new wikitext editor would have to be not just
change for its own sake but better for users to be worth switching, so
we're cautious about how quickly we would introduce this; certainly, a beta
feature test of the initial version for the intrepid will be necessary
before we make any plans as to wider availability.
As well as our core work, it is important to us that we also spend some of
our time to explore ways in which new features can improve the experience
of the site for users, helping them improve quality, breadth and depth of
content more effectively and efficiently. Not all of the ideas below are
ones on which we're actively working right now, but we should have some
progress this coming year on at least most of them.
An idea I'm quite excited about in terms of possibilities is providing a
system in the visual and wikitext editors that can prompt users as they
edit. The range of different kinds of edit, from copy editing and improving
references to a full up re-working of whole sets of pages, means that
newbies can get lost in knowing where to start. There are lots of different
kinds of improvements that we could provide, from simple static ones like
"this article isn't illustrated yet" to very complex and specific ones like
"this article's main wikiproject is about the USA, so wants you to write in
American English". This work is aimed at reducing the burden on experienced
users when they review new editors' changes, letting each wiki configure
hints appropriate to that community. We also intend for these experiments
to improve the "on-boarding" experience for new users, helping them learn
what is wanted and valued by their wiki's community, and what makes for
more constructive edits.
Once we have multi-part content streams (which I mentioned above as core
work), there are several possible feature areas we think are worth
A big one is that we think that there's a lot of potential in storing edits
in HTML DOM as well as in wikitext. Firstly, this should allow us to help
MediaWiki understand changes in edits more like the way that humans do.
This would allow us to provide neat features like visual diffs and animated
histories of pages. Showing clearly who wrote which parts of an article, or
what parts of the article have been changed most recently, is not a new
idea but hasn't been practical to implement at scale. It would be
fascinating to see if this tool could assist in deepening the richness of
understanding for readers of the staleness or volatility of articles in
More importantly, it should allow much better automatic handling of edit
conflict situations, and so reduce the occurrence of edit conflicts that
need manual correction. Theoretically, it could let us remove edit
conflicts entirely, though this would mean making some decisions about how
edits work which we may decide are worse long-term than having manual
resolution of edit conflicts; we're not planning to make a decision on that
until we know more.
Storing pages in DOM could also allow smart partial document saving,
splitting up your bigger edits into different chunks, each of which you can
save as you go. Making smaller, simpler edits. This could also let us
reduce edit conflicts by prompting people to save bits as they edit, and
pushing those new versions "live" into the editor of others also editing at
the same time.
The final thing I'll mention that DOM edits could do is allow DOM-based
annotations to pages. With this, citations could be 'applied' to bits of
the article showing which statements are (and aren't) backed up with a
reference. Discussions could refer to a specific image, sentence or word
choice to let editors have deeper, faster conversations, and understand
when they're editing a potentially divisive section. Illustrations like
diagrams and maps could highlight an area.
Another thing we're keen to explore with content streams is improving how
page meta-data is edited, centralising the data about a page's name,
protection level, whether it should show a table of contents, what pages
redirect to it, and so on. Each of these examples is currently edited in a
different place and with a different tool. We think it could help a lot to
provide these controls together, editing a new "part" of the page alongside
the wikitext block. Note that we're not planning on removing the existing
mechanisms, which each work well enough – this would be an additional tool,
at least at first.
A final item worth mentioning, because it comes up a lot as a
technical/editor wishlist item from some editors and developers alike, is
real-time collaborative editing. I wrote some details a couple of years ago
about how this, especially the "full-throttle" collaboration system (like
Etherpad or Google Docs, where there can be multiple users at the same time
each with their own cursor) is a huge problem, not just a technical one but
critically a social one. Despite this, I do hear quite often from people
about how this would be very helpful, for mentoring new users and those
doing something with which they're unfamiliar, and for content editing
collaborating, like for edit-a-thons, breaking news articles where lots of
changes are wanted at the same time, and themed collaborations of the day
or similar. I'm keeping an open mind as to whether we will ever do this,
but it's not something we're worrying about right now.
As you can see if you have made it this far, there's a lot of different
things we're working on in the department. I'm hopeful that the
improvements we make have already made, and will continue to make, the
editing lives of those reading this a bit easier.
I'm thankful for all the support we get from across the communities, be it
in the form of clear suggestions, complaints and proposals, technical
advice and volunteering, or anything else. If you're technical, and a
current or prospective volunteer developer interested in working on some of
these areas, we would love to help you.
I'll be at Wikimania this year. As always, I'll be happy to talk about
anything in this update — or missing from it — in person there, online on
Phabricator or IRC, on-wiki, or wherever else. Your thoughts and responses
are what guide us, and what makes it worth doing. Hope this was interesting!
 — https://www.mediawiki.org/wiki/VisualEditor/Roadmap
which has been gradually developed into
https://www.mediawiki.org/wiki/Feature_map for possible Product work.
 — https://www.mediawiki.org/wiki/VisualEditor/Rollouts
 — https://phabricator.wikimedia.org/T107595
 — The plain wikitext editor (with the dark blue buttons toolbar),
WikiEditor (with the light blue/grey toolbar), CodeEditor (with the syntax
highlighting, based on WikiEditor), Flow's discussion editor, and
LiquidThreads's editor (mostly not seen now).
 — https://www.youtube.com/watch?v=jgd2ZHOZGBE
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
At Wikimania two wikipedians of the year were elected. The article for one
of them and the data at Wikidata are pathetic.
The article is a one liner stub. The Wikidata item had no statements and I
added the few that were minimally needed.
I find it incredible that we take no care of our own even when they are
PS I have not looked at any of the others and I would welcome it when they
get some proper attention.
Today WMF's Community Resources team is joined by Delphine Ménard as our
newly appointed Annual Plan Grants
<https://meta.wikimedia.org/wiki/Grants:APG> (APG) Program Officer. In that
role, Delphine will support both funding streams included in the Annual
Plan Grants program, including Simple Annual Plan Grants and the Funds
(FDC) full process APG, with her focus on the FDC. We are excited to have
her join our team.
Some of you may know Delphine as [[user:notafish]]. She's a longtime
Wikimedian who has played many roles in our movement. She was WMF's
Chapter's Coordinator many years ago, then a member of the Board of
Wikimedia Deutschland, and most recently, a member of the Funds
Dissemination Committee herself. Her wide array of experiences and roles
will serve her well as the new APG Program Officer.
In the weeks ahead, Delphine will be reaching out to the FDC-funded
organizations and will also be leading the Board's recruitment to fill four
open seats on the FDC. I know she is looking forward to working with all of
Whenever a serious problem raises and after years of hesitation I
finally realize that I have to speak about it publicly, I have a drive
to drink some rakija, feel good and forget all of the stress the new
issue would give to me.
But this is very important and we have to start talking about it.
This issue lasts for years. I was first approached with this problem
during the Wikimania in London. Because of my firm belief into the
random nature of the nature, I thought it would be solved randomly.
Of course my intuition was wrong. Two years later nothing has changed.
Serbia has 7 millions of inhabitants, India has 1.3 billion. In few
years India will have 2000 times more inhabitants of Serbia.
And when I see what a mess good people from the West  are making
in Serbia, multiply that number with 2000 and realize that I have a
number of Wikimedia friends from India, my anxiety freaks out.
We are not the worst, it's likely we are even the best, but we are
mostly doing the same things that has been proved to be plainly wrong.
Fortunately, it's just "mostly", not "completely", as we have the way
to see what is wrong.
The problem we have there is bigger than any inequality gap we have in
all OECD countries combined, as Wikimedia is doing poor job in solving
any problem for approximately 1.2 billion of humans.
I will start with with the simple fact that Hindi, the fourth language
by number of speakers  has Wikipedia at the 58th place by number of
articles . And, no, Hindi Wikipedia is not at all in the category
"smaller number of very good articles".
I will continue with my completely unscientific approximation that 1/7
of the world population has been constantly represented on Wikimanias
by 1/7 Wikimedians if we count genetics and 0 (zero) if we count
For those who didn't yet get it, if the upper classes of India consist
even 20% of population, we don't have any representation of 1 billion
I could continue here with the background of the issue, various
problems mentioned to me, frustration expressed to me, but I don't
think it's useful at all.
What I think it's most useful is to start fixing the problem *now*. I
want to hear Indian Wikimedians what they see as problems that should
be solved, how they think that they should be solved, as well as WMF
and other Wikimedia movement bodies to start tackling that problem.
This is the part of the bigger problem. All of us have similar
problems in our own societies. And I think everybody should follow the
resolution of this problem and think how to do the similar things in
their own capacities in their own societies. (Hint for American
Wikimedians: Trump supporters are your next target for positive