Wikitech-l January 2015

wikitech-l@lists.wikimedia.org

133 participants
117 discussions

Re: [Wikitech-l] From Node.js to Go
by Ori Livneh 30 Jan '15

30 Jan '15

(Sorry, this was meant for wikitech-l.) On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh <ori(a)wikimedia.org> wrote: > We should do the same, IMO. > http://bowery.io/posts/Nodejs-to-Golang-Bowery/ >

9 8

Re: [Wikitech-l] [WikimediaMobile] Florian for +2 on MobileFrontend?
by Tomasz Finc 30 Jan '15

30 Jan '15

CC'ing wikitech-l@ to broaden the reach of this --tomasz On Fri, Jan 30, 2015 at 10:32 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: > I've proposed that Florian gets +2 on the MobileFrontend repository. > Florian has been an extremely active MobileFrontend developer (he is > our 5th most active contributor). > > It would be great to have him helping out with merging patches. He > also is based in Europe so it would strengthen our ability to get > regressions fixed on different timezones quicker! > > You can support this by voting using the {{support}} template on: > https://www.mediawiki.org/wiki/Gerrit/Project_ownership#.2B2_for_Florian_Sc… > > Please show your {{support}} on the wiki page to make this happen! > > (In the words of Spiderman with great power comes great reponsibility) > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l

1 0

MediaWiki Language Extension Bundle 2015.01 release
by Kartik Mistry 30 Jan '15

30 Jan '15

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2015.01. This bundle is compatible with MediaWiki 1.23.8 and MediaWiki 1.24.1 releases. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2015.01.tar… * sha256sum: 7a53ed826ae14ffe279fc4231cc47d367f668723a5843ad62c13a8f17d339744 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 and CleanChanges == * Localisation updates only. == LocalisationUpdate == * T69154: Added support for updating skins. == Translate == * T44162: Patrol footer will not appear on translation pages now. * T76731: Added Content Translation Machine Translation backend support. * T86000: Message group configurations are now optionally validated. * Make 'fuzzy' as a default action for changes in source language in Special:ManageMessageGroups. == UniversalLanguageSelector == * This version has compatibility issues with Internet Explorer 8. Support will be restored in the next MLEB release. === Input Methods === * Corrected names of Punjabi input methods. -- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

1 0

Blog post on Librarization project published
by Bryan Davis 30 Jan '15

30 Jan '15

For the last four months, my main focus has been the Librarization project [0]. Today a wrap up blog post was posted to blog.wikimedia.org [1] that I'd invite all of you to read to get an overview of what our high level goals and motivations were and what we accomplished. The TL;DR is that we now have some guidelines for how to separate code from MediaWiki and publish it as a semi-autonomous open source project. The blog post ends with a thinly veiled call to action for MediaWiki developers to continue the work of extracting code from the current MediaWiki core application and publishing them as independent libraries. We've published some information on how to deal with git hosting, code review, and various other general issues on mediawiki.org [2]. There is also a list of some areas of the existing code base that we thought would be interesting targets for extraction [3]. The CDB library [4] can serve as one concrete example of using the guidelines. I'd like to invite anyone interested in starting work on decoupling a particular area of the code to start a thread on wikitech-l and file a task in Librarization phabricator project [5] to attract collaborators and help reduce possible duplication of effort. It would also be great to have edits on the list page and/or phabricator tasks to act as a wish list of things that know of in MediaWiki that you would either like to be able to use in a non-MediaWiki PHP project or feel would be a good candidate for isolation so that alternate implementations could be introduced. [0]: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki [1]: https://blog.wikimedia.org/2015/01/29/modernizing-mediawiki-with-libraries/ [2]: https://www.mediawiki.org/wiki/Manual:Developing_libraries [3]: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki/Library… [4]: https://www.mediawiki.org/wiki/CDB [5]: https://phabricator.wikimedia.org/tag/librarization/ Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

3 2

wfShellExec() quirk - advice needed on further debug
by Keith Welter 29 Jan '15

29 Jan '15

The GraphViz extension uses wfShellExec() to invoke the "dot" command. Sometime in the last month or so, on my Ubuntu 14.04 installation, the command started failing with: Warning: Could not load "/usr/lib/graphviz/libgvplugin_gd.so.6" - file not found The file does exist and the dot command runs fine from a shell session. I found that by eliminating the ulimit -v option from ulimit4.sh, which wfShellExec() invokes, the problem goes away. The -v limit is 102400 on my installation (so 100Mb). I find it hard to believe that dot actually needs that much virtual memory. Suggestions on how to proceed with debug would be much appreciated. Thanks, Keith Welter

2 2

