In the past it happened to me a few times that I opened bugs about
something wrong that happened on a Wikimedia site, and it was closed as
invalid because the issue was not in MediaWiki code, but in a local gadget,
style or template on that project.
The bugs were actually fixed, but I'd like to question the "invalid"
They were real bugs in real products. The fact that the software is not in
Gerrit doesn't mean that they don't affect the product de facto. Just for
the sake of example, if a bug in a local Gadget affects the Flow extension,
for example, I find it perfectly valid to add tag the Flow tag to it. Core
and extension developers should be curious about how what they developed
behaves in the wild.
I do wonder what other tags are there to add to such a bug? I'm going to
open one now.
(P.S. Yes, this raises an issue of whether non-Wikimedia sites should
count. I say - yes, and it shouldn't be limited unless it gets seriously
out of hand. But a URL with reproduction instructions must always be
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
“We're living in pieces,
I want to live in peace.” – T. Moore
it seems that failed jobs will never be executed again.
My extension creates jobs that talk with an external server via soap.
This connection might fail (e.g. server maintenance) which then means
that my job fails and needs to be reexecuted later.
On my wiki I am running $wgJobRunRate = 0, my extension job is in
$wgJobTypesExcludedFromDefaultQueue. To run my jobs I have a cronjob
with "php runJobs.php --maxjobs 10 --type CreateTicket". My job has
allowRetries() implemented with "return true".
From my observations the "job_token" and "job_token_timestamp" fields
in the job table are used as a LOCK so that no job gets executed twice.
The only problem is that these fields are never emptied, if the job
fails (return false), so that the job scheduler can reexecute them.
Is this intended behaviour or is this a bug? Does anyone have an idea
how to solve this issue?
Over the course of the next two days, a major update to the
SyntaxHighlight_GeSHi extension will be rolled out to Wikimedia wikis. The
change swaps geshi, the unmaintained PHP library which performs the lexical
analysis and output formatting of code, for another library, called
The roll-out will remove support for 31 languages while adding support for
several hundred languages not previously supported, including Dart, Rust,
Julia, APL, Mathematica, SNOBOL, Puppet, Dylan, Racket, Swift, and many
others. See <https://people.wikimedia.org/~ori/geshi_changes.txt> for a
full list. The languages that will lose support are mostly obscure, with
the notable exception of ALGOL68, Oz, and MMIX.
The change is expected to slightly improve the time it takes to load and
render all pages on all wikis (not just those that contain code blocks!),
at the cost of a slight penalty (about a tenth of a second) on the time it
takes to save edits which introduce or modify a block of highlighted code
to an article.
Lastly, the way the extension handles unfamiliar languages will change.
Previously, if the specified language was not supported by the extension,
instead of a code block, the extension would print an error message. From
now on, it will simply output a plain, unhighlighted block of monospaced
The wikitext syntax for highlighting code will remain the same.
As part of concluding SUL finalization, users who do not have a global
SUL account will no longer be able to login. They will receive an error
message indicating that their password is invalid.
This should affect practically nobody. There are a few unattached
accounts left (e.g. T98156) but those shouldn't cause issues.
If a user is complaining that they are unable to login, you can check
[[Special:CentralAuth/$username]] to see if their account is in fact
unattached. If that is the case, please file a bug in the
SUL-Finalization project and I'll take a look. We are also logging
denied logins, so I'll be checking that log over the next few days.
TL;DR, Whether you are an amateur or an expert coder, or if you are a
current or interested user of the WikiEduDashboard or of the Education
Extension,* please join us at a hackathon session at Wikimania on
Wednesday, 15 July in Workplace 2 - Don Genaro at 1pm. *
A long time ago in a galaxy far, far away, the Wikimedia Foundation
developed Extension:EducationProgram. It did what we needed it to do at the
time, which was to provide a tool that helps organize classes that want to
edit Wikipedia articles for course credit. Since its release, the extension
has been deployed to 18 Wikimedia projects: it's on 4 sister projects in 16
Recently, the Wiki Education Foundation , led by project manager Sage
Ross - User:Sage (Wiki Ed), User:Ragesoss - developed a Ruby on Rails app
called the WikiEduDashboard , which they will use beginning this fall
instead of the EducationProgram extension, for the university courses that
they support on English Wikipedia.
We believe it is possible to use their freely-licensed code to create a
clone of this dashboard that can be used for non-Wiki Ed education program
courses and other group editing activities on English Wikipedia and,
ultimately, on other Wikimedia projects and in other languages.
We are asking for community support for this project since this is outside
the scope of WMF's engineering team for this year. We see the need for a
global dashboard tool and would love to have your help building it!
We're planning some exciting improvements to the Wiki Education Dashboard,
see Phabricator  for the full list.
* Full i18n, including right-to-left support.
* Generalize the UI to work for any wiki project and not only
* Integration with the Gather extension, to render lists of articles
being written and reviewed.
* Integration with Campaigns, to track group membership and statistics.
* Improvements to the API to simplify some actions taken from the
* Potentially using Wikidata as the backend for storing information
about courses and editing projects.
We look forward to working together to build this powerful tool which will
support more education and outreach programs in the movement!
on behalf of the WMF's Education team, + Andrew Green, Adam Wight, Sage
Hello all together,
some time ago, WMF started to re-organize into a new structure to focus on
specific topics. Now, I think, the main tasks are done, so that I want to
bring a (for me, and I think and hope for some others, too) very important
topic back to the ToDo list: mobile editing.
In the past, the mobile web team (in which I mostly contributed, too)
maintained the mobile wikitext editor in a very basic state, and the
VisualEditor team maintained the VisualEditor for tablet users. Now, most
people of the former mobile web team moved to the new vertical
“Readership”, so I’m pretty sure, that the responsibility for all editing
stuff on mobile isn’t in this team anymore (reading ≠ editing), so I
think, that the new editing vertical maintains all the editing stuff,
including mobile editing. Now I have some questions around this topic:
1. I’m missing MobileFrontend in the list of maintained extensions on
https://www.mediawiki.org/wiki/Editing ? Are there plans to move all editing
features away from MobileFrontend, or is the editing code in MobileFrontend
unmaintained now? How volunteers are able to contribute to the right place?
What is the bigger image for editing code in mobile?
2. Is there a roadmap for the mobile VisualEditor? At the moment it’s
only available for tablet users (which makes contributing on smartphones a
bit hard, there is only a clean wikitext editor, see one of my next points).
I know task T93325, is that meant to enable mobile VE on smartphones,
too? What is the roadmap for it?
3. Are you planning to support a wikitext editor on mobile, too (Like
a light WikiEditor)? At the moment, the wikitext editor in mobile is very
very basic (basically without any feature). I submitted a change to
enable some rally basic features to it, which, technically seems to be
merge able, but no-one of editing reviews it, neither it’s possible for a
volunteer (me :)) to find out, if such a feature matches the global vision
for mobile editing.
4. And the last point (any maybe the most important one): Who is the
person (or the group of person) I can contact for mobile related editing
things? In the time of the former mobile web team I have known the persons I
can ping on irc, e-mail or via mailing lists, now I’m a bit confused, who
is responsible for mobile editing, it’s like a gray veil :)
It would be great to have these points answered :)
Have a nice weekend!
(Apologies for crossposting.)
We're pleased to announce the 2nd edition of the *VisualEditor Translathon*.
It is a translation rally, focused on interface messages and help pages
related to VisualEditor .
In order to participate, you need to *sign up on the Translathon page* .
The top 3 contributors will each win a Wikipedia t-shirt of their choice
from the Wikipedia store .
Translations made between *July 15th and July 19th* (CDT time zone )
If you are at Wikimania Mexico this year , you are also welcome to join
a related sprint during the hackathon in *Workplace 1 - Don Américo,
Thursday 16 July at 4pm (CDT)* at the conference venue, so you can meet
other fellow translators and get support if you need some .
Interface messages have the priority. You will need to create an account at
translatewiki.net in order to work on them, if you don't have one. *It is
recommended to create the account ASAP*, so that it can be confirmed in
You can also help translate documentation pages about VisualEditor on
mediawiki.org. You can use your Wikipedia account to work there.
You will find instructions, links and other details on the Translathon page
Thanks for your attention, and happy translating!
Elitre (WMF) and Trizek (WMF)
 https://store.wikimedia.org/ . You can choose between any short-sleeve
