February 2015 - Wikitech-l - lists.wikimedia.org

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 28 Jun '24

28 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

New RFC: better JS minification
by Max Semenik 01 Nov '15

01 Nov '15

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]])

9 12

Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 11 Aug '15

11 Aug '15

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

30 38

Re: [Wikitech-l] Bug in the Wikipedia main web page
by Sukyoung Ryu 25 May '15

25 May '15

Thank you for the quick fix! Best, -- Sukyoung On Jan 29, 2014, at 9:55 AM, Nathan wrote: > FYI in case you aren't subscribed to the list. > > ---------- Forwarded message ---------- > From: Yair Rand <yyairrand(a)gmail.com> > Date: Tue, Jan 28, 2014 at 7:25 PM > Subject: Re: [Wikitech-l] Bug in the Wikipedia main web page > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > Thank you for pointing out this bug. Your suggested change to > MediaWiki:Gadget-wm-portal.js has been implemented by Meta-Wiki > administrator User:PiRSquared17. > > > On Tue, Jan 28, 2014 at 6:50 PM, Sukyoung Ryu <sukyoung.ryu(a)gmail.com>wrote: > > > Dear all, > > > > We are researchers at KAIST in Korea working on finding JavaScript bugs in > > web pages. While analyzing top websites from Alexa.com, we found an issue, > > which seems to be a bug, on the Wikipedia main web page (wikipedia.org). > > We would be grateful if you can either confirm that it is a bug and even > > better fix it or let us know what we're missing. > > > > Here's the issue. When a user selects a language in which search results > > are displayed via the language selection button from the Wikipedia main web > > page, the following JavaScript function is executed: > > > > 1 function setLang(lang) { > > 2 var uiLang = navigator.language || navigator.userLanguage, date > > = new Date(); > > 3 > > 4 if (uiLang.match(/^\w+/) === lang) { > > 5 date.setTime(date.getTime() - 1); > > 6 } else { > > 7 date.setFullYear(date.getFullYear() + 1); > > 8 } > > 9 > > 10 document.cookie = "searchLang=" + lang + ";expires=" + > > date.toUTCString() + ";domain=" + location.host + ";"; > > 11 } > > > > Depending on the evaluation result of the conditional expression on line > > 4, "uiLang.match(/^\w+/) === lang", the function leaves or dose not leave > > the selected language information on the user's computer through a cookie. > > But we found that the expression, "uiLang.match(/^\w+/) === lang", always > > evaluates to false, which results in that the function always leaves > > cookies on users' computers. We think that changing the contidional > > expression, "uiLang.match(/^\w+/) === lang", to the expression, > > "uiLang.match(/^\w+/) == lang", will solve the problem. > > > > This problem may occur in the main web pages of all the Wikimedia sites. > > Could you kindly let us know what you think? Thank you in advance. > > > > Best, > > Changhee Park and Sukyoung Ryu > > > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

3 3

Please Review These Patches
by Tyler Romeo 21 Apr '15

21 Apr '15

I don’t usually email the list for this kind of stuff, but if you have some spare time to test an extension, please check out this patch chain. I’d like to get it merged before May (when they become a year old). In order of dependency: https://gerrit.wikimedia.org/r/132783 https://gerrit.wikimedia.org/r/132784 https://gerrit.wikimedia.org/r/134050 https://gerrit.wikimedia.org/r/134789 https://gerrit.wikimedia.org/r/135597 As a description, these five patches severely refactor Extension:OATHAuth, in hopes that I can try and get it deployed on wiki so that enwiki users can use two factor authentication. Thanks, -- Tyler Romeo 0x405D34A7C86B42DF

2 2

new extension
by Ricordisamoa 18 Apr '15

18 Apr '15

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?

3 8

Requiring PHP >= 5.3.3 for MediaWiki core
by Legoktm 07 Apr '15

07 Apr '15

Hi, As part of the librarization project[1], we are planning on taking the CSSJanus library that is currently in includes/lib/ and bringing it in with composer. However, it requires PHP >=5.3.3 in its composer.json[2]. Krinkle has stated[3] that is due to the fact that it has only been tested on 5.3.3 and higher, and it's also what travis-ci provides. After doing some research[4], it appears that we would be dropping support for Ubuntu 10.04LTS, which has security support until April 2015. MediaWiki 1.25.0 is expected to be released in May 2015. Does anyone have any objections to dropping 5.3.2 support? I've uploaded [5] that actually increments the required version number. Thanks, -- Legoktm [1] https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki [2] https://github.com/cssjanus/php-cssjanus/blob/master/composer.json [3] https://github.com/cssjanus/php-cssjanus/pull/5#issuecomment-60069126 [4] https://phabricator.wikimedia.org/T839#14160 [5] https://gerrit.wikimedia.org/r/168535

11 14

Our CAPTCHA is very unfriendly
by Jon Harald Søby 18 Mar '15

18 Mar '15

Hi all, My apologies if this is the wrong place to start a discussion on this, but it's a better place than nowhere. I recently took part in two very different Wikipedia workshops -- one in Uganda for schoolchildren aged 14-17, and one Bodø, Norway, for GLAM people aged 35-55. One glaringly obvious barrier of entry that was common for both groups is that the CAPTCHA we use is too freaking hard. The main concern is obviously that it is really hard to read, but there are also some other issues, namely that all the fields in the user registration form (except for the username) are wiped if you enter the CAPTCHA incorrectly. So when you make a mistake, not only do you have to re-type a whole new CAPTCHA (where you may make another mistake), you also have to re-type the password twice *and* your e-mail address. This takes a long time, especially if you're not a fast typer (which was the case for the first group), or if you are on a tablet or phone (which was the case for some in the second group). So I would like to start a discussion about changing to a CAPTCHA that is more user-friendly, and hopefully one that isn't as English/Latin-alphabet-centric as the one we currently use. If Ugandan children and old Norwegian people, which all use the Latin alphabet, have such problems deciphering the CAPTCHA, what about people speaking languages that don't use the Latin alphabet? I would prefer something more simplistic, like some sort of math or image-based CAPTCHA, instead of the current CAPTCHA we use. -- mvh Jon Harald Søby <http://meta.wikimedia.org/wiki/User:Jon_Harald_S%C3%B8by>

28 68

MediaWiki tests will verify the completeness of $wgAvailableRights
by hoo 16 Mar '15

16 Mar '15

Hi Everyone, just wanted to quickly let you know that MediaWiki will verify that extensions register all rights they define in $wgAvailableRights (or using the "UserGetAllRights" hook). To make sure your extension complies with that just add all the rights your extension defines to $wgAvailableRights (which is a simple string[] of theses user rights). This test will be introduced with https://gerrit.wikimedia.org/r/192087 Cheers, Marius

1 1

Changing contentmodel of pages
by Erik Bernhardson 16 Mar '15

16 Mar '15

When ContentHandler support was added to MediaWiki in 2012, the content type and content model of a revision is stored with it. However, the DB tables for WMF wikis did not have the new columns, so $wgContentHandlerUseDB was set to false on our wikis. Eventually the database jobs to add and populate the columns completed, and $wgContentHandlerUseDB has been true on some wikis including mediawiki.org for months. There are several projects that are requesting this be set true everywhere, T51193. However, changing the content model of an existing page is a disruptive change. We added the right `editcontentmodel` without which attempts to change content model through the API or EditPage.php fail. Currently no group (user or bot) has this right. So we think it's OK and safe to enable $wgContentHandlerUseDB on WMF wikis. https://gerrit.wikimedia.org/r/#/c/170129/ is the patch. There are issues with granting the editcontentmodel right, see T85847. The Flow discussion and collaboration software has its own contentmodel. Currently the Flow team changes a talk page to a Flow board by editing a PHP config variable (!), which doesn't scale. (FYI, plans for enabling Flow are at [1], and it is happening slowly.) When we do we archive the existing talk page content. The first change to the status quo is allowing a *new* page to be a Flow board. In particular, the Co-op project[2] wants to provide a Flow board for each new editor who signs up to collaborate with a mentor. This doesn't feel like changing the content model of a page, since there was nothing present before. So Flow has its own right, 'flow-create-board', which we grant to flow-bot group; attempting to add a Flow topic or Flow board header to an non-existent page fails unless the user has this right. The Co-op team will ask the Bot Approval Group on enwiki to grant their bot this right. Eventually we envision having a Special:Flowify page that will let admins turn a page into a Flow board. This will run PHP code to archive the current page, handle redirects, and then create a Flow board revision, etc. This feels like the 'editcontentmodel' right, but it will probably be a more restrictive right, 'flow-flowify'. Daniel Kinzler proposed that we should not grant the editcontentmodel right because any change to content model is a special case that requires smart handling via dedicated PHP code. Which is what Flow is doing for both the Co-op bot and the future Special:Flowify. So is there anything to discuss? :) [1] https://www.mediawiki.org/wiki/Flow/Rollout Relax, is happening slowly. [2] https://en.wikipedia.org/wiki/Wikipedia:Co-op

7 7

New feature: tool edit
by Petr Bena 06 Mar '15

06 Mar '15

Hi, I think I proposed this once but I forgot the outcome. I would like to implement a new feature called "tool edit" it would be pretty much the same as "bot edit" but with following differences: -- Every registered user would be able to flag edit as tool edit (bot needs special user group) -- The flag wouldn't be intended for use by robots, but regular users who used some automated tool in order to make the edit -- Users could optionally mark any edit as tool edit through API only The rationale is pretty clear: there is a number of tools, like AWB and many others that produce incredible amounts of edits every day. They are spamming recent changes page - https://en.wikipedia.org/wiki/Special:RecentChanges can't be filtered out and most of regular users are not interested in them. This would make it possible to filter them out and it would also make it easier to figure out how many "real edits" some user has made, compared to automated edits made by tools. Is it worth implementing? I think yes, but not so sure. Thanks

17 40

Moses decoder
by Bahodir Mansurov 06 Mar '15

06 Mar '15

Hello, I’ve been learning how to use Moses decoder [1] for creating machine translation models for the Uzbek language and was wondering if anyone else has any experience with. After talking to Amir, we decided to set Moses up in a Labs instance. Is anyone else interested in this? How was your experience with the decoder? Thanks, Baha [1] https://github.com/moses-smt/mosesdecoder

4 4

need review and co-mentor volunteers for GSoC Accuracy review proposal
by James Salsman 05 Mar '15

05 Mar '15

I invite review of this preliminary proposal for a Google Summer of Code project: http://www.mediawiki.org/wiki/Accuracy_review If you would like to co-mentor this project, please sign up. I've been a GSoC mentor every year since 2010, and successfully mentored two students in 2012 resulting in work which has become academically relevant, including in languages which I can not read, i.e., http://talknicer.com/turkish-tablet.pdf .) I am most interested in co-mentors at the WMF or Wiki Education Foundation involved with engineering, design, or education. Synopsis: Create a Pywikibot to find articles in given categories, category trees, and lists. For each such article, add in-line templates to indicate the location of passages with (1) facts and statistics which are likely to have become out of date and have not been updated in a given number of years, and (2) phrases which are likely unclear. Use a customizable set of keywords and the DELPH-IN LOGIN parser [http://erg.delph-in.net/logon] to find such passages for review. Prepare a table of each word in article dumps indicating its age. Convert flagged passages to GIFT questions [http://microformats.org/wiki/gift] for review and present them to one or more subscribed reviewers. Update the source template with the reviewer(s)' answers to the GIFT question, but keep the original text as part of the template. When reviewers disagree, update the template to reflect that fact, and present the question to a third reviewer to break the tie. Possible stretch goals for Global Learning Xprize Meta-Team systems [http://www.wiki.xprize.org/Meta-team#Goals] integration TBD. Best regards, James Salsman

4 8

Tech Talk: Hack - An Evolution of PHP: March 4th
by Rachel Farrand 04 Mar '15

04 Mar '15

Please join us for the following tech talk: *Tech Talk**:* Hack: An Evolution of PHP *Presenter:* Josh Watzman from Facebook *Date:* March 4th *Time:* 1800 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=Hack%3A+An+Evoluti…> Link to live YouTube stream <http://www.youtube.com/watch?v=jqXqdqUhxy8> *IRC channel for questions/discussion:* #wikimedia-office Google+ page <https://plus.google.com/u/0/b/103470172168784626509/events/ckh4leo7qam35mc5…>, another place for questions *Talk description: *Although PHP has several features that allow engineers to be extremely productive in it, it also has several rough edges and pitfalls that cause problems (and often give the language a bad name). This talk will introduce Hack, Facebook's dialect of PHP. Hack keeps most of the PHP language -- all of the parts that make engineers so productive -- but sands down several of the more problematic sharp edges. It also introduces several new features, such as a simple yet extremely powerful syntax for asynchronous IO, to make the language even more effective for existing PHP programmers and newcomers alike.

2 4

