The XML database dumps are missing all through May, apparently
because of a memory leak that is being worked on, as described
here,
https://phabricator.wikimedia.org/T98585
However, that information doesn't reach the person who wants to
download a fresh dump and looks here,
http://dumps.wikimedia.org/backup-index.html
I think it should be possible to make a regular schedule for
when these dumps should be produced, e.g. once each month or
once every second month, and treat any delay as a bug. The
process to produce them has been halted by errors many times
in the past, and even when it runs as intended the interval
is unpredictable. Now when there is a bug, all dumps are
halted, i.e. much delayed. For a user of the dumps, this is
extremely frustrating. With proper release management, it
should be possible to run the old version of the process
until the new version has been tested, first on some smaller
wikis, and gradually on the larger ones.
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
This drag and drop from a CSV and other mentions of VE neatness would make a great blog post. I would love see a post about being productive in VisualEditor. Tips and tricks as it were.
-Chris K.
This electronic mail and any attached documents are intended solely for the named addressee(s) and contain confidential information. If you are not an addressee, or responsible for delivering this email to an addressee, you have received this email in error and are notified that reading, copying, or disclosing this email is prohibited. If you received this email in error, immediately reply to the sender and delete the message completely from your computer system.
Hi, I'd like to present a new RFC for your consideration:
https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript
delivered to users.
Your comments are highly welcome!:)
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hello, wikitech-l,
tl;dr trying to make mw-core pass mw-codesniffer, expect large patches on
Gerrit, and please help
A lot of work has been done on MediaWiki codesniffer
<https://phabricator.wikimedia.org/tag/mediawiki-codesniffer/> (the
PHP_CodeSniffer standard for MediaWiki) over the last few months and this
might be a good time to get core to pass our coding conventions
<https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP>.
Work on this has already started at T102609
<https://phabricator.wikimedia.org/T102609>. There were two primary reasons
to send this email:
1. This is a pretty big task and any help would be very welcome! If we can
get phpcs to run against core's master, it would make every patch
contributors' work a little easier.
2. Work is being organized as subtasks of T102609, and has been divided on
the basis of sniffs. Because of this, every patch is going to change a lot
of unrelated files and a lot of reviewers are going to get added on Gerrit.
Let's make this happen!
Vivek Ghaisas (polybuildr)
In the next RFC meeting, we will discuss the following RFC:
* Improving extension management
<https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_man…>
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 23:00
* Australia AEST: Thursday 07:00
-- Tim Starling
There's a pretty hilarious American police procedural TV show in 2015
called "CSI: Cyber", featuring mostly cybercrime. Obviously they have to
dredge up snippets of code from places for screenshots on the show.
Episode 4 happened to include a tidbit from MediaWiki 1.25/wmf3. Supposedly
the code was a hack to make your printer blow up.
Original lulz and screenshots via
http://moviecode.tumblr.com/post/114815574587/this-is-from-csi-cyber-s01e04…
When api.php was basically the only API in MediaWiki, calling it "the API"
worked well. But now we've got a Parsoid API, Gabriel's work on a REST
content API, Gabriel's work on an internal storage API, and more on the
way. So just saying "the API" is getting confusing.
So let's bikeshed a reasonably short name for it that isn't something awful
like "the api.php API". I'm horrible at naming.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
As part of the on-going UI standardisation work[0], we have just merged
into MediaWiki master a patch that will allow users of HTMLForm[1] to
easily switch over to use OOUI[2]. This allows you to make your code use
the standard UI styling and components with very little effort, improving
consistency and accessibility.
To convert your code over from the existing styling of MediaWiki's HTMLForm
(or its VForm version), you can replace the instantiation command of
- $form = new HTMLForm( … );
- or:
- $form = HTMLForm::factory( 'vform', … );
-
with
- $form = HTMLForm::factory( 'ooui', … );
… and everything Should Just Work™.
This doesn't break anything for existing use of this code, and you can
explicitly retain the existing styling by using $form = HTMLForm::factory(
'table', … ); or 'div' or 'vform' instead if you wish. Feel free to add
your code to the epic task on Phabricator which is the central liaison
point for this work[3].
Finally, please be careful to check your interfaces after converting them –
although we have tested this and believe it works well, there may be some
edge cases where it doesn't quite work. We're still missing a few features
[4] (such as prettier radio buttons), which we're hoping to have ready in a
week or two. If do you find any such issues, please report them so we can
fix them. Also note that OOUI already implements the new "MediaWiki" theme
for all users, so please ensure you advertise the visual changes as they
roll out to minimise disruption.
[0] - https://phabricator.wikimedia.org/T49145
[1] - https://www.mediawiki.org/wiki/HTMLForm
[2] - https://phabricator.wikimedia.org/T85291
[3] - https://phabricator.wikimedia.org/T100270
[4] - https://phabricator.wikimedia.org/T100279
Yours,
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
Hello,
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
Pygments.
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
code.
The wikitext syntax for highlighting code will remain the same.
-- Ori