Following the recent outage, we've had a new series of complaints
about the lack of improvements in CX, especially related to
server-side activities like saving/publishing pages.
Now, I know the team is involved in a long-term effort to merge the
editor with the VE, but is there an end in sight for that effort? Can
I tell people who ask "look, 6 more months then we'll have a much
better translation tool"?
Is there a publicly available roadmap for this project and more
generally, for CX?
I'm working on the database schema for Multi-Content-Revisions (MCR)
<https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema> and I'd
like to get rid of the rev_sha1 field:
Maintaining revision hashes (the rev_sha1 field) is expensive, and becomes more
expensive with MCR. With multiple content objects per revision, we need to track
the hash for each slot, and then re-calculate the sha1 for each revision.
That's expensive especially in terms of bytes-per-database-row, which impacts
So, what do we need the rev_sha1 field for? As far as I know, nothing in core
uses it, and I'm not aware of any extension using it either. It seems to be used
primarily in offline analysis for detecting (manual) reverts by looking for
revisions with the same hash.
Is that reason enough for dragging all the hashes around the database with every
revision update? Or can we just compute the hashes on the fly for the offline
analysis? Computing hashes is slow since the content needs to be loaded first,
but it would only have to be done for pairs of revisions of the same page with
the same size, which should be a pretty good optimization.
Also, I believe Roan is currently looking for a better mechanism for tracking
all kinds of reverts directly.
So, can we drop rev_sha1?
Principal Platform Engineer
Gesellschaft zur Förderung Freien Wissens e.V.
It's that time of year again where the density of holidays increases and
at the same time our plans for fundraising also increase.
Per our usual practice we will be not doing deployments at various
points in the next few months. Here's the full outline:
Reminder for all on we did last year:
* No MW train the week of Thanksgiving (but SWAT deploys were open for
* No deploys (at all) the last two weeks of December. People were happy
* The first week of January was normal (minus Monday being Jan 2nd, our
observed New Year's Day holiday) deployment wise.
* The second week was weird due to Dev Summit/All Hands: No MediaWiki
train, only SWATs as needed on Mon/Tues/Wed. No SWATs/deploys during
I imagine we'll do similarly. In that case (looking at the calendar....)
* No MW train the week of Thanksgiving (Nov 20th), SWATs open for high
* No deploys weeks of Dec 18th and 25th (last two weeks)
* Normal week week of Jan 1st (minus no deploys that Monday)
* The Dev Summit and WMF All Hands is the week of January 22nd, so that
will be a "No Train but SWATs OK on Mon/Tues/Wed" week.
* The following week (week of January 29th) the Release Engineering team
will be on an offsite, so a week of "No Train, but SWATs and service
This is now on-wiki at:
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
MediaWiki core is upgrading its version of QUnit from 1.x to 2.x.
This means extensions or skins with QUnit tests must now be compatible
See https://phabricator.wikimedia.org/T170515 and
### Deprecated API
In 2014, QUnit started to overhaul its API, to be more robust and better
support async workflows. The most notable change was the removal of global
and static functions, in favour of more contextual methods.
The first part of this released in 1.15, and more was gradually introduced
in later releases. The vast majority of our codebases are already using the
new interfaces. In fact, the vast majority of our QUnit tests were written
after 2014 and never used the old interfaces in the first place.
For a short list of removed functions, see
If you find a QUnit Jenkins job for a MediaWiki extension or skin repo
starts failing, it is most likely due to this. Look for errors such as
"QUnit.start undefined", "test.callback is not a function",
"QUnit.asyncTest is undefined", and "QUnit.push is undefined",
There are also some methods that have been deprecated over the past few
years. These still work in QUnit 2. Please take a moment to familiarise
yourself with the renamed methods and new methods. Doing so will avoid
confusion when reading new code that uses them.
### New features
The 'setup' and 'teardown' module hooks are now called 'beforeEach' and
'afterEach'. The old names still work, but the new names clarify that these
hooks are run for each QUnit.test().
QUnit 2.0 also adds new 'before' and 'after' hooks, which run only once per
module. This is somewhat analogous to use of setUpBeforeClass() in PHPUnit.
Since QUnit 1.16, QUnit.test() supports returning a Promise from the test
callback. This automatically attaches an assert.async() handler and waits
for the promise to complete. It also asserts that the Promise will be
resolved, and fails the test if rejected. This helps avoid a common pitfal
where a test could timeout when forgetting to attach a promise.fail()
The copy used for command-line usage (grunt-karma) and Jenkins will be
upgraded by https://gerrit.wikimedia.org/r/367838
SUMMARY: The Search Platform team (formerly part of Discovery) is planning
to fix a long-standing search bug on many wiki projects by disabling the
code in CirrusSearch that re-uses the “fallback” languages (which are
specified for user interface or system messages) for the language analysis
modules (which are used to index words in search). Deployment is planned to
start the week of October 9, 2017.
Messaging fallbacks specify what language to show a message in when there
is no message available in the language of a given wiki. A language
analysis module is language-specific software that processes text to
improve searching—so that, for example, searching for a given word will
find related forms of that word, like "hope, hopes, hoping, hoped" or
"resume, resumé, résumé" on English-language wikis.
Fallback languages for system messages make sense for historical and
cultural reasons—a reader of the Chechen Wikipedia is more likely to
understand a user interface or system message in Russian than in French,
Greek, Hindi, Italian, or Japanese—but the fallbacks don't necessarily make
any linguistic sense. Chechen and Russian, for example, are from unrelated
language families; while the languages have undoubtedly influenced one
another, their grammars are completed different.
We will deploy the software change that disables using messaging fallbacks
for language analysis fallbacks in about two weeks (targeting the week of
October 9, 2017), with any cross-language analysis exceptions explicitly
configured in a new manner. Changes will not immediately happen to all
affected wikis because each wiki in each language will need to be
re-indexed, which is a separate process that takes time. There may also be
other delays caused by Elasticsearch upgrades or other changes that need
You can also track progress of the tasks on Phabricator or read more,
see examples, and get the full list of languages affected on MediaWiki.
Sr. Software Engineer, Search Platform
Well, it's nothing functionally important, but I was wondering what the
"p" initial was for, as it's used everywhere as the returned value by
modules. I recall I already asked that somewhere, but I can't remember
if I was a replied a significant answer, sorry.
According to lua wiki
<http://lua-users.org/wiki/LuaLocales%20In%20Lua%205.1>, in Lua 5.1
"identifiers [are] locale dependent, and from the reference manual which
states that "[the documentation] derived from the Lua 5.1 reference
manual <http://www.lua.org/manual/5.1/index.html>", I guess tha
Scribunto is still derived form Lua 5.1.
So, what I would like is being able to set the locale for a module and
use identifiers with locale characters. But `os.setlocale` isn't
accessible in scribunto modules.
Might I have some information about reasons to disabling it and feedback
related to the possibility to enable it?