Transfering domain cswp.cz to WMF
by Petr Bena 03 Mar '15

03 Mar '15

Hi, Long time ago I purchased domain cswp.cz in order to use it in same way as enwp.org for czech wikipedia (cswp.org was taken by something). I think that it would be probably better if it was owned and maintained by WMF rather than me, but I don't really know where to ask, neither if ops are actually interested in maintaining it, the script which redirects the page is pretty simple: <?php $uri = $_SERVER['PHP_SELF']; $target = "http://cs.wikipedia.org/wiki"; header ("Location: $target"."$uri"); exit(); I can't really provide any data on usage of this domain, because I never collected any, but if there isn't any long-term plan for global wiki shorteners I think this domain could be used. Thank you

4 3

Phabricator monthly statistics - 2015-01
by communitymetrics＠wikimedia.org 03 Mar '15

03 Mar '15

Hi Community Metrics team, this is your automatic monthly Phabricator statistics mail. Number of accounts created in (2015-01): 305 Number of active users (any activity) in (2015-01): 669 Number of task authors in (2015-01): 401 Number of users who have closed tasks in (2015-01): 199 Number of tasks created in (2015-01): 2584 Number of tasks closed in (2015-01): 1775 Number of tasks in the shell project closed as resolved,fixed in (2015-01): 22 Number of open and stalled tasks in total: 19008 Median age in days of open tasks by priority: Unbreak now: 50 Needs Triage: 132 High: 133 Normal: 417 Low: 691 Needs Volunteer: 531 TODO: Numbers which refer to closed tasks might not be correct, as described in T1003. Yours sincerely, Fab Rick Aytor (via community_metrics.sh on iridium at Sun Feb 1 00:00:05 UTC 2015)

9 13

Line break in php
by Thomas Mulhall 01 Mar '15

01 Mar '15

Hi how can I do line breaks in php because I am trying to do line breaks for global in github.com/paladox/Metrolook/blob/test/MetrolookTemplate.php

2 1

Tech Talk: What's New with MediaWiki-Vagrant?: Simple Use Cases and Beyond: November 25
by Rachel Farrand 01 Mar '15

01 Mar '15

