[Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Brion Vibber
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...

Re: [Wikitech-l] MediaWiki Developer Summit: The future of Language Converter

2015-01-27 Thread Joel Sahleen
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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread C. Scott Ananian
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

Re: [Wikitech-l] MediaWiki Developer Summit: The future of Language Converter

2015-01-27 Thread C. Scott Ananian
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

Re: [Wikitech-l] MediaWiki Developer Summit: The future of Language Converter

2015-01-27 Thread James Forrester
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

Re: [Wikitech-l] MediaWiki Developer Summit: The future of Language Converter

2015-01-27 Thread James Forrester
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,

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Brion Vibber
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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Brion Vibber
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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Luis Villa
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!

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Subramanya Sastry
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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread C. Scott Ananian
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

Re: [Wikitech-l] MediaWiki Developer Summit: The future of Language Converter

2015-01-27 Thread wctaiwan
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

[Wikitech-l] Odd API errors spotted this morning (around 08:25 UTC to 10:20 UTC)

2015-01-27 Thread Brad Jorsch (Anomie)
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' );

Re: [Wikitech-l] MediaWiki Developer Summit: The future of Language Converter

2015-01-27 Thread C. Scott Ananian
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

Re: [Wikitech-l] Performance of parsing links?

2015-01-27 Thread Chad
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#

Re: [Wikitech-l] Performance of parsing links?

2015-01-27 Thread Brion Vibber
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,

Re: [Wikitech-l] Performance of parsing links?

2015-01-27 Thread Daniel Friesen
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:

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Stas Malyshev
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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Daniel Friesen
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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Daniel Friesen
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

[Wikitech-l] Performance of parsing links?

2015-01-27 Thread Daniel Barrett
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.

[Wikitech-l] Archcom plans

2015-01-27 Thread Brion Vibber
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

Re: [Wikitech-l] All Hands On Deck!

2015-01-27 Thread Jay Ashworth
- 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

[Wikitech-l] Please Review These Patches

2015-01-27 Thread Tyler Romeo
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

Re: [Wikitech-l] All Hands On Deck!

2015-01-27 Thread Mark A. Hershberger
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

Re: [Wikitech-l] Thoughts: stateless services with open servers?

2015-01-27 Thread Federico Leva (Nemo)
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.

[Wikitech-l] DevSummit appreciation

2015-01-27 Thread Erik Moeller
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_

Re: [Wikitech-l] [Engineering] DevSummit appreciation

2015-01-27 Thread Joel Sahleen
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

Re: [Wikitech-l] Wikidata search provider for GNOME Shell

2015-01-27 Thread Jon Robson
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

Re: [Wikitech-l] Wikidata search provider for GNOME Shell

2015-01-27 Thread Bahodir Mansurov
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

Re: [Wikitech-l] Wikidata search provider for GNOME Shell

2015-01-27 Thread Jon Robson
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/

[Wikitech-l] MediaWiki Developer Summit: The future of Language Converter

2015-01-27 Thread C. Scott Ananian
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