Wikitech-l August 2014

wikitech-l@lists.wikimedia.org

133 participants
137 discussions

People with knowledge of English swear words needed :o
by Petr Bena 20 Nov '14

20 Nov '14

Are you good in swearing? WE NEED YOU Huggle 3 comes with vandalism-prediction as it is precaching the diffs even before they are enqueued including their contents. Each edit has so called "score" which is a numerical value that if higher, the edit is more likely a vandalism. If you want to help us improve this feature, it is necessary to define a "score words" list for every wiki where huggle is about to be used, for example on English wiki. Each list has following syntax: (see https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config&diff=573…) score-words(score): list of words separated by comma, can contain newlines but comma must be present example score-words(200): these, are, some, words, which, presence, of, increases, the, score, each, word, by, 200, So, if you know english better than me, which you likely do, go ahead and improve the configuration file there, no worries, huggle's config parser is very syntax-error proof. If you have any other suggestion how to improve huggle's prediction, go ahead and tell us!

8 8

OOjs, MobileFrontend and Flow
by Jon Robson 20 Sep '14

20 Sep '14

Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside the mobile and Flow projects. The following 3 patches kicks off moving MobileFrontend's class model towards that of oojs - many thanks for Roan for doing most of the legwork :-): https://gerrit.wikimedia.org/r/155593 https://gerrit.wikimedia.org/r/155589 https://gerrit.wikimedia.org/r/129336 On the long term we'd look to swap out the Class.js and eventemitter.js files in MobileFrontend for oojs, but this is going to be tricky and require some care, possibly mixing both oojs and MobileFrontend's class code in the repository at the same time. e.g. increasing JavaScript on the short term, but reducing it on the longterm. The MobileFrontend core development team will need to work out how best to manage this transition. Since Flow is very DOM-focused, as opposed to many smaller JavaScript modules with element management per the currently-accepted use of OOjs, it is unclear how we may go about integrating with OOjs fully. However, some potential use cases have been identified as candidates for implementing OOjs on an interim basis, primarily by abstracting some current FlowBoardComponent workflows, such as those which handle (re-)rendering of existing and new content fetched from the API.

3 6

Status of collation config updates?
by Bartosz Dziewoński 17 Sep '14

17 Sep '14

Hi, There are currently three pending patches to change category collation configuration for various Wikimedia wikis: https://gerrit.wikimedia.org/r/140580 https://gerrit.wikimedia.org/r/147922 https://gerrit.wikimedia.org/r/154213 (This generally makes it so that accented letters like 'é' or 'ą' are not sorted at the end of lists, after 'z', and fixed ordering for languages with interesting alphabets; see https://www.mediawiki.org/wiki/Manual:$wgCategoryCollation.) I have previously been told that these are on hold because of WMF's Trusty migration and the need to rebuild all existing collation data. (No one told me how long that might take, but by my estimates that can't possibly take more than two or three weeks, and I know for a fact that it can be done with no downtime and minimal problems.) That was about two months ago. Is anything known about the current status of the collation things, and the Trusty migration in general? Is there any public venue that I could follow to know what is going on, or at least a private one I could be cc'd on if I asked pretty-please? Is there any ETA, even vague, as to when things might get done? I would like to update the bugs that are stuck with this information. -- Matma Rex

2 4

Disabling JS support in additional browsers
by Erik Moeller 12 Sep '14

12 Sep '14