Please join us for the following tech talk: *Tech Talk**:* What's New with MediaWiki-Vagrant?: Simple Use Cases and Beyond *Presenter:* Bryan Davis & Dan Duvall *Date:* November 25th *Time:* 1830 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=What%27s+New+with+…> Link to live YouTube stream <http://www.youtube.com/watch?v=I66xR-fq2O8> *IRC channel for questions/discussion:* #wikimedia-office Google+ page <http://www.youtube.com/watch?v=I66xR-fq2O8>, another place for questions *Talk description:*We'll start off by giving a brief refresher on how MW-Vagrant works and how it differs from stock Vagrant. Next, we'll showcase some of the newest and most useful features of MWV such as multi-wiki support, SSH/HTTP sharing, Labs integration, advanced customization using Hiera and local roles. Finally, we'd like to show how MWV can be useful in test-driven development by demonstrating how to run unit and browser tests. The last 15 minutes will be reserved for Q/A. == Outline (WIP) == * (10 minutes) What is Vagrant, MediaWiki-Vagrant, Puppet (dan + bryan) * (15 minutes) Local customizations (bryan) * (15 minutes) Running unit tests and browser tests under MW-V (dan) * (5 minutes) Vagrant sharing (it's awesomesauce!!!) (bryan) * (15 minutes) Q & A

3 6

Re: [Wikitech-l] [MediaWiki-l] Autopromote problems
by Alex Monk 28 Feb '15

28 Feb '15

(CCing wikitech-l) On 28 February 2015 at 01:04, John Horne <john.horne(a)plymouth.ac.uk> wrote: > > $wgAutopromote['sysop'] = array(APCOND_ISIP, '141.163.4.11'); > Wait, what? MediaWiki supports that?! You should not do that. > However, when I log in and look at the special user rights management > page for my own userid, I see that I am in no specific group except for > the implied group of 'autoconfirmed users' and Administrators. There are > checkboxes for the Administrators, Bureaucrats and 'editor' groups, but > none of them are ticked. If I tick a checkbox, and then click save, it > says the setting has been saved but unchecks the checkbox again. > It sounds like UserRights can't reasonably handle groups that are both implied (e.g. by autopromotion) and actually grant-able to specific users (where the target user already has implied access?). I'm not entirely surprised - I'm not sure we officially support that configuration? > Secondly, and more worryingly, is that if I log in using the > 141.163.4.11 IP address, and look at the special user rights page, it > shows everyone as being in the 'Administrators' (sysop) group! If I take > out the autopromote from the LocalSettings file, then no-one (other than > the original account created during installation) is shown as being in > the Administrators group. Very strange. > Okay, matching APCOND_ISIP (and APCOND_IPINRANGE) is based on checking $user->getRequest()->getIP(). But take a look at what User::getRequest does: https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/User.… So it'll determine every user's eligibility for autopromotion... Using the current requester's IP. Depending on who requests a page (or indeed, from which IP), the wiki will have different admins. That's ridiculous. There probably can't be much more useful behaviour from User::getRequest - a user doesn't have an assigned IP address, and could have made different sorts of actions from different IPs (log in, edit, etc.) - you wouldn't want to autopromote any user account that's ever logged in from that Plymouth University IP, for example. All we can do is look at the current requester's IP. I wonder why we're not just throwing an exception when code tries to call User::getRequest for a User other than the one making the request... Maybe we just shouldn't even have a User::getRequest function at all. Alex.

1 0

[RfC] AuthManager
by Legoktm 27 Feb '15

27 Feb '15

Hi! Anomie, bd808, CSteipp, and myself have been working on updating Tyler's previous AuthStack RfC: <https://www.mediawiki.org/wiki/Requests_for_comment/AuthManager>. Our goal is to build an authentication system that is flexible enough to support the variety of usecases that MW currently supports and those it should support in the future, without requiring tons of hooks or ugly hacks. Please leave comments and feedback on the talk page :) Thanks! -- Legoktm

5 4

Welcome Eric Evans to the WMF Services team
by Rob Lanphier 27 Feb '15

27 Feb '15

Hi everyone, I'm pleased to welcome Eric Evans as a new engineer in our Services team. Eric lives and works in San Antonio, TX Eric's formative years in his current career were at Rackspace, which at the time he joined (February 2000) was a small 30 person hosting company in southern Texas. At the beginning of his tenure, he was responsible for customer-facing sysadmin work. As he progressed with increasing responsibilities, he eventually led a small team in the architecture and implementation of a multi-petabyte storage system that would become Rackspace's Cloud Files offering. By the time he left Rackspace, he was a core contributor on the Cassandra storage software project, contributing CQL (Cassandra Query Language) among other things. He also is given credit/blame for having coined the term "NoSQL". Eric left Rackspace in 2011, and has since worked in a couple of Cassandra-related roles, first at a London-based startup (Acunu) where he honed his remote collaboration skills, and later at The OpenNMS Group, where he developed Newts, a Cassandra-backed time series data store used as part of the larger network management stack. Eric has deep roots in the free software world, and contributes even when not strictly necessary for his job. He is a longtime contributor to the Debian Project, where he met our very own Faidon Liambotis, and hence, a big reason why he's here. He also created Lumens, which is software for controlling Chrismas light displays. Eric's first job here is to help get RESTbase ready for production use. RESTbase is a Cassandra-backed (see a theme yet?) revision caching/storage architecture which we're initially using to accelerate VisualEditor load times. Everyone involved is really excited to get someone with Eric's depth of experience in this area, and looking forward to seeing big things here. Eric starts working remotely today, and can be found on the #wikimedia-services IRC channel, using the nick "urandom". He'll also be visiting our SF office the week of March 9-13. Rob

1 0

MediaWiki Language Extension Bundle 2015.02 release
by Kartik Mistry 27 Feb '15

27 Feb '15

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2015.02. This bundle is compatible with MediaWiki 1.23.8 and MediaWiki 1.24.1 releases. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2015.02.tar… * sha256sum: 536cf86e7080d8293a02cb59f99d96328c7009c8239e818556b28b77b02ff88d Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to: https://phabricator.wikimedia.org/ * Talk with us at: #mediawiki-i18n @ Freenode Release notes for each extension are below. -- Kartik Mistry == Babel, CLDR, CleanChanges and LocalisationUpdate == * Only localisation updates. == Translate == * Improvements in Special:PagePreparation: ** T69591: Added 'Cancel' button. ** T68880: Categories kept as a part of page template. * T87503: Validate and normalize input file encoding in FFS. * T54728: Split language details to subpage on Special:SupportedLanguages. * Performance improvements by removing unneeded queries. * T53410: Performance improvements in Special:MessageGroupStats and Special:LanguageStats == UniversalLanguageSelector == * Restore compatibility with IE8. If you still have any issue, please report it! * Magnifying glass icon is now clickable! * Localisation updates. -- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

1 0

Fwd: Another labs outage - curse of the accursed hardware failure continues
by Yuvi Panda 27 Feb '15

27 Feb '15

FYI ---------- Forwarded message ---------- From: Yuvi Panda <yuvipanda(a)gmail.com> Date: Fri, Feb 27, 2015 at 11:42 AM Subject: Another labs outage - curse of the accursed hardware failure continues To: Wikimedia Labs <labs-l(a)lists.wikimedia.org> Hello! A repeat of the failure that happened a few days ago. Underlying flaky hardware, andrewbogott is looking into it atm. == Why is everything so terrible? == Labs instances are Virtual Machines that run on physical hardware. When the underlying hardware dies, the virtual machines on them also die. This is similar to AWS or other cloud providers. We had one spare machine (virt1012) in case any of the currently in use machines died and needed a lifeboat. A week or so ago one of the machines (virt1005) died, and we migrated things to virt1012. This week, the new machine, virt1012, has been having issues, and that's why the outages are all so similar. So the current instability is basically caused by *two* different hardware-related issues happening to two different machines with different configuration. IT IS A CURSE! == Making things better? == We're adding more hardware. https://phabricator.wikimedia.org/T90783 is the ticket for that. And specifically for toollabs, it would be awesome for it to be able to survive one virt* node being down. This is not an easy problem to solve, but here's the tracking ticket for it: https://phabricator.wikimedia.org/T90542 Andrew is working through his night (again) to diagnose / fix this issue (thanks!) and we'll keep you updated as things progress. Thank you for your patience. -- Yuvi Panda T http://yuvi.in/blog -- Yuvi Panda T http://yuvi.in/blog

1 0

Possible parser test breakage in cases using <gallery>
by Brion Vibber 26 Feb '15

26 Feb '15

The <gallery> tag generation has been updated to include srcset attributes for high-density displays: <https://phabricator.wikimedia.org/T64709> An unfortunate consequence is that if extensions have parser test cases including a <gallery> they will need to be updated for the new HTML. The only one I noticed on my setup with in Cite, so I submitted a patch to fix that; but keep an eye out for surprise test failures elsewhere. It's an easy fix -- run the parser tests, find the failing test, and copy-paste the 'srcset' attribute from the generated HTML into the test case expected output. -- brion

2 1

Config change: anon dismissal for DismissableSiteNotie
by Brion Vibber 26 Feb '15

26 Feb '15

I've gone ahead and flipped a long-requested config change for DismissableSiteNotice (which controls local, not Central, site notices) to allow anons to dismiss them. https://gerrit.wikimedia.org/r/#/c/193090/ https://phabricator.wikimedia.org/T59732 IIRC the only reason the dismiss wasn't allowed for anons was that back in 2007 or so it would have been prohibitively expensive to deal with more cookies, especially since I think local sitenotice was still being used for fundraising banners and such. My understanding of our current cookie-handling config in the caching layer is that this shouldn't explode. But if it does, or it doesn't seem to be working right, deployers please feel free to revert it and we'll poke at it some more until it works better -- it's an easy config switch, just revert and sync the settings file. If there's a better process I should follow on this sort of thing do let me know, I don't mean to step on any toes! -- brion

2 1

Extension:Newsletter seeks co-mentor or hackathon buddy
by Quim Gil 26 Feb '15

26 Feb '15

The day Extension:Newsletter is deployed, everybody will ask themselves why didn't we have this feature before. While this happens, I keep trying to find a GSoC / Outreach co-mentor, and now a hackathon buddy in Lyon just in case this alternative model works better. Someone willing to write a prototype of this MediaWiki extension. I have a clear idea of what we need and I can help sketching the UI, writing strings, testing, discussing improvements, promoting the features, perhaps even recruiting more people. If you are interested, please check Possible Project for a Newsletter MediaWiki extension https://phabricator.wikimedia.org/T76199 Public / private questions and feedback are very welcome! -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 1

server-side HTML templating now live in core
by Ryan Kaldari 26 Feb '15

26 Feb '15

After 14 months of discussion, HTML templating is now live in core MediaWiki. Currently only the server-side implementation has been merged. A client-side implementation has also been submitted, but is stalled in Gerrit (https://gerrit.wikimedia.org/r/#/c/180647/). You can now use Mustache templates in your extensions and core code by calling TemplateParser->processTemplate(). Full documentation can be found at https://www.mediawiki.org/wiki/Manual:HTML_templates. There are three main impetuses for this new feature: 1. Improving the sanity and readability of MediaWiki code. Ideally, our PHP code should have little or no HTML in it. We should strive to keep our PHP interfaces high-level and with clear separation of concerns. We are a long way from conforming to anything like an MVC pattern, but this brings us one step closer to being able to achieve that. The work on OOjs and related interfaces is another important component of this. 2. Standardizing our templating implementations. There are currently six different HTML templating implementations in various MediaWiki extensions.[1] Hopefully, we can now reduce that number. 3. Moving MobileFrontend into core. We are also a long way away from achieving this goal, but now one step closer. MobileFrontend relies heavily on HTML templating, so having this feature in core is a pre-requisite to moving more MobileFrontend features over. I know there is still disagreement about the specific implementation details of this feature (such as the choice of Mustache), but this is just the first iteration of this feature and I hope we can work together to revise and improve it further. 1. https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library… Ryan Kaldari

3 2

Reminder: VisualEditor weekly triage meetings – 2015-02-25/26
by James Forrester 25 Feb '15

25 Feb '15

As a reminder, this week's VisualEditor triage meeting will be at 00 <http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…> :00 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…> on Thursday 26 February ( 16 :00 PST on Wednesday 25 February) – that's in approximately 5 hours' time. Joining instructions are on mw:Talk:VisualEditor/Portal <https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal#How_to_join_the_tri…> . Hope to see many of you there. Yours, -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

"Needs Volunteer" priority field value in Phabricator
by Andre Klapper 25 Feb '15

25 Feb '15

Apparently the idea to rename the Priority field value from "Lowest" in Bugzilla to "Needs Volunteer" in Phabricator created more confusion than expected. I am sorry for that - wasn't intended. To fix that, there are two questions that welcome input in https://phabricator.wikimedia.org/T78617 : 1) Our Phabricator currently offers six levels of prioritization. See https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_leve… Do project maintainers / devs really feel a need for planning to differentiate between "low" priority and one level below that? Or could we reduce our six levels with five levels? 2) If there is a need for a level below "low": Let's rename "Needs Volunteer" back to "Lowest" (Looking at the proposed names in T78617, "Lowest" seems to be the least confusing term / smallest evil.) If you feel like helping make a decision by adding some *additional* arguments based on your experience, please raise your voice in T78617 after reading the existing comments and arguments in that task. Thank you for your help! andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

5 6

Wikimedia Hackathon travel sponsorship
by Quim Gil 25 Feb '15

25 Feb '15

Hi, we are hoping to open registration to the Wikimedia Hackathon in Lyon next week. Those of you relying on travel sponsorship can start preparing your requests already now: # Familiarize yourself with the goals of the hackathon: https://www.mediawiki.org/wiki/Hackathons#The_Wikimedia_Hackathon_model # Join or propose a demo-able project in Phabricator: https://phabricator.wikimedia.org/tag/wikimedia-hackathon-2015/ # Find a hackathon buddy in the Wikimedia communities or related projects out there: https://www.mediawiki.org/wiki/Lyon_Hackathon_2015/Buddies Here you have a draft form to get an idea of what questions you will be asked: http://goo.gl/forms/MPzx8q7BBz (not a real form; data submitted will be ignored and deleted) Your feedback about the process is welcome, especially in the related Phabricator task: https://phabricator.wikimedia.org/T88406 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Partial (but dramatic) labs outage on Tuesday: 2015-02-24 1500UTC-1800UTC
by Andrew Bogott 24 Feb '15

24 Feb '15

It is with a heavy heart that I must share the news of an upcoming Labs maintenance window. The labs NFS store (which you probably know as /data/project) is filling up rapidly and we need to add more drives. By weird coincidence the actual physical space for that server in the datacenter is ALSO filling up, so Chris Johnson has graciously agreed to spend his day re-shuffling servers in order to make space for the new diskshelf. This involves lots of unplugging and replugging and amounts to the fact that the NFS server will need to be turned off for several hours. During this window Chris will take care of another long-deferred maintenance task -- he's putting more RAM into the labs puppet master, virt1000. What will break: - Shared storage for all labs and tools instances. That includes volumes like /data/project, /public/dumps, /data/scratch, /home - Logins to all instances running ubuntu Precise. (Trusty hosts will /probably/ still support logins.) - Login to wikitech and manipulation of instances. What won't break: - Labs instances will continue to run - Tasks running on instances will continue to run; those that don't rely on shared storage should be fine. - Web proxies should keep working, if the services they support aren't relying on shared storage. What will get better: - More storage space! - Fewer problems with dumps filling up NFS (which is basically the same as 'more storage space'. - More reliable puppet runs and fewer outages with miscellaneous OpenStack services (which also run on virt1000) I apologize in advance for this downtime. Don't hesitate to contact me or Coren either here or on IRC with advice about how to harden your tool against this upcoming outage. We will also be available on IRC during and after the outage to help revive things that are angry about the timeouts. -Andrew

2 2

New process for Gerrit repository ownership requests
by Quim Gil 24 Feb '15

24 Feb '15

The on-wiki process to request ownership of Gerrit repository has been moved to Phabricator. We hope this change will contribute to a faster processing of requests, not because Phabricator is intrinsically magic, but because you can now associate requests to relevant Phabricator projects and CC existing repo owners to your requests. https://www.mediawiki.org/wiki/Gerrit/Project_ownership https://phabricator.wikimedia.org/tag/repository-ownership-approvers/ These are the people who can approve repository ownership: https://phabricator.wikimedia.org/project/members/1076/. Ideally all of you would watch this project to receive notifications as soon as new requests are submitted... instead of leaving almost all the work to Chad and QChris. By the way, there seems to be an open request: Replacing mwalker with cscott for the OCG repositories https://phabricator.wikimedia.org/T90585 PS: this migration has been discussed at https://phabricator.wikimedia.org/T86639 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 2

Announcing service-runner, a startup module / supervisor for node services
by Gabriel Wicke 24 Feb '15

24 Feb '15

Hi folks, in our quest to simplify the creation of production-quality services we have recently made some modest progress with a service-runner module [1] and an early service-template-node prototype [2]. The latter deserves its own discussion (and is at a very early stage), so I'm focusing on service-runner in this thread. Service-runner [1] is a small module that we moved out of restbase. It generalizes some simple start-up, monitoring and supervision facilities that we refined while building services like Parsoid, Mathoid or RESTBase: - commandline option parsing & yaml config loading (with a standard format) - worker pool management using the cluster module; graceful restarts - logging via gelf to logstash, with option to configure other backends - generic metric reporting (txstatsd, statsd or simple logging for development) - general worker monitoring & debugging: V8 heap metrics & limiting, support for heap dumps For small (third party) installs with limited memory, we also added the capability to cleanly run multiple services in a single process. The uniform way to run and configure services provided by service-runner should let us create a shared puppet module to manage most of the per-service tasks [3]. Another possibility is to automatically build packages for these services [4], which can help to distribute these services to third-party users. So, please have a look & let us know what you are missing / would like to see. There is a service-runner tag on phabricator [5] that we can use to track specific tasks. Thanks, Gabriel [1]: https://github.com/wikimedia/service-runner [2]: https://github.com/wikimedia/service-template-node [3]: https://phabricator.wikimedia.org/T89901 [4]: https://phabricator.wikimedia.org/T89900 [5]: https://phabricator.wikimedia.org/tag/service-runner/

6 8

Re: [Wikitech-l] If you hear about 'hackathon buddies'...
by Quim Gil 24 Feb '15

24 Feb '15

If you are looking for a Wikimania Hackathon buddy, check https://wikimania2015.wikimedia.org/wiki/Hackathon/Buddies On Thu, Feb 19, 2015 at 3:57 PM, Quim Gil <qgil(a)wikimedia.org> wrote: > Yesterday we opened the travel request process for Wikimedia Foundation > employees in Engineering and Product willing to participate at the > Wikimedia Hackathon or Wikimania. There is no public link, but you can > follow this task at https://phabricator.wikimedia.org/T89355 > > In this process, we are asking WMF employees to find a hackathon buddy > with the sole requirement of not being another WMF employee. In fact, in > the registration for the hackathons we will request the same to all > participants. > > https://www.mediawiki.org/wiki/Hackathons#Pairing_buddies > > This means that non-WMF contributors might receive a request from a WMF > employee to be hackathon buddies. This also means that if you are planning > to participate in any of these events (and especially if you plan to > request travel sponsorship to Lyon) you will be encouraged to find a buddy > as well. > > It's going to be fun. :) And no worries, we will help making connections > to whoever needs that help. > -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Global user pages deployed to all wikis
by Legoktm 23 Feb '15

23 Feb '15

Hello! Global user pages have now been deployed to all public wikis for users with CentralAuth accounts. Documentation on the feature is available at mediawiki.org[1], and if you notice any bugs please file them in Phabricator[2]. Thanks to all the people who helped with the creation and deployment (incomplete, and in no particular order): Jack Phoenix & ShoutWiki, Isarra, MZMcBride, Nemo, Quiddity, Aaron S, Matt F, James F, and everyone who helped with testing it while it was in beta. [1] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage [2] https://phabricator.wikimedia.org/maniphest/task/create/?projects=PHID-PROJ…

25 39

Increase min mysql version to 5.0.3
by Brian Wolff 23 Feb '15

23 Feb '15

Currently the min mysql version we require is 5.0.2. In order to fix T6715 [2], I'd like to bump it to 5.0.3. This would allow us to have varchar fields larger than 255. Anyone have any objections? 5.0.3 was released in march 2005 (8 years ago!), so this is hardly bleeding edge. As far as I can tell, Wikiapiry says this would affect no wikis [1] [0] https://phabricator.wikimedia.org/T6715 [1] https://wikiapiary.com/w/index.php?title=Special%3ASearchByProperty&propert… -- bawolff

1 0

ignoring composer.lock
by Amir E. Aharoni 23 Feb '15

23 Feb '15

Hi, Should composer.lock be added to .gitignore? It may be different for different extensions. In ContentTranslation we currently only have: "require": { "php": ">=5.3.0", "composer/installers": ">=1.0.1" }, I don't know much about Composer, but it looks like nothing more than the bare minimum. Should composer.lock be version-controlled in such a situation? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

2 1

E-mail login to wiki - needs feedback
by Tony Thomas 23 Feb '15

23 Feb '15

Hello, Before someone starts with a proposal for the proposed-tech-project 'Allow user login with e-mail address'[1], is there still community consensus for the same ? I personally think its a must-have for MediaWiki, as e-mail address is easy to remember than a complex username. Currently multiple users can sign-up with the same e-mail id - which would possibly be a blocker, and can be fixed. Thanks to MzMcbride, we have an RFC[2] too on the same. [1] https://phabricator.wikimedia.org/T30085 [2] https://www.mediawiki.org/wiki/Requests_for_comment/Login_via_e-mail_address Thanks, Tony Thomas <http://tttwrites.wordpress.com/> FOSS@Amrita <http://foss.amrita.ac.in> *"where there is a wifi, there is a way"*

19 32

GPL upgrading to version 3
by Thomas Mulhall 23 Feb '15

23 Feb '15

Hi should we upgrade GPL to version 3 since version 3 is more modern then version 2. Should it be updated in extensions, skins and MediaWiki.

26 71

post project funding
by dan entous 23 Feb '15

23 Feb '15

does anyone know if there is a method for applying for post project funding within the wikiverse or if there is a committee that awards a project after it has proven itself useful? with kind regards, dan

5 7

Re: [Wikitech-l] [Wikimedia-l] Types of allowed projects for grant funding (renamed)
by Pine W 22 Feb '15

22 Feb '15

Hi Luis, Thank you for agreeing to consider grant funding for software projects. It sounds like you also plan a broader review of funding for community needs and growth. I have a list of requests for changes, which boil down to removing policy barriers and greatly improving communications and workflows so that community growth is fostered and volunteer time is used wisely. I imagine that we will have an opportunity to discuss these matters in person in Berlin. I look forward to seeing you there, and I greatly appreciate your interest in supporting communities and contributor growth. Pine On Feb 21, 2015 6:12 PM, "Luis Villa" <lvilla(a)wikimedia.org> wrote: > On Sat, Feb 21, 2015 at 5:39 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > > > Damon, Luis and members of their teams will need to weigh in on this, > > and will want to think through the implications for their respective > > areas, but it's a good conversation to have -- keeping in mind that > > Luis is just starting in his new role, so please give him at least a > > few days to get up to speed. ;-) > > > > Thanks for at least a few hours of cushion, Erik ;) > > I'm a big believer in the power of/need for software tools, and at least > philosophically I'm very open to funding software development outside the > Foundation (though obviously there are lots of pragmatic difficulties - > code review, etc.) So, yes, as part of our broader review of how we support > communities and contributor growth, CE will look at funding code very > seriously. > > Luis > > -- > Luis Villa > Sr. Director of Community Engagement > Wikimedia Foundation > *"Imagine a world in which every single human being can freely share in the > sum of all knowledge. That's our commitment."* > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

2 1

Re: [Wikitech-l] Types of allowed projects for grant funding (renamed)
by Pine W 22 Feb '15

22 Feb '15

(Now continuing this discussion on Wikimedia-l also, since we are discussing grant policies.) For what it's worth, I repeatedly advocated for allowing IEG to support a broader range of tech projects when I was on IEGCom. I had the impression that there was a lot of concern about limited code review staff time, but it serms to me that WMF has more than enough funds to to pay for staffing for code review if that is the bottleneck for tech-focused IEGs (as well as other code changes). I also think that the grant scope policies in general seem too conservative with regard to small grants (roughly $30k and under). WMF has millions of dollars in reserves, there is plenty of mission-aligned work to be done, and WMF itself frequently hires contractors to perform technical, administrative, communications, legal and organizing work. It seems to me that the scope of allowed funding for grants should be similar to the scope of allowed work for contractors, and it would serve the purposes that donors have in mind when they donate to WMF if the scope of allowed purposes for grants is expanded, particularly given WMF's and the community's increasing skills with designing and measuring projects for impact. In the past I think there were probably some wasteful uses of grant funding, and the response at the time might have been to prohibit or refuse to fund entire categories of expenses. Now that everyone has more planning and evaluation capacity, it seems to me that this is a good time to rethink the categorical prohibitions and replace at least some of them with appropriate expectations for impact that would better serve our overall mission of creating and sharing knowledge. Pine On Feb 21, 2015 12:05 PM, "Brian Wolff" <bawolff(a)gmail.com> wrote: > On 2/21/15, Pine W <wiki.pine(a)gmail.com> wrote: > > In general WMF has a conservative grant policy (with the exception of > IEG, > > grant funding seems to be getting more conservative every year, and some > > mission-aligned projects can't get funding because they don't fit into > the > > current molds of the grants programs). Spontaneous cash awards for > previous > > work are unlikely. However, if there is an existing project that could > use > > some developer time, it may be possible to get grant funding for future > > work. > > > > [Rant] > > I find this kind of doubtful when IEG's (which for an individual > developer doing a "small" project is really the type of funding that > applies) have been traditionally denied for anything that even > remotely touches WMF infrastructure. (Arguably the original question > was about toollabs things, which is far enough away from WMF > infrastructure to be allowed as an IEG grant, but I won't let that > stop my rant...). Furthermore, it appears that IEGs now seem to be > focusing primarily on gender gap grants. > > I find it odd, that we have grants through GSOC and OPW to people who > are largely "newbies" (although there are exceptions), and probably > not in a position to do anything "major". IEG provides grants as long > as they are far enough away from the main site to not actually change > much. But we do not provide grants to normal contributors who want to > improve the technology of our websites, in big or important ways. > > Ostensibly this is done in the name of: > >Any technical components must be standalone or completed on-wiki. > Projects are > >completed without assistance or review from WMF engineering, so MediaWiki > >Extensions or software features requiring code review and integration > cannot be > >funded. On-wiki tech work (templates, user scripts, gadgets) and > completely > >standalone applications without a hosting dependency are allowed. > > Which on one hand is understandable. WMF-tech has its own priorities, > and can't spend all its time babysitting whatever random ideas get > funded. So I understand the fear that brought this about. On the other > hand it is silly, since a grant to existing tech contributors is going > to have much less review burden than gsoc/opw, and many projects might > have minimal review burden, especially because most review could > perhaps be done by non-wmf employees with +2, requiring only a final > security/performance sign off. In fact, we do already provide very > limited review to whatever randoms submit code to us over the internet > (regardless of how they are funded, or lack thereof). If IEG grants > were allowed in this area, it would be something that the grantee > would have to plan and account for, with the understanding that nobody > is going to provide a team of WMF developers to make someone else's > grant happen. We should be providing the same amount of support to IEG > grantees that we would to anyone who submitted code to us. That is, > not much, but perhaps a little, and the amount dependent on how good > their ideas are, and how clean their code is. > > > [End rant] > > Politically, I think its dangerous how WMF seems to more and more > become the only stakeholder in MediaWiki development (Not that there > is anything wrong with the WMF, I just don't like there being only 1 > stakeholder). One way for there to be a more diverse group of > interests is to allow grants to groups with goals consistent with > Wikimedia's. While not exactly super diverse (all groups have similar > goals), at least there would then be more groups, and hopefully result > in more interesting and radical projects. > > --bawolff > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

6 5

Thread subjects
by Bináris 22 Feb '15

22 Feb '15

Hi folks, could we by any chance return to the conservative Netiquette way of creating subjets, or the New Era of inadequate subjects has just begun, and we trend to soil the list with these marketing-based whatnots? Shall I go to the details or are we all informatics-minded people here? -- Bináris

2 1

Progress report: Hierator
by Max Semenik 22 Feb '15

22 Feb '15

Hi, this is a status update for my WikiHiero rewrite! [1] I've made a first pass on comparison, based on all hieroglyphic texts on English Wikipedia: [2] You can see the difference yourselves, in my opinion the general quality is considerably better, and far more hieroglyphs are supported. However, a few problems were identified, mostly related to WikiHiero accidentally allowing invalid syntax in the past. I'm working on either fixing them in tokenizer, e.g. converting "ra::" to something like "ra:.:." or making a fallback to the old HTML renderer and adding a tracking category for future fixage by editors. Some of the known problems are listed at [3]. Unfortunately, this also includes some cases where WikiHiero's hieroglyphs deviated from what was said in standards, resulting in a mess that needs manual conversion during a transitional period. These will also fall back on the old renderer and be tracked. The code is still being worked on, it can be seen in [4] (Hierator) and [5] (WikiHiero). ----- [1] https://www.mediawiki.org/wiki/Requests_for_comment/Hierator [2] http://staging.wmflabs.org/w/extensions/wikihiero/comparison/ [3] https://www.mediawiki.org/wiki/Extension:WikiHiero/JSesh_migration [4] https://gerrit.wikimedia.org/r/178970 [5] https://gerrit.wikimedia.org/r/178269 -- Best regards, Max Semenik ([[User:MaxSem]])

2 1

w3c editing task force
by Amir E. Aharoni 21 Feb '15

21 Feb '15

Hi, I just found out that w3c has an editing task force, which tries to address the nightmare that is contenteditable: http://w3c.github.io/editing-explainer/tf-charter.html Does Wikimedia participate in it in any way?

1 0

My experiences with PHPCS and PHPMD
by Jeroen De Dauw 21 Feb '15

21 Feb '15

Hey, I've written some stuff about my experiences with PHPCS and PHPMD in the context of MediaWiki development, which might be of interest to people here. http://www.bn2vs.com/blog/2015/02/20/phpcs-and-phpmd-my-experiences/ Also, in case you want to see how easy it is to add these tools to a MediaWiki extension, see https://github.com/SemanticMediaWiki/SemanticMetaTags/pull/25/files Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3

2 1

Parser tests failing due to clickable anchors for section headers
by Vivek Ghaisas 20 Feb '15

20 Feb '15

In I562e437e, clickable anchors for section headers were added to the parser's output, which is causing many extensions' tests to fail . I will try to update some of the extensions' tests, but I'm hoping the extension maintainers will update their tests to reflect this change since I don't think I'll be able to update them all as of now. Sincere apologies for the late notification. Regards, polybuildr

2 1

RuboCop is now voting
by Željko Filipin 20 Feb '15

20 Feb '15

Antoine and I have paired on making the RuboCop[0] Jenkins jobs voting. The details are in Phabricator[1] and Gerrit[2]. If you are not familiar with Rubocop, there is some documentation at mediawiki.org[3] and my blog[4]. If a repository is set up to run RuboCop, all you have to do is to execute this is terminal: gem install bundler bundle install bundle exec rubocop If you have any questions, or if you notice any problems, let me know. Željko -- 0: https://github.com/bbatsov/rubocop 1: https://phabricator.wikimedia.org/T84979 2: https://gerrit.wikimedia.org/r/#/c/191861/ 3: https://www.mediawiki.org/wiki/Manual:Coding_conventions/Ruby#RuboCop 4: http://filipin.eu/rubocop/

1 0

Preparing Google Summer of Code 2015 and Outreachy
by Quim Gil 20 Feb '15

20 Feb '15

Today Google Summer of Code 2015 and Outreachy (was FOSS Outreach Program for Women, now open to other groups) have announced their call for organizations. Wikimedia will apply to both programs. The deadlines are February 20 and 17, respectively. THIS IS 7-10 DAYS FROM NOW! We need to update the ideas page, but this time we will do it differently: all project ideas need to be presented as a Phabricator task only (no excerpt in wiki page page is needed). We will use a workboard to track the readiness of project ideas. If you are interested in participating as intern or mentor, follow https://phabricator.wikimedia.org/T921 If you are interested in proposing a project idea, associate your task to https://phabricator.wikimedia.org/tag/possible-tech-projects/ (work-in-progress drafts and other proposals subject to discussion are welcome too) I'm looking for a co-organizer to drive this round. We have a process that works, a motivated pool of mentors, and room for creativity and improvement. Between two people, the job is actually simple, and the rewards are literally priceless (including the possibility to attend the Mentors Summit). Nemo was a great co-organizer of Google Code-in, setting a precedent that we want to consolidate. If you are interested, contact me. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 1

(no subject)
by Angela lum neh 19 Feb '15

19 Feb '15

Hello everyone, am Angela. Am happy to be part of this mailing list.

2 1

If you hear about 'hackathon buddies'...
by Quim Gil 19 Feb '15

19 Feb '15

Yesterday we opened the travel request process for Wikimedia Foundation employees in Engineering and Product willing to participate at the Wikimedia Hackathon or Wikimania. There is no public link, but you can follow this task at https://phabricator.wikimedia.org/T89355 In this process, we are asking WMF employees to find a hackathon buddy with the sole requirement of not being another WMF employee. In fact, in the registration for the hackathons we will request the same to all participants. https://www.mediawiki.org/wiki/Hackathons#Pairing_buddies This means that non-WMF contributors might receive a request from a WMF employee to be hackathon buddies. This also means that if you are planning to participate in any of these events (and especially if you plan to request travel sponsorship to Lyon) you will be encouraged to find a buddy as well. It's going to be fun. :) And no worries, we will help making connections to whoever needs that help. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 6

OOjs UI 0.8.0 release
by Trevor Parscal 19 Feb '15

19 Feb '15

OOjs UI 0.8.0 has been released today. It will be in MW from 1.25wmf19+. *Breaking changes since last release:* - [BREAKING CHANGE] Make default distribution provide SVG with PNG fallback (Bartosz Dziewoński) We've tagged this as a breaking change, but the only breakage is renaming the stylesheet files. This will only "break" for systems which are responsible for importing the library. This is fixed for MediaWiki and for VisualEditor standalone; no other users should be affected. As part of this change, from MediaWiki 1.25wmf19 onwards, OOjs UI will provide raster icon fallbacks for the vector icons, which we were previously not using. *Deprecations since last major release:* - DEPRECATION: TextInputWidget: Deprecate 'icon' and 'indicator' events (Bartosz Dziewoński) The functionality they expose (user clicking on the icon/indicator) is fundamentally not accessible: the icon/indicator is not focusable (has no tabindex), has no keyboard events, doesn't have a label associated or a tooltip, and has no sensible way of fixing all of this. If something needs to be clickable separately, it should probably be a separate Widget with the appropriate mixins added. - DEPRECATION: ButtonWidget: Rename nofollow config option to noFollow (C. Scott Ananian) We're switching this feature (added just last release) to use consistent camel case. The old `nofollow` property still works for backward compatibility, but it is deprecated and will be removed in the next major release but one. If you have any further questions or need help dealing with deprecations, please let me know. General library documentation is available at mediawiki.org <https://www.mediawiki.org/wiki/OOjs_UI> and generated code-level documentation at doc.mediawiki.org <https://doc.wikimedia.org/oojs-ui/master/#!/api>. - Trevor

1 0

VisualEditor weekly triage meetings – 2015-02-18 – minutes
by James Forrester 19 Feb '15

19 Feb '15

Here are the minutes for this week's VisualEditor weekly triage meeting on 2015-02-18. *Item 1 – Release criteria* The release criteria at https://phabricator.wikimedia.org/project/sprint/profile/1015/ (note new URL) were considered. It was proposed and agreed that the wording for "Qualitative UX testing" be changed from "Most users" to a specific number of 75%, and similarly in "Meets specified performance benchmarks", that "reasonable" was changed to a specific number of 150%. These changes have been made. *Item 2 – Review of fixed tickets since last week* These accepted items were fixed and so will be released in this week's production release unless otherwise noted. … in VisualEditor: - https://phabricator.wikimedia.org/T88650 – Support data-mw.body.id for reference contents - https://phabricator.wikimedia.org/T88148 – class="wikitable wikitable" corrupted to class="wikitable" - https://phabricator.wikimedia.org/T87161 – Default to not performing sanity checks - https://phabricator.wikimedia.org/T86401 – Cutting and pasting a paragraph causes (only) the last inline template to be replaced by HTML - https://phabricator.wikimedia.org/T74929 – Using browser native interactive spell-check when the changed word in the only item in the paragraph causes endless insertions in Firefox [*fixed in our IME work in January*] - https://phabricator.wikimedia.org/T74398 – Actually run MediaWiki-VisualEditor's tests for MWHeadingNode / MWPreformattedNode - https://phabricator.wikimedia.org/T67873 – Cannot go to the next line of an article after inserting a special character in a block slug and "TypeError: Inserted data is trying to close the root node (at index 0)" appears [*fixed earlier*] - https://phabricator.wikimedia.org/T65462 – Using browser native interactive spell-check tool causing repeated automatic deletion in Chrome [*fixed in our IME work in January*] - https://phabricator.wikimedia.org/T61748 – Native browser interactive spell-check tool fails to get content into DM, just CE, in Safari [*fixed in our IME work in January*] The fixed tickets represent 83 "story points". There are 1020 remaining points in the list of items accepted as of the end of the meeting. … in dependencies: - https://phabricator.wikimedia.org/T88660 – Parsoid Cite: Render missing reflists - https://phabricator.wikimedia.org/T88019 – Transclusion marker meta tags being left behind in some nested extension/transclusion scenarios - https://phabricator.wikimedia.org/T85870 – Parsoid performance analysis - https://phabricator.wikimedia.org/T75955 – RESTBase / Parsoid integration - waiting for parsoid deploy - https://phabricator.wikimedia.org/T69787 – Investigate remaining rtselser errors in parserTest runs *Item 3 – Review of nominated tickets* Nominated tickets accepted: … as corruption & stability issues: - https://phabricator.wikimedia.org/T89192 – [Regression wmf-16] Including a template/comment/table/gallery/math node in a slug makes the editor completely unresponsive - https://phabricator.wikimedia.org/T89309 – [Regression wmf-17] Safari - cannot click in any check-box … as performance issues: - https://phabricator.wikimedia.org/T89543 – ve.init.mw.ViewPageTarget.transformPage triggers recalculate style due to $.fn.animate - https://phabricator.wikimedia.org/T89423 – Massive recalculate style triggered by OO.ui.Widget.setDisabled - https://phabricator.wikimedia.org/T89536 – Instrument (i.e., track) additional progress markers for VE load - https://phabricator.wikimedia.org/T89735 – VisualEditor is emitting event "timing.ve.behavior.firstTransaction.undefined" … as testing issues: - https://phabricator.wikimedia.org/T89075 – Investigate Chrome disconnect failures when running MediaWiki tests on labs slaves … as feature issues: - https://phabricator.wikimedia.org/T88152 – Cite: 'Autofill from URL' initially shows Basic as a type for inserted citation in context menu, then corrects when re-selected - https://phabricator.wikimedia.org/T89352 – Make slugs keyboard accessible again - https://phabricator.wikimedia.org/T76398 – External link interface for link dialogue [high risk area; accepted with provision that we will likely have to modify work based on user testing] - https://phabriactor.wikimedia.org/T76397 – Search interface for link dialogue [ high technological risk area; accepted with lower priority, to be re-assessed later ] - https://phabricator.wikimedia.org/T52036 – Focus highlights for elements using CSS column-count are too tall in Chrome [accepted as a "polish" issue] - https://phabricator.wikimedia.org/T73085 – Comments in "unsafe" content locations are not displayed [accepted as a lower-priority issue; needs technological investigation for feasibility] … as dependencies: - https://phabricator.wikimedia.org/T89788 – Report on the central tendency for length of pages which are edited for VisualEditor performance benchmarking … for investigation and re-triage: - – None this week Nominated tickets rejected: - https://phabricator.wikimedia.org/T89074 – Create a guided tour for VisualEditor using Getting Started tooltips Rejected for now based on product concerns raised about targeting the right user groups and in the right way, and technological risk/feasibility about bringing in new systems into contact with VisualEditor. Likely to be re-cast and re-nominated next week. - https://phabricator.wikimedia.org/T89072 – Change Welcome dialogue content to more helpful message to new users based on the GuidedTour Rejected as dependent on the above ticket. *Item 4 – Other business* The process was very briefly discussed, without suggestion of changes. Hope this is of interest. Next week's meeting will be at 00 <http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…> :00 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150225T16&p1=224…> ( 16 :00 PST) on Wednesday 25 February; hope to see many of you there. Joining instructions are on mw:Talk:VisualEditor/Portal <https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal#How_to_join_the_tri…> . We'll send a reminder before the meeting. Yours, -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

Html.php line 269
by Petr Bena 19 Feb '15

19 Feb '15

Can someone explain the point of these lines to me? https://github.com/wikimedia/mediawiki/blob/master/includes/Html.php#L269 If these tags are optional, they can be there, so why remove them? If you remove them, you should probably also care about them in closeElement() so that mediawiki doesn't produce html which has only ending tags for html and head. It seems that on WMF installation we don't use anyway as there is head tag. So why is it there? What purpose does it server?

6 10

Scrum of Scrums notes, 2015-02-18
by Dan Andreescu 18 Feb '15

18 Feb '15

https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-02-18

1 0

[Reminder] [x-post] Language Engineering IRC Office Hour on 18 February 2015 (Wednesday) at 1300 UTC
by Runa Bhattacharjee 18 Feb '15

18 Feb '15

Hello, A quick reminder about Language Engineering team's monthly IRC office hour thats happening later today at 1300 UTC on #wikimedia-office. Please see below for the original announcement, local time, and agenda. We will post logs on metawiki[1] after the event. Thanks Runa [1] https://meta.wikimedia.org/wiki/IRC_office_hours#Office_hour_logs ---------- Forwarded message ---------- From: Runa Bhattacharjee <rbhattacharjee(a)wikimedia.org> Date: Fri, Feb 13, 2015 at 7:47 PM Subject: [x-post] Language Engineering IRC Office Hour on 18 February 2015 (Wednesday) at 1300 UTC To: MediaWiki internationalisation <mediawiki-i18n(a)lists.wikimedia.org>, Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>, Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, "Wikimedia & GLAM collaboration [Public]" <glam(a)lists.wikimedia.org> [X-posted announcement] Hello, The next monthly IRC office hour of the WMF Language Engineering team will be on February 18, 2015 (Wednesday) at 1300 UTC on #wikimedia-office. Please note that for this instance the session has been set to a much earlier hour. We will be taking questions and discussing about our ongoing projects, particularly the recent activation of Content Translation as a beta feature on several Wikipedias[1]. We’d love to hear comments, suggestions and any feedback that will help us make this tool better. Please see below to check local time and event details. Logs from our earlier office hours are available at: https://meta.wikimedia.org/wiki/Category:Language_Engineering Thanks Runa [1] http://blog.wikimedia.org/2015/01/20/try-content-translation/ Monthly IRC Office Hour: ================== # Date: February 18, 2015 (Wednesday) # Time: 1300 UTC (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150218T1300) # IRC channel: #wikimedia-office # Agenda: 1. Ongoing projects - Content Translation beta feature 2. Q & A (Questions can be sent to me ahead of the event) -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation

1 0

IRC: wm-bot now speak with GitHub fluently
by Petr Bena 17 Feb '15

17 Feb '15

Hi folks, I was too tired of semi-working unstable random IRC services that provides IRC commit messages from github to your channel, so I created a simple plugin to wm-bot which can handle that now. Features: * It's incredibly easy to setup (10 seconds setup) * Requires no registration * Pretty stable (running on wikimedia labs) * Self-service - everyone can configure the bot as they want directly from IRC How it works in few steps: 1) Get wm-bot to your channel (just join #wm-bot and type @add #somechannel 2) type @github+ <full name of repository> for example for repository http://github.com/benapetr/test it would be @github+ benapetr/test 3) Add web hook in github settings of your repository to http://wm-bot.wmflabs.org/github/index.php That's all Example output: (10:41:00) <wm-bot> GitHub [benapetr/test-wm] benapetr pushed 1 commits: https://github.com/benapetr/test-wm/compare/87ad2018cae6...f5b2131c10ad (10:41:00) <wm-bot> GitHub [benapetr/test-wm] commit by benapetr (Petr Bena) https://github.com/benapetr/test-wm/commit/f5b2131c10ad3bb1fe902db911ed0142… test Formatting kind of suck, but you can fix it! Handler is written in PHP: https://github.com/benapetr/wikimedia-bot/blob/master/src/WMBot.Plugins/Git…

2 4

Define entry point to generate documentation
by Antoine Musso 17 Feb '15

17 Feb '15

Hello, We are migrating Jenkins jobs to simply invokes [test entry points] (ex: composer test, npm test). Some repositories have documentation generated by Jenkins and pushed under https://doc.wikimedia.org/ . I would like to make it as trivial as possible for developers to configure Jenkins, hence I am looking to establish a convention to generate doc. We would need: - a single command we agree on (ex: make doc) - a way to pass/override the destination directory so the jobs in Jenkins can enforce the output where it expects it I have filled https://phabricator.wikimedia.org/T88999 for it. Discussions on wikitech-l preferred. If there is no objections by next week. I will define the convention to be 'make docs' and create all the needed Jenkins jobs templates. Thanks! [test entry points] https://www.mediawiki.org/wiki/Continuous_integration/Test_entry_points -- Antoine "hashar" Musso

2 2

Re: [Wikitech-l] Deadline for Wikimania 2015 submissions: Feb 28
by Quim Gil 17 Feb '15

17 Feb '15

It turns out we are in 2015. :D On Tue, Feb 17, 2015 at 10:05 AM, Quim Gil <qgil(a)wikimedia.org> wrote: > Hi, just a reminder about the deadline to submit proposals for Wikimania: > February 28. > > https://wikimania2015.wikimedia.org/wiki/Submissions > > The Hackathon program will be more flexible in terms of deadline, process, > etc, but if you want to have a session scheduled in the main Wikimania > program you need to submit your proposal before the end of this month. > -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Deadline for Wikimania 2005 submissions: Feb 28
by Quim Gil 17 Feb '15

17 Feb '15

Hi, just a reminder about the deadline to submit proposals for Wikimania: February 28. https://wikimania2015.wikimedia.org/wiki/Submissions The Hackathon program will be more flexible in terms of deadline, process, etc, but if you want to have a session scheduled in the main Wikimania program you need to submit your proposal before the end of this month. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Adopting Composer's composer.json for extensions
by Mark A. Hershberger 17 Feb '15

17 Feb '15

I've opened a task on Phabricator[1] to attempt to merge the information in extension.json with Composer's already-used-by-several-extensions-and-skins composer.json. Kunal has rightly pointed out that composer doesn't fit some use-cases for MediaWiki. I see that as an opportunity to be good citizens in the larger developer community by working to integrate MediaWiki into the growing ecosystem available on packagist.org. For example, if composer had been available, we might not have had to develop our own HTTP client. If composer had been available, Brion could have released the work under includes/normal as its own package. As he says in the README there: This directory contains some Unicode normalization routines. These routines are meant to be reusable in other projects, so I'm not tying them to the MediaWiki utility functions. (Of course, there was PEAR, but that is ugly and centralized in a way that composer is not.) Using Composer for extensions also reduces the learning curve for developers who want to adapt their work (which may already be available via Composer) to be used in MediaWiki. It helps us increase the size of the available developer community without too much effort. Footnotes: [1] https://phabricator.wikimedia.org/T89456 -- Mark A. Hershberger NicheWork LLC 717-271-1084

4 4

Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun
by Max Semenik 17 Feb '15

17 Feb '15

Sorry for all the trolling, but why instead of discussing how we need a responsive skin for MediaWiki and waiting for Winter to come don't we just do it: * Move Minerva out of MobileFrontend * Leave all mobile-specific improvements, "improvements" and hacks in MF * Polish Minerva to do everythig a normal desktop skin does * Bundle it with MW by default ---- [0] https://en.wikipedia.org/wiki/James_Randi?useskin=minerva -- Best regards, Max Semenik ([[User:MaxSem]])

16 20

[VisualEditor] 2nd weekly triage meeting; office hours in February and March
by Erica Litrenta 16 Feb '15

16 Feb '15

Hi everybody, and apologies for cross-posting. Here are some reminders and announcements about upcoming appointments related to VisualEditor. This Wednesday (18 February) the second *triage meeting* is scheduled for 4pm UTC [1]. You can find all the relevant information at mediawiki.org. [2] This email also serves as a reminder that the next VE *office hour* is on Thursday 19 February at 7pm UTC [3], in case you had not added it to your calendar yet! Please notice that March's appointment has been scheduled as well: we'll meet on Friday 27 at 3pm UTC [4]; previous logs and other information, including how to participate, can be found at Meta [5]. Talk to you soon! Elitre (WMF) https://www.mediawiki.org/wiki/Community_Engagement_(Product) [1] http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=00&sec=0&d… [2] https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal#How_to_join_the_tri… [3] http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=00&sec=0&d… [4] http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0&d… [5] https://meta.wikimedia.org/wiki/IRC_office_hours

1 0

What architectural fissures do we want in MediaWiki?
by Rob Lanphier 16 Feb '15

16 Feb '15

Hi everyone, There has been a lot of talk over the past year or so about SOA and what it means for MediaWiki. What I've taken from the conversation is the following: 1. There is a general desire for us to separate user interface code from data manipulation code. This is mainly in service of making alternative user interfaces simpler and cleaner (e.g. mobile web, mobile apps, print, offline). The developers that are consumers of said systems (i.e. user interface developers) probably don't care so much what goes on inside the data manipulation sausage factory, so long as the APIs used to access our data are well-defined and easy to use. It may be one data manipulation service, it may be 100 tiny little services with a brokering layer, but as long as there's a clean split, all is well. I've created an RFC which basically spells this out: https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_pre… Note that there is nothing terribly creative about this idea, and *that is the point*. With this RFC, let's document which aspects are utterly uncontroversial so that we can make clear the urgency to come to consensus on more specific proposals, such as Trevor and Timo's proposal to redo the skin system[1] 2. Within the larger data manipulation area, there is also potential for another split between public information (e.g. pages on public wikis, the vast majority of old revisions, etc) and private information (e.g. pages on private wikis, revdel'ed revisions, CheckUser information). With public information, we can choose technologies that optimize for replication and data delivery (speed and volume). With private information, we can lock things down more, possibly losing efficiency in exchange for greater security. Since private information will presumably be accessed less frequently in most cases, and the limited cases where high frequency access is needed (e.g. authn/authz) typically don't involve a lot of data flow, we can generally make different design decisions. I've also created an RFC that spells this out too: https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_pub… These RFCs are both admittedly vague, somewhat on purpose. It's useful to agree on a general direction before getting down in the weeds on specific proposals. Proposal #1, other than the lack of specificity, is hopefully completely uncontroversial, and thus (maybe with a *little* fleshing out) could sail through the process. Proposal #2 may be a bit more controversial, but something that is worth some discussion. For the specifics on these proposals, the best place to discuss these is the talk page. If/when the conversation dies out there (or if it never really starts), I'll summarize on this list. If there are other sensible places for cleaner fissures in the system, please document where you think they should go. Even if the fissures we define are not boundaries between hardware clusters, but instead just library boundaries, that's still useful to mark where those lines should go. Rob [1] https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework

2 1

MediaWiki will avoid serving SVG images to Opera 12
by Bartosz Dziewoński 16 Feb '15

16 Feb '15

Just a quick note that I have submitted a patch <https://gerrit.wikimedia.org/r/190819> that will make MediaWiki avoid serving SVG images to Opera 12 (the old, Presto-based one) when a PNG fallback is available. We support it as a Grade A browser, which means that we should do our best to provide the best possible experience. In my opinion, the best possible experience involves not giving it any SVGs. Opera 12 has issues when rendering SVG background-images together with border-radius or background-size rules (see task <https://phabricator.wikimedia.org/T87504> for details and examples), and both of these are becoming increasingly common in our codebase. One common complaint was the new MediaWiki UI checkboxes, where the check icon would sometimes not appear for Opera users. -- Bartosz Dziewoński

1 0

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 16 Feb '15

16 Feb '15

Quarterly review minutes and/or slides of the following teams have been posted in recent days: Multimedia: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Legal & Community Advocacy: https://commons.wikimedia.org/wiki/File:LCA_Q2_Slides.pdf (abridged slides only) Fundraising and Fundraising Tech: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Communications: https://commons.wikimedia.org/wiki/File:Communications_WMF_Quarterly_Review… (slides only, as a report - no actual meeting took place) With this, documentation from all 20 quarterly review meetings that took place about Q2 (October-December 2014) has been published. On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB

1 0

RFC meeting this week
by Tim Starling 16 Feb '15

16 Feb '15

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…> Also, we will have a general discussion about services in the second half hour. The meeting will be on the IRC channel #wikimedia-office on chat.freenode.net at the following time: * UTC: Wednesday 21:00 * US PST: Wednesday 13:00 * Europe CET: Wednesday 22:00 * Australia AEDT: Thursday 08:00 -- Tim Starling

1 0

.js errors in Metrolook skins
by Thomas Mulhall 15 Feb '15

15 Feb '15

Hi I am getting js script errors in Metrolook skin. The error is in $(document).click(function(e) { if (!$(e.target).closest('#'+openDiv).length) { toggleDiv(openDiv); } }); and error says Object expected. Source code is at https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook and https://github.com/paladox/Metrolook If I have to split js script out of the MetrolookTemplate.php could I have some help to do that please thanks.

2 4

Modifications list and automated (cron?) task.
by Georges DICK 15 Feb '15

15 Feb '15

Hello. I installed Mediawiki (and a couple of extensions) as an intranet website. Everyone in the company is entitled to publish, so my fear is people missing important information. My idea is to send a weekly e-mail to list every modified pages (link to page, author, last modification date). I started to write a PHP script as a demonstration and it now works pretty well. So I have two questions: - I first unsuccessfully tried to find something similar, but maybe I'm re-inventing the wheel? - If I'm the first to build such a feature, maybe someone else could have some interest in it? If yes, how to publish (this is not an extension, but a standalone software reading a MySQL database)? Georges

3 3

Building an extension management CLI tool (What language should I write it in?)
by Daniel Friesen 15 Feb '15

15 Feb '15

((Jump to the -- TL;DR -- if you just want to answer my question)) Hey guys, right now managing extensions is a complete mess for those of us with a wiki running a dozens of extensions on a VPC. Even if you use git to make things easier. You still need to batch fetch/pull multiple git repos. And then some extensions don't work via git, instead you install them using composer. ((And don't say use mediawiki/extensions.git, that should conflict with composer extensions, doesn't help when an extension uses something like version tags, and appears to have the same issues with bulk updating a few extensions)) I convinced my boss to let me spend some time (when I have no client projects to work on) building a tool to make managing extensions easier for CLI users. Some notes on the idea here: https://www.mediawiki.org/w/index.php?title=User:Dantman/Code_Ideas&diff=13… Please note that this is NOT meant to be the new way we manage extensions forever, this is a hack meant to be used as a workaround to deal with current reality until the grand future when we're supposed to have a complete extension management system built into core with its own web interface. -- TL;DR -- Now, my question. Do you guys want me to build the local tool in PHP as a maintenance script or in node.js? Actually perhaps I should instead ask "Are you guys fine if I build this in node.js?" because I have a feeling this will be hell to develop if I have to write it in PHP. PHP Pros: - We could bundle this with MediaWiki core if people like it. - You don't need to install Node.js (though it's not 'that' hard). PHP Cons: - Every time I've tried using PHP proc functions I've had to spend endless time debugging. And this tool requires dozens of proc calls. - The tool is going to be difficult to access until at least the next MediaWiki version, since it won't be bundled. -- It may end up useless for a bunch of people right now when it's supposed to help. -- It may also end up locked down so only users with more recent installations of MediaWiki may use it ( Node.js Pros: - Once you have node, getting the tool will be as trivial as `[sudo] npm install -g mediawiki-...something...`. - The tool will be available for and should work on any MediaWiki version you can get a current extension to work on, not just future releases. - Executing git and composer from node to download things is trivial. -- I not only expect it to be easy, I'm already doing it. The server code is Node.js and is already happily chugging away fetching all our gerrit based git repos, doing multiple in parallel. - I could make parts of the tool interactive and much more user friendly. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

4 7

Using strpos mutiple times
by Thomas Mulhall 14 Feb '15

14 Feb '15

Hi how can I use strops multiple times I am trying to filter the skins api to only show skins and this wokrs but it only allows you to do one it currently looks like this if ( strpos( $ret['type'] = $type, 'parserhook' ) === 0 ) { continue; } but I would like to get it to do if ( strpos( $ret['type'] = $type, 'parserhook', 'specialpage' ) === 0 ) { continue; } Or is there something simler to this I could use or is there one that allows to express only skin is allowed to show through skin api instead of blacklisting the other types. Please help.

1 1

Google thinks the Anonymous entry on enwp is hacked
by John Mark Vandenberg 14 Feb '15

14 Feb '15

Google is showing their "This site may be hacked." note when showing the enwp article about Anonymous, with a link to <https://support.google.com/websearch?p=ws_hacked> https://www.google.com/search?q=Anonymous+group Found via http://thestack.com/anonymous-this-site-may-be-hacked-wikipedia-120215 -- John Vandenberg

4 5

Who moved my cheese?
by Andrew Garrett 14 Feb '15

14 Feb '15

Hey folks, I'd to modestly propose that we talk about managing/announcing breaking changes to core MediaWiki architecture. I want to have this chat because I spent an hour or two yesterday trying to figure out why changing default configuration options for an extension in MyExtension.php wasn't working. Apparently, now, you also have to change it in extension.json for it to work on Vagrant. I understand that this was a change that was announced on wikitech-l, but I don't think that I'm the only one who thinks that reading wikitech-l isn't a good use of time, compared to, say, doing my job (irony upon ironies, I know). If you want to change the way that things have worked for 11 years, then making engineers understand what they need to do differently is your responsibility, not mine. So, besides huffing and puffing, I have two small proposals: 1. We should have a low-volume list/RSS feed/twitter account/something where we announce major breaking changes like this, that doesn't involve reading 20 emails per day of other stuff that doesn't affect the way I do my job. 2. If we make breaking changes, the change should be really obvious so that I can't spend hours trying to find out what changed. For example, when we did the i18n JSON migration (everybody seems to love JSON these days), and I went to change/add a message, I found that the message file was a completely different format, and I was clued in straight away to the fact that something was different. By contrast, in this case, the way I'd done things for years suddenly stopped working. I've heard it justified in this particular case that this is just a transition period; but it's not just a transition period for code, it's a transition period for practices, and therefore it's the time when it should be the LEAST confusing for engineers who don't care about your refactoring, not the MOST confusing. — Andrew Garrett

8 8

VisualEditor weekly triage meetings – 2015-02-11 – minutes
by James Forrester 14 Feb '15

14 Feb '15

As promised in the meeting, here is are the minutes for the VisualEditor weekly triage meeting on 2015-02-11. *Item 1 – Release criteria* The release criteria at https://phabricator.wikimedia.org/tag/%C2%A7_visualeditor_q3_blockers/ were considered. After a brief discussion, no changes were proposed. *Item 2 – Review of nominated tickets* Nominated tickets accepted: … as corruption & stability issues: - https://phabricator.wikimedia.org/T76998 – Random removal of categories when using Safari - https://phabricator.wikimedia.org/T74048 – [Regression] VE corruption issue(?) moving pre-existing categories to the middle of the page - https://phabricator.wikimedia.org/T89025 – Using keyboard shortcuts (in multiple browsers) or the "Open menu" (in Firefox only) to copy a paragraph and a reference together causes selected content to be deleted (not cut) instead - https://phabricator.wikimedia.org/T88148 – class="wikitable wikitable" corrupted to class="wikitable" - https://phabricator.wikimedia.org/T74579 – Deleting from a paragraph-terminating node to a paragraph-terminating node (?) is throwing "Unbalanced set of replace operations found" - https://phabricator.wikimedia.org/T76715 – Same Category get added multiple times ,for every change in “Sort this page by default as” value - https://phabricator.wikimedia.org/T72375 – Deleting from an empty paragraph to the end of an inline node throws an exception - https://phabricator.wikimedia.org/T70537 – In production, sometimes page scrolling is not working and in the console Getting Error: offset was inside a handlesOwnChildren node in Firefox … as performance issues: - https://phabricator.wikimedia.org/T88386 – ~50ms spent a.oo-ui-buttonElement-button - https://phabricator.wikimedia.org/T76523 – Show the VisualEditor toolbar/editor chrome immediately after the user clicks "edit", rather than blocking on waiting for the content to load - https://phabricator.wikimedia.org/T88650 – Support data-mw.body.id for reference contents - https://phabricator.wikimedia.org/T88623 – VisualEditor should load data-mw from a separate API call alongside the body content - https://phabricator.wikimedia.org/T87553 – API requests to action=visualeditor&paction=parse more than four times slower than requests directly to parsoid-lb … as testing issues: - https://phabricator.wikimedia.org/T74398 – Actually run tests for MWHeadingNode / MWPreformattedNode … as feature issues: - https://phabricator.wikimedia.org/T78202 – Wordbreak detection is faulty for selection starting just down-page of a single character - https://phabricator.wikimedia.org/T88337 – Tools should be able to specify a label for their appearance in the context menu - https://phabricator.wikimedia.org/T76398 – External link interface for link dialogue … as dependencies: - https://phabricator.wikimedia.org/T66171 – Log Parsoid server-side save performance … for investigation and re-triage: - https://phabricator.wikimedia.org/T74929 – Using browser native interactive spell-check when the changed word in the only item in the paragraph causes endless insertions in Firefox - https://phabricator.wikimedia.org/T65462 – Using browser native interactive spell-check tool causing repeated automatic deletion in Chrome Nominated tickets rejected: - https://phabricator.wikimedia.org/T72665 – Tab/Shift-Tab behaviour in contexts other than lists (like tables) This is a nice-to-have feature but it isn't critical to any of the common edit workflows for the user groups targeted right now. - https://phabricator.wikimedia.org/T67589 – Up/down keys in table when you've selected a cell move left/right instead This is a nice-to-have feature but it isn't critical to any of the common edit workflows for the user groups targeted right now. - https://phabricator.wikimedia.org/T52616 – Improve VisualEditor's loading performance in Firefox This is really a tracker bug more than a specific call-to-action. - https://phabricator.wikimedia.org/T55825 – Reduce VisualEditor's memory usage This is a high-level tracker bug rather than a blocker; it needs child bugs with more specifics to be nominated as blockers. - https://phabricator.wikimedia.org/T53798 – There should be help links in every context - dialog boxes, inspectors, etc. We disagree with the premise; instead, there should only be help links where they are useful to explain the complexity of a control to the user. Most of this is already done, and the focus areas for this release don't have this level of complexity required. - https://phabricator.wikimedia.org/T88316 – Preview interface for link dialogue As a product decision, we decided to remove this as a blocker to the release, and instead focus on the citation improvements first before taking this on. - https://phabricator.wikimedia.org/T86693 – Alter the toolbar and dropdown menu design As a product decision, we decided to remove this as a blocker to the release; instead, this potentially will be part of our polish effort instead. *Item 3 – Other business* The process was very briefly discussed, without suggestion of changes. Hope this is of interest. Next week's meeting will be at 16:00 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150218T08&p1=224…> (08:00 PST) on Wednesday 18 February; hope to see many of you there. Joining instructions are on mw:Talk:VisualEditor/Portal <https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal#How_to_join_the_tri…> for those who didn't make it this week. Yours, -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

Flame graphs in Chrome / Chromium
by Ori Livneh 14 Feb '15

14 Feb '15

Hello, The timeline and flame graph features of Chrome's DevTools have been very useful for us as we work to understand and improve the performance of VisualEditor. Someone asked me today about how we use these tools, so I recorded a short (3-minute) screencast. It unfortunately cut off near the end, but only the last sentence or so got clipped. https://commons.wikimedia.org/wiki/File:Demonstration_of_Chromium%27s_timel… T88590 is a good example of a bug we caught using this feature: https://phabricator.wikimedia.org/T88590 Hope it's useful, Ori

2 2

Re: [Wikitech-l] OOjs and OOjs UI for on-wiki gadgets
by Jon Robson 13 Feb '15

13 Feb '15

I recently hit the exact same issue. It's a useful widget but has no demos (see https://phabricator.wikimedia.org/T85467) Luckily after a week of fiddling Florian and I have two demos that are working. The code in the following patches should help you work out. I understand that Andrew Garret is setting up a demo site. I wonder if during the dev summit we could get s demo for this done and on it? https://gerrit.wikimedia.org/r/181225 https://gerrit.wikimedia.org/r/180880 On 10 Jan 2015 04:37, "Ricordisamoa" <ricordisamoa(a)openmailbox.org> wrote: Thanks. I eventually managed to use ProcessDialog and several widgets in a script of mine <https://it.wikipedia.org/wiki/Utente:Ricordisamoa/PDC.js>. I just couldn't make LookupInputWidget work (phab:T85467 < https://phabricator.wikimedia.org/T85467>, mw:Talk:OOjs UI#OO.ui.LookupInputWidget vs jQuery autocomplete < https://www.mediawiki.org/wiki/Talk:OOjs_UI#OO.ui. LookupInputWidget_vs_jQuery_autocomplete>), and had to fall back to jQuery UI's autocomplete. The 'solution' I've come up with is, more or less: var widget= new OO.ui.TextInputWidget(); widget .$input .autocomplete( { source: function ( request, response) { response( [ request.term + 'test 1', request.term + 'test 2', request.term + 'test 3' ] ); } } ); Very few examples can be found of LookupInputWidget. Does anyone have any hints about it? Il 19/10/2014 17:49, Bartosz Dziewoński ha scritto: OOUI is reasonably stable and can be used in gadgets, if you wish to. > There is some high-level documentation and several examples at > https://www.mediawiki.org/wiki/OOjs_UI and complete API reference at > https://doc.wikimedia.org/oojs-ui/master/ . > > Breaking changes still can sometimes happen and when they do, they are not > being announced very widely (they're just committed with "BREAKING CHANGE" > in the subject line). If you start using OOUI and something that used to > work suddenly breaks, please complain at #mediawiki-visualeditor. > > _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

3 5

New recent changes library for .Net
by Petr Bena 13 Feb '15

13 Feb '15

Hi Some of you who use JS and Python were probably excited about deployment of new RCStream (1) and some of you who use .Net were probably disapointed how complex it is to get it, JSON and websockets.IO running on .Net in order to get it working. Here I made a super simple C# library that utilizes a XmlRcs (2) proxy to RCStream using only native .Net libraries that are provided by microsoft and mono. That means this library is working out of the box anywhere. You can get it here: https://github.com/huggle/XMLRCS/tree/master/clients/c%23/XmlRcs This library makes it extremely simple for anyone to connect to wikimedia recent changes stream for any WMF project and hook event to any change made to wiki. This would be probably very useful for .Net bots and tools. Let me know if you needed any help or improvements, or just use that github tracker! Have fun 1 http://wikitech.wikimedia.org/RCStream 2 http://wikitech.wikimedia.org/XmlRcs

1 0

[x-post] Language Engineering IRC Office Hour on 18 February 2015 (Wednesday) at 1300 UTC
by Runa Bhattacharjee 13 Feb '15

13 Feb '15

[X-posted announcement] Hello, The next monthly IRC office hour of the WMF Language Engineering team will be on February 18, 2015 (Wednesday) at 1300 UTC on #wikimedia-office. Please note that for this instance the session has been set to a much earlier hour. We will be taking questions and discussing about our ongoing projects, particularly the recent activation of Content Translation as a beta feature on several Wikipedias[1]. We’d love to hear comments, suggestions and any feedback that will help us make this tool better. Please see below to check local time and event details. Logs from our earlier office hours are available at: https://meta.wikimedia.org/wiki/Category:Language_Engineering Thanks Runa [1] http://blog.wikimedia.org/2015/01/20/try-content-translation/ Monthly IRC Office Hour: ================== # Date: February 18, 2015 (Wednesday) # Time: 1300 UTC (Check local time: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150218T1300) # IRC channel: #wikimedia-office # Agenda: 1. Ongoing projects - Content Translation beta feature 2. Q & A (Questions can be sent to me ahead of the event) -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation

1 0

Vendro api in MediaWiki
by Thomas Mulhall 13 Feb '15

13 Feb '15

Hi does vendor have an api like the extension api which tells you name of the extension and version. Because I have ask for WikiApriary to support vendor in there tracking wiki site and they are asking for the api.

3 3

Fix problem with CollapsibleVector
by Thomas Mulhall 13 Feb '15

13 Feb '15

Hi could I have some help to fix a problem that a user reported on the extension talk page. The talk page is at http://www.mediawiki.org/wiki/Extension_talk:CollapsibleVector and the title is flickering. I am not sure how to fix the problem I was wandering if someone on here knew how to fix the problem. the source code is at https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCollapsibleVector

1 2

Investigating building an apps content service using RESTBase and Node.js
by Dan Garry 12 Feb '15

12 Feb '15

*tl;dr: Mobile Apps will, in partnership with the Services, investigate building a content service for the Mobile Apps.* The Mobile Apps Team currently has quite a few pain points with the way we fetch article content currently: - We have to make a lot of API requests to load an article: article HTML, lead image, read more recommendations, and more - We send the user HTML that we then discard, needlessly increasing data usage - We do transforms to the HTML in JavaScript on the client side, which causes code duplication across the apps and degrades user-perceived performance - Trivial changes to the API (e.g. renaming a parameter) can break the app which is problematic since apps can't be hotfixed easily To address these challenges, we are considering performing some or all of these tasks in a service developed by the Mobile Apps Team with help from Services. This service will hit the APIs we currently hit on the client, aggregate the content we need on the server side, perform transforms we're currently doing on the client on the server instead, and serve the full response to the user via RESTBase. In addition to providing a public API end point, RESTBase would help with common tasks like monitoring, caching and authorisation. So the Mobile Apps Team is going to spend a bit of time investigating whether using RESTBase with Node.js is an option for building a content service for the Wikipedia app to replace our current method of retrieving article content. Our initial scope for this is feature parity with our current content retrieval method. Our action items are as follows: - Wait for RESTBase to be deployed. - Timescale: Weeks - Owner: All of us :-) - Figure out what information the service should serve for the first iteration (i.e. for feature parity) and what APIs it needs to hit to do that - Timescale: Wed 4th Feb - Owner: Dan Garry - Start implementing the service and see whether it meets our needs - Timescale: Planning a spike for next apps sprint (16th Feb - 27th Feb) to perform initial investigation - Owner: Currently undecided engineer from Mobile Apps, with Services engineers serving as consultants As always, feel free to ask if there are any questions. Dan

16 23

Abandoned Labs tools
by Mr. Donald J. Fortier II 12 Feb '15

12 Feb '15

Please comment on https://meta.wikimedia.org/wiki/Requests_for_comment/Abandoned_Labs_tools that I created per https://phabricator.wikimedia.org/T87730 to create a process for usurping or otherwise being added as a maintainer to existing tools which appear to be abandoned. As Coren points out, the following three questions need some consideration: - Under what criteria are tools considered "abandoned" and subject to being handed to someone else? - To whom are abandoned tools handed over? - What happens to credentials a tool may hold (for instance, bot accounts, OAUTH secrets, etc). I've also requested that a one-liner about this topic be added to the next tech news https://meta.wikimedia.org/w/index.php?title=User_talk:Guillaume_%28WMF%29&…

1 0

Cross-wiki template
by Petr Bena 12 Feb '15

12 Feb '15

Hi, Is it possible to use template from english wikipedia on a different wiki (meta in this case)? Something like {{w:Template}}. I couldn't find this anywhere. I don't want to export it, I want to be able to change it on 1 wiki so that change gets everywhere else as well.

3 4

OOjs UI 0.7.0 release
by Trevor Parscal 12 Feb '15

12 Feb '15

*OOjs UI 0.7.0* has been released today. It will be in MW from 1.25wmf18+. We've tried hard to avoid breaking changes when possible, but occasionally they will happen. The last time there were breaking changes in a release was 2014-12-16 (wmf13), 137 OOjs UI commits ago. *Breaking changes since last release:* - [BREAKING CHANGE] Remove window isolation (Trevor Parscal) Window isolation is a feature we introduced to solve certain problems in VisualEditor a while back. It essentially places the content of a window inside an iframe. We've since made improvements to VisualEditor to no longer need this, and are happy to finally be able to remove this rather problematic part of OOjs UI. We are not aware of anyone using this feature, so it should have no effect on code in production. We are also trying to make it easier on users of the library to stay up to date more proactively by publicizing deprecations for at least one release cycle before a related breaking change occurs. *Deprecated changes since last major release:* - DEPRECATION: GridLayout should no longer be used, instead use MenuLayout (Bartosz Dziewoński) GridLayout is a 2D proportional grid container that turned out to be difficult to have features we didn't need and lacked many we did need. The only uses of GridLayout have been removed, and we are planning to remove it in an upcoming release. The shiny new MenuLayout is a much simpler solution, providing a 2-pane split layout that is better suited to the needs we actually have. - DEPRECATION: LookupInputWidget should no longer be used, instead use LookupElement (Bartosz Dziewoński) In response to some feedback about using LookupInputWidget being complex and inflexible, we've changed strategies and are now providing lookup behavior through a mixin called LookupElement. Also, I'd especially like to thank the volunteers and early-adopters who contributed to this release. - C. Scott Ananian - Derk-Jan Hartman - Ricordisamoa - eranroz If you have any further questions or need help dealing with deprecations, please let me know. General library documentation is available at mediawiki.org <https://www.mediawiki.org/wiki/OOjs_UI> and generated code-level documentation at doc.mediawiki.org <https://doc.wikimedia.org/oojs-ui/master/#!/api>. - Trevor

1 0

Why there is no authentication mechanism for desktop applications
by Petr Bena 11 Feb '15

11 Feb '15

Hi, We have OAuth for browser based programs. But nothing for desktop applications that are being used by users. (Like AWB etc). These applications now have to ask for password, which is kind of safe given that they are open source and running on computer of the user, so at some point giving them password is as much insecure as giving it to your we browser, but still, I believe that there could be slightly better security model in use, that would make it safe to provide password to a program that was compiled by anyone and that can be potentially unsafe. Let's take this sample model similar to OAuth: * User would have extra panel in preferences, where they could generate access tokens. * For each token user could specify what application would have access to. Generated tokens would be given to application instead of login and password and the application could use them to login into mediawiki. Users could revoke the tokens in anytime effectively invalidating any tokens that potential hacker could steal using that 3rd application. It sounds pretty simple to me, so why we don't have anything like that?

3 4

Scrum of Scrums notes 2015-02-11
by Dan Andreescu 11 Feb '15

11 Feb '15

https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-02-11 If anyone with better wiki kung fu than me could take a look and figure out why the table of contents is not rendering on that page like it does on all the other [1] ones, I would appreciate it. [1] https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-02-04

3 2

Reminder: Weekly VisualEditor triage meeting tomorrow at 20:00 UTC (12:00 PST)
by James Forrester 10 Feb '15

10 Feb '15

[Apologies for cross-post] As a reminder, on Wednesday, 11 February 2015 at 12:00 (noon) PST (20:00 UTC)[0] there will be the first of a weekly series of open triage meetings about VisualEditor. We will discuss the release criteria for VisualEditor, and jointly prioritise the work of the team, talking about the bugs and features which are most important to you. We particularly welcome the presence of volunteers who enjoy contributing MediaWiki code. The joining instructions are available on MediaWiki.org[1]. Hope to see many of you there. [0] - http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150211T12&p1=224… [1] - https://www.mediawiki.org/wiki/Talk:VisualEditor/Portal Yours, -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

Fwd: [Wmfall] Wikimania Scholarship Application Deadline is Approaching!
by Quim Gil 10 Feb '15

10 Feb '15

---------- Forwarded message ---------- From: Ellie Young <eyoung(a)wikimedia.org> Date: Mon, Feb 9, 2015 at 8:55 PM Subject: [Wmfall] Wikimania Scholarship Application Deadline is Approaching! To: wikimedia-l(a)lists.wikimedia.org, Wikimania general list < wikimania-l(a)lists.wikimedia.org>, Staff All <wmfall(a)lists.wikimedia.org> The deadline for applying for a Scholarship to attend Wikimania 2015 in Mexico City on July 15-19 is a week away! ** Monday 16 February 2015 23:59 UTC ** Please spread the word to anyone you know who might qualify. A scholarship will cover the cost of an individual's round-trip travel, shared accommodation, and conference registration as arranged by the Wikimedia Foundation. Applicants will be rated using a pre-determined selection process and selection criteria by the Scholarship Committee, who will determine which are successful. To learn more about Wikimania 2015 scholarships, please visit: https://wikimania2015.wikimedia.org/wiki/Scholarships To apply for a scholarship, fill out the application form on: https://scholarships.wikimedia.org/apply It is highly recommended that applicants review all the material on the Scholarships page and the associated FAQ before submitting an application. If you have any questions, please contact: wikimania-scholarships at wikimedia.org or leave a message at: https://wikimania2015.wikimedia.org/wiki/Talk:Scholarships Thank you, Ellie Young WMF Conference Coordinator on behalf of the Scholarship Committee _______________________________________________ Wmfall mailing list Wmfall(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Main themes of the Wikimedia and Wikimania hackathons this year
by Quim Gil 10 Feb '15

10 Feb '15

The MediaWiki Developer Summit had three main themes that helped structuring the schedule. These themes were useful, and they can be more useful for the hackathons in Lyon and Mexico City this year, since defining them indvance will help everybody organizing their travel. Anybody can propose a main theme at https://phabricator.wikimedia.org/T89084 Good candidates include Wikimedia software priorities, project meetings, collaboration with external projects, topics of local relevance... Do not hesitate posting proposals even if they are just an initial idea right now. We want to agree on the main themes by the end of next week in order to help people organizing their travel plans. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Wikitech.wikimedia.org read-only, possible outage, 2015-02-10 0:00GMT
by Andrew Bogott 10 Feb '15

10 Feb '15

There were several short wikitech outages last week caused by heavy machine load on the server that (among other things) hosts the site. In an attempt to distribute load a bit more reasonably I'm migrating that web host to new hardware. The transition should be fairly graceful as the new host is already up and running. There will be a few interruptions in service, though: - During the move the new wiki will be read-only. This should only last about 10 minutes or so during the DNS switch-over. - After the move there will almost certainly be a series of mishaps involving the labs-controlling aspects of wikitech. I'll be scrambling to fix them and don't expect to spend more than hour or so; I'll follow up with another email if the interruption is an longer than that. - As usual, login sessions will probably be broken necessitating a fresh login to wikitech. This is scheduled for Midnight GMT Tuesday, February 10th. That's 4PM PST on Monday.

1 2

Urlencoding strip markers
by Arlo Breault 10 Feb '15

10 Feb '15

Currently, while {{urlencod}}ing, content in strip markers is skipped. I believe this violates the expectation that the entire output will be properly escaped to be placed in a sensitive context. An example is in the infobox book caption on, https://en.wikipedia.org/wiki/%22F%22_Is_for_Fugitive There’s a brief discussions of the security implications of some proposed solutions in the review of, https://gerrit.wikimedia.org/r/#/c/181519/ It seems best (I guess) to just drop the content (`killMarkers()`). Any opinions or better ideas? Thanks, Arlo

5 9

Re: [Wikitech-l] [Engineering] Announcement: Tyler Cipriani joins Wikimedia as Release Engineer
by Kristen Lans 10 Feb '15

10 Feb '15

Welcome Tyler! Great to have you on board. On Mon, Feb 9, 2015 at 5:35 PM, Emily Blanchard <eblanchard(a)wikimedia.org> wrote: > Welcome Tyler! > > > > > > > Emily Blanchard > Talent Acquisition Team > Wikimedia Foundation > eblanchard@wikimedia. <eblanchard(a)gmail.com>org > Follow us on Twitter @wikimediaatwork > http://wikimediafoundation.org/wiki/Home > Become a Contributor: https://en.wikipedia.org/wiki/Wikipedia:Teahouse > Join Us: http://wikimediafoundation.org/wiki/Work_with_us > Developers Join the Fun: http://www.mediawiki.org/wiki/Communication > > > *Imagine a world in which every single human being can freely share inthe > sum of all knowledge. Help us make it a reality!* > > On Mon, Feb 9, 2015 at 1:39 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote: > >> Welcome, Tyler! I'm looking forward to working together. >> >> On Mon, Feb 9, 2015 at 1:28 PM, Greg Grossmeier <greg(a)wikimedia.org> >> wrote: >> >>> Hello all, >>> >>> I’m delighted to announce that Tyler Cipriani[0] is joining the >>> foundation as a Release Engineer (obviously joining the Release >>> Engineering team). >>> >>> Tyler lives (and will continue to work remotely from) where you can see >>> the Flatirons[1] in Colorado and comes to us from SparkFun[2] where he >>> was a web developer and sysadmin. >>> >>> Along with the Wikimedia Foundation being a great fit professionally for >>> Tyler (I’m biased maybe) he is also “thrilled to be working at an >>> organization whose values seemingly so closely align with [his] own.” >>> >>> He’ll be at the San Francisco office the week of the 16th and is seeking >>> any suggestions as to what he should do with his free afternoon on >>> Presidents’ Day. >>> >>> Please join me in welcoming Tyler! >>> >>> Greg >>> >>> >>> [0] https://tylercipriani.com/ >>> [1] https://en.wikipedia.org/wiki/Flatirons >>> [2] https://www.sparkfun.com/ >>> >>> -- >>> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | >>> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | >>> >>> _______________________________________________ >>> Engineering mailing list >>> Engineering(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/engineering >>> >>> >> >> >> -- >> Dan Duvall >> Automation Engineer >> Wikimedia Foundation <http://wikimediafoundation.org> >> >> _______________________________________________ >> Engineering mailing list >> Engineering(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/engineering >> >> > > _______________________________________________ > Engineering mailing list > Engineering(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/engineering > >

3 2

Announcement: Tyler Cipriani joins Wikimedia as Release Engineer
by Greg Grossmeier 10 Feb '15

10 Feb '15

Hello all, I’m delighted to announce that Tyler Cipriani[0] is joining the foundation as a Release Engineer (obviously joining the Release Engineering team). Tyler lives (and will continue to work remotely from) where you can see the Flatirons[1] in Colorado and comes to us from SparkFun[2] where he was a web developer and sysadmin. Along with the Wikimedia Foundation being a great fit professionally for Tyler (I’m biased maybe) he is also “thrilled to be working at an organization whose values seemingly so closely align with [his] own.” He’ll be at the San Francisco office the week of the 16th and is seeking any suggestions as to what he should do with his free afternoon on Presidents’ Day. Please join me in welcoming Tyler! Greg [0] https://tylercipriani.com/ [1] https://en.wikipedia.org/wiki/Flatirons [2] https://www.sparkfun.com/ -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

4 3

Beta bounce handling completed with new beta-mx
by Tony Thomas 09 Feb '15

09 Feb '15

Hello, Happy to inform that beta got is now routing through its new working mx ( mx.beta.wmflabs.org ). We had discussions regarding adding a separate mx for beta back in[1] and [2]. Today, we have the mx records added for beta ( dig +short -t mx beta.wmflabs.org ) and beta is sending out mails with a $domain part set as beta.wmflabs.org and bounces coming right back to it. This would make us testing patches related to polonium easy as we never had a polonium equivalent in beta. BounceHandler is working perfectly in the cluster, and bounces are redirected to the API installed in deploymentwiki[3]. In the production cluster, we still have the deployment to group0 wikis[4], which we hope to get done soon. Thanks to Jeff, hoo, Yuvipanda and other devs for the fast deployment and discussions. [1] https://lists.wikimedia.org/pipermail/labs-l/2014-October/002977.html [2] https://phabricator.wikimedia.org/T88215 [3] deployment.wikimedia.beta.wmflabs.org [4] https://gerrit.wikimedia.org/r/#/c/186242/ Thanks, Tony Thomas <http://tttwrites.wordpress.com/> FOSS@Amrita <http://foss.amrita.ac.in> *"where there is a wifi, there is a way" *

2 3

Use of hreflang in the <head>
by Erik Moeller 09 Feb '15

09 Feb '15

Hi folks, MediaWiki emits the hreflang attribute on language links, but only as part of the links in the body, and not in the <head> as recommended by Google [1]. The result of this is that Google (and possibly other search engines) doesn't interpret the hreflang attribute for purposes of prioritizing search results in the user's own language. >From a contact at Google we asked about this: "we currently don't use those annotations on the links, we need to see the hreflang link-elements in the head in order to understand that connection. The important parts there are the we need to have them in the "head", we need to have them confirmed from the other versions (so DE needs to refer to EN, and EN to DE -- it can't be one-sided), and it needs to be between the canonical URLs. (...) I imagine if you just added the cross-links as you have them in the sidebar as link-elements to the head then you'd be covered." This of course would add some additional payload to pages with lots of language links, but could help avoid results like [2] where the English language version of an article is #1 and the Indonesian one makes no appearance at all. Results vary greatly and it's hard to say how big a problem this is, but even if boosts discoverability of content in the user's language by only 10% or so, that would still be a pretty big win for local content. I'm curious if folks see any downside, other than the additional page payload, in adding this information to the page header. Given the time it takes for the index to be updated, we should be careful about any potential negative consequences. Thanks, Erik [1] https://support.google.com/webmasters/answer/189077?hl=en [2] https://www.google.co.id/?gws_rd=ssl#q=edison -- Erik Möller VP of Product & Strategy, Wikimedia Foundation

4 3

jenkings merging
by Thomas Mulhall 09 Feb '15

09 Feb '15

Hi how do I get my skins and extensions to be merged automatically by jenkings like it does on centralauth projects are at https://git.wikimedia.org/summary/mediawiki%2Fskins%2FMetrolook and https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCollapsibleVector

4 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2015