Wikitech-l December 2013

wikitech-l@lists.wikimedia.org

125 participants
119 discussions

Module storage is coming
by Ori Livneh 23 Jan '14

23 Jan '14

The roll-out of 1.23wmf2 to your favorite Wikimedia wiki will inaugurate the era of ResourceLoader module storage -- an era which will be marked by terrifying and hilarious new bugs, intermittent client-side failures, and generally inexcusable disruptions to user experience. Sounds exciting? Read on! What is it? ----------- "Module storage" refers to the use of localStorage in ResourceLoader as an auxiliary to the browser cache. ResourceLoader, remember, is the MediaWiki subsystem that delivers JavaScript and CSS to your browser. One of its primary functions is to minimize the total number of network requests that your browser needs to make in order to render the page, and to make the remaining requests as slim as possible. One of the ways ResourceLoader does this is by making a list of all the different components your browser needs and then transmitting them in bulk. The downside of this approach is that a small update to MediaWiki's code, touching perhaps one or two components, will often force the browser to throw out (and re-retrieve) a bunch of unrelated modules that did not change and did not ostensibly need to be re-retrieved. This is because the browser cache operates on the level of network requests; it is not intelligent enough to decompose a request into its constituitive parts and to cache these parts separately from one another. Starting with the 1.23wmf2 branch, ResourceLoader will check if your browser implements localStorage, a mechanism for storing structure data. If it does, ResourceLoader will use it as an auxiliary cache, capable of versioning individual components. Why? ---- The primary goals are: * Destabalize MediaWiki's front-end code, by coupling it to an inconsistently-implemented and poorly-understood HTML5 API. * Make debugging fun again, by adding another layer of caching to MediaWiki. Yes!! However, as with all new features, unintended side-effects are possible. Specific concerns for module storage include the risk of making the network footprint of page loads smaller, resulting in improved latency. But seriously, -------------- * Module storage is enabled only if the underlying browser supports localStorage (~89% of browsers in use, according to <http://caniuse.com/#feat=namevalue-storage>). Users with older browsers will not see a benefit, but they will not suffer a penalty either. * Module storage may or may not improve site performance. We need to test it against a wide range of browsers and platforms to know for certain. If it doesn't improve performance, we'll blame it on you, your poor choice of browsers, and your uncooperative attitude, but then we'll scrap it. How can I test it? ------------------ Glad you asked! Module storage is enabled by default on the beta cluster, and on test & test2 wikis. The simplest way you can help is by being alert to to performance regressions and front-end code breakage. If you know how to use your browser's JavaScript console, you can get stats about module storage usage on the current page by checking the value of 'mw.loader.store.stats'. When the code is rolled out across the cluster, it will be disabled by default, but you will be able to opt-in by manually setting a cookie in your browser. I will follow up with the exact details. If module storage proves stable enough for production use, we'll seek to asses its utility by running a controlled study of some kind. If we can demonstrate that module storage leads to a significant improvement in performance, we'll enable by it default. --- Ori Livneh ori(a)wikimedia.org

27 57

RFC cluster summary: HTML templating
by Rob Lanphier 22 Jan '14

22 Jan '14

Hi folks, This is an attempt to summarize the list of RFCs that are listed under this cluster: https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_Clusters#HTML_t… ...and possibly get a conversation going about all of this in advance of the Architecture Summit. The main focus of all of these RFCs is around HTML generation for user interface elements. This category is not about wikitext templates or anything to do with how we translate wikitext markup "Template Engine" is Chris Steipp's submission outlining the use of Twig. From my conversations with Chris, it's not so much that he's eager to adopt Twig specifically so much as standardize on *something*, and make sure there's usage guidelines around it to avoid common mistakes. He's seen many attempts at per-extension template libraries that bloat our code and often start off with big security vulnerabilities. There are many extensions that use Twig, and it seems to be a popular choice for new work, so Chris is hoping to standardize on it and put some usage standards around it. "HTML templating library" is Ryan Kaldari's submission, promoting the use of Mustache or something like it. His main motivation is to have a Javascript template library for front-end work, but is hoping we choose something that has both Javascript and PHP implementations so that any PHP template system implementation is compatible with what we use for Javascript templating. "MVC Framework" is Owen Davis's description of Wikia's Nirvana framework, which has been central to all of the user-facing work they've been doing for the past 2-3 years. As Owen points out in the talk page for this, it's really view-controller rather than full MVC. A big plus of adopting this RFC is that it would make it much more likely that Wikia-developed extensions (of which there are many) would be of greater use to the larger MediaWiki community, and would generally help facilitate greater collaboration between Wikia and the rest of us. "OutputPage Refactor" is another submission from Owen Davis, which isn't really about templating, so much as taking the HTML generation code out of OutputPage. Wikia has been maintaining a fork of OutputPage for quite some time, so they already have quite a bit of experience with the proposed changes. This is clustered with the templating proposals, since I imagine the work that gets factored out of OutputPage would need to be factored into whatever templating system we choose. The first three seem somewhat mutually exclusive, though it's clear our task is likely to come up with a fourth proposal that incorporates many requirements of those three. The OutputPage Refactor proposal, given some fleshing out, may not be controversial at all. Where should we go from here? Can we make some substantial progress on moving one or more of these RFCs over the next few weeks? Rob

15 26

Jake requests enabling access and edit access to Wikipedia via TOR
by Thomas Gries 13 Jan '14

13 Jan '14

Hi, during the 30C3 Congress [1] in Hamburg - where neither Wikipedia Foundation nor MediaWiki were formally present this year (but should be next year)- Jacob Appelbaum [2] - core member of the TOR project - complained in one of his numerous talks that the (edit) access to Wikipedia via TOR is not possible. He requested that a way should be found to enable the TOR access including edit access to Wikipedia. I am just the messenger of this message. Regards, Tom [1] https://events.ccc.de/congress/2013/wiki/ [2] https://en.wikipedia.org/wiki/Jacob_Appelbaum

21 44

npm publish
by Dan Andreescu 10 Jan '14

10 Jan '14

We needed to write an npm module for mediawiki oauth, and we're about to publish it to the npm registry. I just wanted to check whether we had a wikimedia account on https://npmjs.org/. If not, do we want one?

5 7

Please use sitenotice when a new version of software is deployed
by Alex Brollo 08 Jan '14

08 Jan '14

Users are very confused and worried any time a new version of wiki software is launched and tested, and some major or minor bug comes invariably out. A clear message using central sitenotice, with links to doc pages listing the changes at different levels of detail and to their talk pages to discuss them and to alert for bugs, is mandatory IMHO. Tech news are largely insufficient; evidence of work in progress should be clearly visible into all pages of interested projects. It's a basic matter of Wikilove. Alex

26 35

$wgDBmysql5
by Tyler Romeo 02 Jan '14

02 Jan '14

As the subject implies, there is a variable named $wgDBmysql5. I am inclined to believe that the purpose of this variable is to use features only available in MySQL 5.0 or later. The specific implementation affects the encoding in the database. https://www.mediawiki.org/wiki/Manual:$wgDBmysql5 Right now MediaWiki installation requirements say you need MySQL 5.0.2 or later. So my question is: is this configuration variable still necessary, or should it be deprecated? *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

3 4

Fwd: Proposal for biweekly Labs showcase
by Diederik van Liere 01 Jan '14

01 Jan '14

Bumping my proposal. I am particularly looking forward from responses from community members. Have an awesome New Year's Eve! Best, Diederik Heya, I just posted an initial proposal to start running a biweekly showcase to feature all the cool things that are happening on Labs. Please have a look at https://wikitech.wikimedia.org/wiki/Showcase, express your interest and chime in on the Talk page to help get this off the ground. Best, Diederik

2 1

Gerrit command line tool
by Jon Robson 31 Dec '13

31 Dec '13

I was getting very bored of the tedious job of working out what to code review and then how to pull it down so I made a tool in the MobileFrontend repository which lets me do all this from the comfort of the command line [1]. With the script (and a couple of python installs as referenced in the command line) you simply run: > make gerrit and it prints a list of options http://imgur.com/e5JBnQI Simply type the number of the commit you want to review and it will pull it down for you. The list of reviews is ordered by the following mechanism (could be tweaked): * Patches closest to being merged appear at top e.g. +1s at top, -2s at bottom * If patches are of equal code review score, the old ones get preference as that only seems fair. It currently doesn't allow you to do reviews from the command line but that would be a pretty awesome addition. Let me know your thoughts. [1] https://gerrit.wikimedia.org/r/#/c/103884/

2 3

MediaWiki Language Extension Bundle 2013.12 release
by Kartik Mistry 31 Dec '13

31 Dec '13

Hello, Happy New Year to all! I would like to announce the release of MediaWiki Language Extension Bundle 2013.12. This bundle is compatible with MediaWiki 1.21.3 and MediaWiki 1.22.0 releases. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.12.tar… * sha256sum: 2ef19e31d685dd0d6e50088ec8bbb1cd3e74c694096dfa333efb61dcfee9c3c0 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://bugzilla.wikimedia.org * Talk with us at: #mediawiki-i18n @ Freenode Release notes for each extension are below. -- Kartik Mistry == Babel, CLDR and LocalisationUpdates == * Only localization updates. == CleanChanges == * Bug 58439: Fix Monobook skin by removing extra <nowiki></div></nowiki> creating invalid HTML. * Localization updates. == Translate == === Noteworthy changes === * Translator Sandbox: ** Translator Sandbox is a feature to simplify the sign-up process for new translators. It can be enabled using "$wgTranslateUseSandbox = true;", but it will only be useful in conjunction with the TwnMainPage, which is not included in MLEB (at least yet). ** Stash and translator approval pages are now usable. ** When a user is accepted, a bare-bones user page with a Babel box is created. * TUX editor: ** Bug 53748: Message group related calls were made two order of magnitudes faster, making Special:Translate's group selector, workflow state selector etc. fast enough even on wikis with hundreds or thousands groups. ** Add useful shortcuts to TUX editor. All buttons to insert/replace text (insertables and then translation aids in order; "discard changes" is skipped) are numbered from 1 up and can be accessed with both alt+<num> and arrow up and down. ** Update the statusbar at the bottom of the TUX message tables when saving or proofreading. * Added support to MediaWiki localisation format from PHP files to JSON files. This is part of the Localization Format RFC ( https://www.mediawiki.org/wiki/Requests_for_comment/Localisation_format ). ** Add support for JSON in mediawiki-defines.txt, allowing the handling of MediaWiki extension that us the new format. Documentation about the updates in MessageGroup configuration can be found at: https://www.mediawiki.org/wiki/Help:Extension:Translate/Group_configuration… ** Fixed JsonFFS for properly importing and exporting Authors. ** targetPattern in group configuration is now optional. ** Migrate the Translate extension itself to JSON based i18n files from PHP files. This change is transparent to all users of extension. * Support xliff 1.1 files in addition to xliff 1.2 as well, but without validation. === Breaking changes === Special:FirstSteps has been removed from Translate. If you want the feature, you'll have to download it separately. == UniversalLanguageSelector == === Noteworthy changes === * Language selector now opens an order of magnitude faster (see https://github.com/wikimedia/jquery.uls/pull/122 for details). * Initial support for webfonts in MobileFrontend: ** Currently, support for webfonts in MobileFrontend is disabled by default. It can be enabled by setting $wgULSMobileWebfontsEnabled = true; in LocalSettings.php file. Note that, even then it will only be enabled for users who has opted in for the mobile beta mode. === Fonts === * Bug 57767: Enable Amiri font for Soranî language. * Bug 58381, 58382: Add Lateef and Scheherazade fonts for Soranî and Farsi languages. * Update Autonym font to version 20131205: ** Fixed Autonym for Old Slavonic. ** Fixed glyphs for the Glagolitic script. ** Removed Reserved Font Name (RFN) and documentation updates. -- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

1 0

Google Code-in starting NOW (important!)
by Quim Gil 31 Dec '13

31 Dec '13

Hi, Google Code-in is about to start: http://www.google-melange.com/gci/homepage/google/gci2013 https://www.mediawiki.org/wiki/Google_Code-In We have currently 72 tasks published and 13 mentors. We are still looking for more mentors and tasks. If you are interested, contact me. This is the first time Wikimedia participates in this program and the only certain prediction at this point is that we all will learn a lot. We have been warned that especially the first two weeks will be quite messy, with many impatient newcomers landing in our community channels and asking for help / feedback / review. Please be kind with them. Things will eventually settle down, partially because our documentation will be better, partially because the students interested in Wikimedia will be familiar with the basics and will know where/how to ask. Ideally https://www.mediawiki.org/wiki/Google_Code-In should contain answers and links to answers for the frequently asked questions. Try to answer GCI students with links to the appropriate pages, and try to assure that such links are available at our GCI wiki page. Thank you for your patience. I have no doubt that your direct or indirect help will pay off with better documentation for all kinds of newcomers interested in many areas of contribution. /me goes to prepare a hot beverage. It is going to be fun. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

3 12

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 December 2013