Following up on disabling JavaScript support for IE6 [1], here is some additional research on other browsers. I'd appreciate if people with experience testing/developing for/with these browsers would jump in with additional observations. I think we should wait with adding other browsers to the blacklist until the IE6 change has been rolled out, which may expose unanticipated consequences (it already exposed that Common.js causes errors in blacklisted browsers, which should be fixed once [2] is reviewed and merged). As a reminder, the current blacklist is in <resources/src/startup.js>. As a quick test, I tested basic browsing/editing operation on English Wikipedia with various browsers. Negative results don't necessarily indicate that we should disable JS support for these browsers, but they do indicate the quality of testing that currently occurs for those browsers. Based on a combination of test results, unpatched vulnerabilities and usage share, an initial recommendation for each browser follows. Note that due to the heavy customization through gadgets/site scripts, there are often site-specific issues which may not be uncovered through naive testing. == Microsoft Internet Explorer 7.x == Last release in series: April 2009 - Browsing: Most pages work fine (some styling issues), but pages with audio files cause JavaScript errors (problem in TMH). - Editing: Throws JS error immediately (problem in RefToolbar) Both of these errors don't occur in IE8. Security vulnerabilities: Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as "moderately critical" (which is the same as IE6, while the most serious IE8 vulnerability is rated "less critical"). Usage: <1% Recommendation: Add to blacklist == Opera 8.x == Last release in series: September 2005 Browsing/editing: Works fine, but all JS fails due to a script execution error (which at least doesn't cause a pop-up). Security: Secunia reports 0 unpatched vulnerabilities (out of 26). Usage: <0.25% Recommendation: Add to blacklist == Opera 10.x-12.x == Last release in series: April 2014 Browsing/editing: Works fine, including advanced features like MediaViewer (except for 10.x) Security: No unpatched vulnerabilities in 12.x series according to Secunia, 2 unpatched vulnerabilities in 11.x ("less critical") and 1 unpatched vulnerability in 10.x ("moderately critical") Usage: <1% Recommendation: Maintain basic JS support, but monitor situation re: 10.x and add that series to blacklist if maintenance cost too high == Firefox 3.6.* == Last release in series: March 2012 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Firefox 3.5.* == Last release in series: April 2011 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Safari 4.x == Last release in series: November 2010 Browsing/editing: Works fine Security: 1 unpatched "highly critical" vulnerability according to Secunia ("exposure of sensitive information") Recommendation: Maintain basic JS support, but monitor == Safari 3.x == Last release in series: May 2009 Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all Security: 2 unpatched vulnerabilities, "highly critical" Usage share: Usage reports for Safari in [3] are broken, all Safari versions are reported as "0.0". However, [4] suggests that Safari 3 usage is negligible/non-existent. Recommendation: Styling issue may be worth investigating in case it affects other browsers and/or is JS-caused. Otherwise probably can be safely ignored. [1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html [2] https://gerrit.wikimedia.org/r/#/c/152122/ [3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-ver… -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

7 9

Standardising icons across projects
by Jon Robson 10 Sep '14

10 Sep '14

Since we had the luxury of having several people in the office, Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat down to talk about the problem we currently have of having no standard way to create icons. Here is my write up of this meeting, again, if you attended please add/correct me on anything and if you were not please ask for clarification where needed. Currently we have two modes of creating icons in MediaWiki 1) Using a font 2) Using SVGs with PNG fallbacks and the markup varies depending on what extension you look at. We discussed both approaches and advantages and disadvantages of each. One of the major disadvantages of the WikiFont is the additional HTTP request it creates to download the font and cannot be embedded in the stylesheet using data uris like SVGs can (due to URL size restrictions). One of the major advantages of WikiFont is you can design a grayscale icon, and style it using font colour. Shahyar was happy to move Flow to using SVG based fonts if we could build grayscale SVGs and change their colours using ResourceLoader. One concrete example is when you have an icon used in a constructive anchor. The icon needs to be green, but when hovered over a lighter green. Another advantage brought up by May was that currently she finds it much easier to build icons in this way, and that having to maintain separate coloured versions of the SVGs is a pain point to her. We decided that we should push towards using SVGs that can be built into fonts for the purpose of the app. As next steps 1) Monte to explore using SVGs in the Wikipedia apps. He will create font from SVGs. He will work with May to ensure her workflow is as easy as before. 2) Trevor is going to look into how we can automatically generate different colour versions of SVGs and automatically create PNGs from them. 3) I am going to aim to agree on a standard icon HTML markup for mediawiki ui. We still have an issue with the fact that everyone is using different HTML markup to create icons. After reviewing all our current approaches [1] it was clear that we were relatively closely aligned and that it simply is a case of agreeing on class names. We aim to get all the above done by Sept 15th, 2014 so please poke us on the mailing list if you haven't had a follow up then. Full disorganised notes can be found here [2]. [1] https://www.mediawiki.org/wiki/Icon_standardisation [2] http://etherpad.wikimedia.org/p/Icon_standardisation

3 4

The future of skins
by Jon Robson 10 Sep '14

