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...
I would love to go to this but the timing is not good. Like James, already
committed to another session.
There seem to be a lot of language-related issues that are being worked on
independently by different groups of people who don’t necessarily communicate.
Hard for a newbie like me to wrap
We already run a public Parsoid service.
Kiwix uses it, as does Nell's Wikipedia. I believe some non-WMF content
translation efforts also use it.
Usage limits and API keys would probably be a reasonable thing to do,
longer-term.
--scott
On Tue, Jan 27, 2015 at 11:20 AM, Brion Vibber
Asaf, wctaiwan: I totally understand the social and cultural implications
-- that is indeed one of the key things I wish to discuss during this
session so that people understand that language variants are not *just* a
technical issue.
For example, I believe that Urdu and Hindi are also amendable
On 27 January 2015 at 10:32, C. Scott Ananian canan...@wikimedia.org
wrote:
Asaf, wctaiwan: I totally understand the social and cultural implications
-- that is indeed one of the key things I wish to discuss during this
session so that people understand that language variants are not *just* a
On 27 January 2015 at 10:49, C. Scott Ananian canan...@wikimedia.org
wrote:
Well, I'll give James the opposite answer then:
Language Variants are not *just* a social and cultural issue, either.
There are real technical issues to address, having to do with how we manage
slightly forked wikis,
On Tue, Jan 27, 2015 at 11:10 AM, James Forrester jforres...@wikimedia.org
wrote:
On 27 January 2015 at 11:04, Brion Vibber bvib...@wikimedia.org wrote:
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
Another possibility is to shell out to nodejs-based services as an
alternative to running them as ongoing web services.
This may not be super performant, but it should work -- just as we've been
able to shell out to system binaries, Python scripts, ocaml, lua, etc for
years. Would require having
On Tue, Jan 27, 2015 at 11:20 AM, Brion Vibber bvib...@wikimedia.org
wrote:
Running Parsoid as a public service (with some soft-ish API limits)
would
allow us to support the oft-cited user who has a dumb PHP-only box and no
means to install a node service, so that has my support;
Yay!
On 01/27/2015 11:46 AM, C. Scott Ananian wrote:
We already run a public Parsoid service.
But, this doesn't serve wiki content from wikis other than wikimedia
wikis and we are unlikely to do so with the existing production WMF cluster.
The discussion is whether we should / will run a
On Tue, Jan 27, 2015 at 11:46 AM, Brion Vibber bvib...@wikimedia.org
wrote:
Another possibility is to shell out to nodejs-based services as an
alternative to running them as ongoing web services.
Parsoid currently does a lot of MediaWiki API querying at startup to get
the current wiki
I think any decision to split wikis should not be made without
consensus within the affected communities. From a technical
standpoint, it would be much easier to decide in favour of a split,
but I'm worried that the social ramifications of such a decision would
be overlooked in a discussion among
Something seems to have gone weird with the API this morning, to the point
where something like this would have intermittently failed on enwiki:
// The POST parameter 'cmtitle' has value 'Category:Articles to be
expanded'
$title = RequestContext::getMain()-getRequest()-getVal( 'cmtitle' );
Well, I'll give James the opposite answer then:
Language Variants are not *just* a social and cultural issue, either.
There are real technical issues to address, having to do with how we manage
slightly forked wikis, how we maintain code which is not used by enwiki,
and the technical limitations
On Tue Jan 27 2015 at 1:37:36 PM Brion Vibber bvib...@wikimedia.org wrote:
Probably the fastest thing would be to manually create the ulli etc and
wrap them around a loop calling the linker functions (Linker::link).
https://doc.wikimedia.org/mediawiki-core/master/php/html/classLinker.html#
Probably the fastest thing would be to manually create the ulli etc and
wrap them around a loop calling the linker functions (Linker::link).
https://doc.wikimedia.org/mediawiki-core/master/php/html/classLinker.html#a52523fb9f10737404b1dfa45bab61045
-- brion
On Tue, Jan 27, 2015 at 1:33 PM,
You should be able to return something like this to make your parser
function output raw HTML instead of WikiText.
return array( $output, 'noparse' = true, 'isHTML' = true );
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2015-01-27 1:33 PM, Daniel Barrett wrote:
Hi!
Running Parsoid as a public service (with some soft-ish API limits) would
allow us to support the oft-cited user who has a dumb PHP-only box and no
means to install a node service, so that has my support; however, I worry
that WMF might not be the best organisation to provide this if
On 2015-01-27 11:04 AM, Brion Vibber wrote:
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
On 2015-01-27 12:51 PM, Stas Malyshev wrote:
Hi!
Running Parsoid as a public service (with some soft-ish API limits) would
allow us to support the oft-cited user who has a dumb PHP-only box and no
means to install a node service, so that has my support; however, I worry
that WMF might not
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.
I just want to thank everybody who participated in the 'future of the
architecture committee' session at the dev summit today -- we had some
great discussion and good ideas and concerns from a lot of people.
Damon has proposed that the committee plan a provisional governance model
formalizing
- Original Message -
From: Mark A. Hershberger m...@nichework.com
Can we get a simple English version of the poetry there?
As others have pointed out poetry doesn't translate well, but I've
managed to come up with an interpretation that I hope is easy for a
non-native speaker to
I don’t usually email the list for this kind of stuff, but if you have some
spare time to test an extension, please check out this patch chain. I’d like to
get it merged before May (when they become a year old).
In order of dependency:
https://gerrit.wikimedia.org/r/132783
Antoine Musso hashar+...@free.fr writes:
Le 23/01/2015 09:11, littlewmfb...@yandex.com a écrit :
Oh what a day! Which began when perforce
a visitor from afar began to exhort
snip
https://lists.wikimedia.org/pipermail/wikitech-l/2015-January/080300.html
Can we get a simple English version
The only true precedent we have here is the public Collection server run
by PediaPress, which is a wonderful service used by several hundreds
wikis for years. It ensures a comparatively smooth installation of the
Collection extension even for the most niche formats.
Just a quick note that I really appreciated everyone's help making the
summit come together. As always, we'll be doing lots of second-guessing of
everything we did and didn't do, and how we want to use future time
together. Before we go into that, I'd like to thank the event team and
_everyone_
Here, here! Thanks to everyone who helped put this event together. Great job!
Joel Sahleen, Software Engineer
Language Engineering
Wikimedia Foundation
jsahl...@wikimedia.org
On Jan 27, 2015, at 10:43 PM, Erik Moeller e...@wikimedia.org wrote:
Just a quick note that I really appreciated
Hey Baha! How can I see what this is like without a Gnome environment?
On Fri, Jan 23, 2015 at 2:28 AM, Lydia Pintscher
lydia.pintsc...@wikimedia.de wrote:
On Fri, Jan 23, 2015 at 6:24 AM, Bahodir Mansurov
bmansu...@wikimedia.org wrote:
I’ve created a GNOME Shell extension that allows the user
You can see a screenshot here [1]. It’s similar to spotlight search on a mac.
[1] https://extensions.gnome.org/extension/924/wikidata-search-provider/
https://extensions.gnome.org/extension/924/wikidata-search-provider/
On Jan 27, 2015, at 9:02 AM, Jon Robson jdlrob...@gmail.com wrote:
Hey
Nice!
On Tue, Jan 27, 2015 at 9:05 AM, Bahodir Mansurov
bmansu...@wikimedia.org wrote:
You can see a screenshot here [1]. It’s similar to spotlight search on a mac.
[1] https://extensions.gnome.org/extension/924/wikidata-search-provider/
Another late addition to the developer summit: let's talk about language
converter, content translation tools, and other ways to bridge language
differences between projects.
2:45pm PST today (Tuesday) in Robertson 3.
Task: https://phabricator.wikimedia.org/T87652
Here's a list of all the
32 matches
Mail list logo