Thoughts: stateless services with open servers?
by Brion Vibber 29 Jan '15

29 Jan '15

We had a great discussion at the MediaWiki dev summit just now on service-oriented architecture and future plans in that direction... as always the community seems a bit split on the subject. Breaking things out to separate services can indeed make setup and maintenance more complex... pro-services/pro-VM/pro-hosting folks like me tend to say "hey that can be automated!" (and MediaWiki-Vagrant shows a lot of awesomeness to start, though it's very developer-focused). One thing that comes to mind though is something Gabriel mentioned about wanting stateless services for things like image manipulation and citation parsing and whatnot -- in principle many services like this could be opened up to public use. For instance, a random MediaWiki instance could use a Wikimedia-hosted image scaler or graph rasterizer. Usage limits and API keys could be introduced if we're worried about overloading. Whether this can apply also to things like Parsoid might be tricky -- that's the biggest Scary Thing since core editing with VE/Flow is going to depend on it. Anyway, just thoughts. :) -- brion

14 26

Dev Summit debrief: SOA proliferation through specification
by James Douglas 29 Jan '15

29 Jan '15

Howdy all, It was a pleasure chatting with you at this year's Developer Summit[1] about how we might give SOA a shot in the arm by creating (and building from) specifications. The slides are available on the RESTBase project pages[2] and the session notes are available on Etherpad[3]. I'm eager to keep the conversation going on the mailing list, and want to address a couple items that came up (or were missing) during the session, as well as prompt for further discussion. I mentioned after the presentation that we're using our spec to drive our automated testing. I added some info about that to slide #14 in the slides[2]. The idea is that, since Swagger lets us add custom fields to a spec, we can augment each endpoint specification with a functional description of its expected inputs and outputs. During testing, we parse the spec and verify that these indeed hold true. There's a lot of opportunity for enhancement of our (currently very basic) approach to this, but it's already proving pretty handy from a coverage standpoint. There was a question in the notes[3] about Swagger's support for internationalization, but I'm not familiar with the use case in mind. How might an API differ, aside from the content of fields in a specified model, under different localizations? Might users want the models themselves (or parameter names, etc.) to vary? Cheers! James [1] https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015 [2] http://wikimedia.github.io/restbase/docs/presentations/wm-dev-summit-2015/s… [3] https://etherpad.wikimedia.org/p/mwds15-spec-oriented-architecture

4 4

Performance of parsing links?
by Daniel Barrett 29 Jan '15

29 Jan '15

I'm writing a parser function extension that outputs about 5000 lines of text (an organizational chart of a company) as a nested, bulleted list. * Bob the CEO ** Jane Jones ** Mike Smith *** etc. It takes about 3 seconds (real time) for MediaWiki to render this list, which is acceptable. However, if I make it a list of links, which is more useful: * [[User:Bob | Bob the CEO]] ** [[User:Jane | Jane Jones]] ** [[User:Mike | Mike Smith]] the rendering time more than doubles to 6-8 seconds, which users perceive as too slow. Is there a faster implementation for rendering a large number of links, rather than returning the wikitext list and having MediaWiki render it? Thanks, DanB ________________________________ My email address has changed to danb(a)cimpress.com. Please update your address book. Cimpress is the new name for Vistaprint NV, the world’s leader in mass customization. Read more about Cimpress at www.cimpress.com. ________________________________

5 4

Request for comments for RESTBase?
by MZMcBride 29 Jan '15

29 Jan '15

Hi. There's been quite a bit of discussion about RESTBase lately. Is there a request for comments on mediawiki.org about RESTBase? I looked at <https://www.mediawiki.org/wiki/Requests_for_comment> and didn't see one. >From my limited understanding of what's being proposed, I'd personally be a lot more comfortable with the idea if someone from both the software architecture side (Brion, Tim, or equivalent) and someone from the operations side (Mark, Faidon, Giuseppe, or equivalent) weighed in and signed off on what's being proposed. This may have already happened somewhere, but I didn't see anything in my brief searching and poking around on pages such as <https://www.mediawiki.org/wiki/RESTBase>. MZMcBride

2 3

Scrum of Scrums notes
by Matthew Flaschen 28 Jan '15

28 Jan '15

This is the Collaboration team update for 1/28. We are in early stages of improving the user experience for enabling and disabling Flow boards. We enabled Flow on two pages on Portuguese Wikipedia, and are preparing to finish enabling Flow for the Co-op (https://en.wikipedia.org/wiki/Wikipedia:Co-op). We fixed an urgent issue caused by moving a regular page into Flow's topic namespace (both preventing the issue in the future and treating the symptoms this time). Matt Flaschen

1 0

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 January 2015