10 Sep '14

Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :) Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags. Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not. We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing) As next steps we agreed to do the following: 1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September. 2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library

13 22

UploadWizard bug triage on Sep 09, 17:00UTC
by Andre Klapper 09 Sep '14

09 Sep '14

Heja everybody, you are invited to join us on the next Bugday: Tuesday, September 09, 2014, 17:00 to 19:00UTC [1] in #wikimedia-multimedia on Freenode IRC [2] We will take a look at open Bugzilla tickets for UploadWizard. Everyone is welcome to join. No technical knowledge needed! It's an easy way to get involved or to give something back. More information can be found here: https://www.mediawiki.org/wiki/Bug_management/Triage/20140909 For more information on triaging in general, check out https://www.mediawiki.org/wiki/Bug_management/Triage See you there? andre [1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html [2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 1

Using magic functions (e.g. __get) to deprecate class members
by Stephan Gambke 08 Sep '14

08 Sep '14

TL;DR: Please review [1] I was asked to discuss the topic on the mailing list, so here goes. Since some time Siebrand is making an effort to improve code quality by making it phpcs-strict compliant [0]. This involves explicitly declaring the visibility of class members. Alas, intended or not, in very many cases he did not only explicitly declare the class variable's visibility, but he also changed it from the implicit 'public' to explicit 'protected' or 'private', thus introducing a major API change without a proper deprecation period. Apparently this was not noticed (or at least not challenged) by the reviewers. I checked a few of his commits and they were all merged within hours. Now, to be clear about that, I appreciate both changes - the phpcs compliance as well as the more limited accessibility of class variables. This was long overdue. However, to introduce something like this a proper deprecation period is in my opinion essential, in particular considering the extent of the changes. I do believe that Siebrand checked that the variables he declared protected or private were not used by extensions. However, he missed one (EditPage::mTokenOk) which subsequently resulted in a bug in an extension (SemanticForms). Given the number of the now newly hidden variables I am quite sure, that there are other cases. If only because many extensions are not hosted on WMF servers, so they can not be checked. To keep the changes and still be able to properly deprecate the direct access to the member variables I submitted a patch [1] that makes use of PHP magic functions [2]. They provide access to the class members and issue a deprecation warning. The intention is to keep these functions for the custom two releases [3], i.e. until 1.26, and then remove them. This patch was shot down for three reasons: <quote> * it duplicates code * there is no tests * our code base barely use the magic methods and I am pretty sure Tim Starling commented a while back about them being nasty. </quote> When I pointed out, that these functions are not re-entrant and thus Tims warning [4] did not apply the answer was "I have merely copy pasted Tim comment without even attempting to understand what it means". I was subsequently asked to present this to the mailing list which I do with this mail. I would appreciate comments on the patch (preferably constructive), that would allow us to not revert Siebrand's changes and still properly deprecate formerly public class members. Thanks. Stephan [0] https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+bra… [1] https://gerrit.wikimedia.org/r/#/c/151370/ [2] http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overlo… [3] https://www.mediawiki.org/wiki/Deprecation [4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504

3 5

Simplest UI for creating & editing Phabricator tasks
by Quim Gil 02 Sep '14

02 Sep '14

Hi, Users of the future Wikimedia Phabricator will have a very simple and straightforward interface to create and edit tasks. Bugzilla's UI was one of the top complaints from new/casual users, and we can fix this in Phabricator easily. Currently we are testing this setup in fab.wmflabs.org, where you can see an example: http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points" field is not there). Advanced users needing to prioritize tasks, assign them to someone, and resolve them can join the Triagers team in order to get the additional permissions: http://fab.wmflabs.org/project/view/74/ We are still fine tuning this process at http://fab.wmflabs.org/T64 -- your feedback is welcome. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

4 8

Watchlist and Echo
by svetlana 01 Sep '14

01 Sep '14

Hi all. I've noticed Echo has a separate special page, Special:Notifications. Would we like to rewrite the extension so that it adds entries to the watchlist instead? (And add 'Edits' tab into echo itself - put the watchlist items there). There is a lot of Special: pages already and adding new ones doesn't - immediately - appear to help usability. svetlana

2 2

Jump to page:

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 August 2014