shirt, or other items for the same value.
 This means both new translations, and updates for messages in the
"Outdated" tab of the translation interface.
Did anybody ever try to collect statistics about frequent section titles in
For Wikipedia, for example, titles such as "Biography", "Early life",
"Bibliography", "External links", "References", "History", etc., appear in
a lot of articles, and their counterparts appear in a lot of languages.
There are probably similar things in Wikivoyage, Wiktionary and possibly
Did anybody ever try to collect statistics of the most frequent section
titles in each language and project?
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
“We're living in pieces,
I want to live in peace.” – T. Moore
We have an existing wiki using MW 1.23. We are working on a build script to
generate a wiki using MW 1.25. Eventually the script will also automate the
database import and update, but for now I'm still learning the steps.
I built a VM with 1.25 and VE using some scripts that we are building.
VE seemed to be happily working. Then I imported our 1.23 SQL database and
files (/images). I ran update.php and runJobs.php. Now it seems VE hangs at
about the 75% point of the blue "progress bar" after clicking "Edit". Note
that I am still able to edit source.
I know this is not enough to get a full answer, but I'm hoping you can help
me find some more resources to try. For example, are there any significant
changes between the REL1_25 branch of Parsoid and HEAD? I see the branch on
Gerrit, but I couldn't see that branch in git for a checkout.