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
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
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
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
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
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
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.
________________________________
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
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