Wikitech-l February 2015

wikitech-l@lists.wikimedia.org

134 participants
140 discussions

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 05 Mar '15

05 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

Jump to page:

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