Wikitech-l May 2015

99 participants
85 discussions

Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 11 Aug '15

11 Aug '15

When api.php was basically the only API in MediaWiki, calling it "the API" worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying "the API" is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like "the api.php API". I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

30 38

FYI: HTMLForm is now available in OOUI format
by James Forrester 22 Jul '15

22 Jul '15

As part of the on-going UI standardisation work[0], we have just merged into MediaWiki master a patch that will allow users of HTMLForm[1] to easily switch over to use OOUI[2]. This allows you to make your code use the standard UI styling and components with very little effort, improving consistency and accessibility. To convert your code over from the existing styling of MediaWiki's HTMLForm (or its VForm version), you can replace the instantiation command of - $form = new HTMLForm( … ); - or: - $form = HTMLForm::factory( 'vform', … ); - with - $form = HTMLForm::factory( 'ooui', … ); … and everything Should Just Work™. This doesn't break anything for existing use of this code, and you can explicitly retain the existing styling by using $form = HTMLForm::factory( 'table', … ); or 'div' or 'vform' instead if you wish. Feel free to add your code to the epic task on Phabricator which is the central liaison point for this work[3]. Finally, please be careful to check your interfaces after converting them – although we have tested this and believe it works well, there may be some edge cases where it doesn't quite work. We're still missing a few features [4] (such as prettier radio buttons), which we're hoping to have ready in a week or two. If do you find any such issues, please report them so we can fix them. Also note that OOUI already implements the new "MediaWiki" theme for all users, so please ensure you advertise the visual changes as they roll out to minimise disruption. [0] - https://phabricator.wikimedia.org/T49145 [1] - https://www.mediawiki.org/wiki/HTMLForm [2] - https://phabricator.wikimedia.org/T85291 [3] - https://phabricator.wikimedia.org/T100270 [4] - https://phabricator.wikimedia.org/T100279 Yours, -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

3 2

ContentTranslation gets to 2000
by Amir E. Aharoni 06 Jun '15

06 Jun '15

[ cross-posted to MediaWiki-i18n, Wikimedia-L and Wikitech-L ] Dear Wikimedians, The 2000th article that was written using the ContentTranslation extension was published today. Article #2000 was translated from English to Greek, and it's about Škocjan Caves, a UNESCO World Heritage site in Slovenia. Original: https://en.wikipedia.org/wiki/%C5%A0kocjan_Caves Translated: https://el.wikipedia.org/wiki/%CE%A3%CF%80%CE%AE%CE%BB%CE%B1%CE%B9%CE%B1_%C… In case you're wondering what ContentTranslation is, here's a brief summary: ContentTranslation is an extension that helps Wikipedia editors to create articles quickly and easily by translating them from other languages. It's being developed by the Language Engineering team. Its design started in the summer of 2013 and its coding started in early 2014. You can find more info at https://www.mediawiki.org/wiki/CX as well as in the following blog posts: * http://blog.wikimedia.org/2015/01/10/content-translation-beta-coming-soon/ * http://blog.wikimedia.org/2015/01/20/try-content-translation/ * http://blog.wikimedia.org/2015/04/06/content-translation-improved-my-edits/ * http://blog.wikimedia.org/2015/04/08/the-new-content-translation-tool/ Some more data about ContentTranslation: * Our first deployment was in mid-January to Catalan, Spanish, Portuguese, Esperanto, Norwegian Bokmal, Danish, Indonesian and Malay. Now we support 43 languages, and this number is growing every week as we extend the deployment (a special thank-you to the Ops and Release Engineering people, who continuously and tirelessly support our deployment effort). * In all the Wikipedias in which ContentTranslation is deployed, it is currently defined as a Beta feature, which means that it is only available to logged-in users who opted into it in the preferences. * The 1000th article was written on April 10th, so it took much less to get to 2000 than to 1000. * The language into which the most articles were translated is Catalan: 762. The Catalan Wikipedia community always had a strong inclination to translation, it was the first one that volunteered to test the tool in labs in the summer of 2014 and provided a lot of useful feedback, and it also has good machine translation support thanks to the Freely-licensed Apertium engine. * The second most popular target language is Spanish. It started slowly in the first couple of months, but it's quickly growing since March. * Other target languages that are quickly growing lately are French, Portuguese and Ukrainian. * The language from which the largest number of articles is translated is English. It is followed by Spanish, from which a lot of articles are translated to the closely related Portuguese and Catalan. * The total number of people who published at least one translated article into any language is 663. * Of more than 2000 articles that were created, about 60 were deleted, so we have a reason to think that the quality of the created articles is pretty OK. * In Catalan we see that ContentTranslation has some influence on the number of articles created per day - it was usually between 60 and 90 before 2015, and in January and February it was over a 100. It's too early to say how does it influence other languages, but we are optimistic ;) * A community discussion about enabling the tool in the French Wikipedia ended with 50 "votes" in support of the tool and 0 "votes" against it ;) Some of our plans for the coming months are: * Enabling more languages, including big ones like English, Russian and Italian, as well as right-to-left languages. * Improving the support for links. * Creating support for smart suggestions of articles to translate, as well as "task lists" for translation projects. * Starting to get the tool out of beta status :) I'd like to thank all the Wikimedia volunteers around the planet who are participating in this effort by translating articles, translating the extension's user interface, testing the tool, assisting other wikipedians to translate, organizing translation workshops, reporting useful bugs, submitting patches, and generally proving day after day what an incredible community they are - hard-working, massively-multilingual, helpful, patient, creative and talented. Thank you - we have a lot more to achieve together \o/ -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

6 6

Open Help Conference & Sprints
by Quim Gil 02 Jun '15

02 Jun '15

Hi, anybody interested in participating at the Open Help Conference & Sprints September 26-30 Cincinnati, Ohio, USA http://conf.openhelp.cc/ A Wikimedia expedition attended a couple of years ago with a Wikipedia & user help focus, and they were happy about the event. http://blog.wikimedia.org/2013/07/03/wikipedians-open-help-conference/ Lately we are focusing on users of our APIs, datasets, tools, infrastructure... Would it make sense to organize something at that event? Wikimedia volunteers, remember that we might be able to support your travel expenses. https://meta.wikimedia.org/wiki/Grants:TPS -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

3 3

Use Supercounter as an API
by Nasir Khan 01 Jun '15

01 Jun '15

Hi, I want to build a tool which will generate the statistics for my native wiki. Before starting to build a tool i was searching for an existing one. The "Super Counter"[1] has some of the features i want to implement in my tool. So is there any way to use the "Super Counter" as an API? if so, can anyone please show me the path of the documentation? [1] - https://tools.wmflabs.org/supercount/index.php -- *Nasir Khan Saikat* www.nasirkhn.com

2 3

Simplifying the WMF deployment cadence
by Greg Grossmeier 30 May '15

30 May '15

Hi all, Starting the week of June 8th we'll be transitioning our MediaWiki + Extensions deployment cadence to a shorter/simpler one. This will begin with 1.26wmf9. New cadence: Tuesday: New branch cut, deployed to test wikis Wednesday: deployed to non-wikipedias Thursday: deployed to Wikipedias This is not only a lot simpler to understand ("wait, we deploy twice on Wednesday?") but it also shortens the time to get code to everyone (2 or 3 days from branch cut, depending on how you count). == Transition == Transitions from one cadence to another are hard. Here's how we'll be doing this transition: Week of June 1st (next week): * We'll complete the wmf8 rollout on June 3rd * However, we won't be cutting wmf9 on June 3rd Week of June 8th (in two weeks): * We'll begin the new cadence with wmf9 on Tuesday June 9th I hope this helps our users and developers get great new features and fixes faster. Greg endnotes: * The task: https://phabricator.wikimedia.org/T97553 * I'll be updating the relevant documentation before the transition -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

14 25

Re: [Wikitech-l] [reading-wmf] Fwd: Mobile Firendly
by Jon Katz 30 May '15

30 May '15

+external mobile and wikitech Shoot. I meant to send this the external list. For those of you just joining us, we recently got an email from google letting us know that some of our pages are now failing the mobile-friendly test, which has an adverse impact on our search results. It appears that most of our pages are also blocking style info. Google doesn't offer much insight into penalties, but if they're sending us the email then it is or will have some impact. I'd like to see if we can better understand the other side of the equation- what is cost of fixing it? I think Jon's questions below are the ones to start with. -J On Fri, May 29, 2015 at 1:35 PM, Jon Robson <jrobson(a)wikimedia.org> wrote: > It's all in the report. We block w/ in robots.txt always have. > > There have been a bunch of changes to improve performance of the site > overall which might have led to that. Mailing this to the public mailing > list wikitech would give you a better idea. > > Our site /is/ mobile friendly it's just we tell google not to load styles > from w/load.php so no need to panic. > > The question is what is the penalty of us failing this tool? Does it > impact our google search rankings? > > Fix is trivial.. Update robots.txt but first the question is why are we > blocking scripts and styles on that url? > On 29 May 2015 1:17 pm, "Jon Katz" <jkatz(a)wikimedia.org> wrote: > >> Hi Readership team and broader community, >> Any changes we might have recently made to cause this warning to appear >> about googlebot not being able to access our site? >> I consider this to be a very serious issue. >> The examples below are not mobile, but same issue applies when you try an >> en.m. version of the pages. >> >> Best, >> Jon >> >> >> ---------- Forwarded message ---------- >> From: Wes Moran <wmoran(a)wikimedia.org> >> Date: Fri, May 29, 2015 at 12:47 PM >> Subject: Mobile Firendly >> To: Jon Katz <jkatz(a)wikimedia.org> >> Cc: Adam Baso <abaso(a)wikimedia.org> >> >> >> Jon, >> >> Google notified us of the followin... >> >> "We recently noticed that there was a change with how you embed CSS & JS >> which results in us not being able to use the CSS & JS to recognize what >> the page looks like. That's making some of your pages fail the >> mobile-friendly-test, for example. You used to load CSS & JS from >> bits.wikimedia.org, but now they're loaded through /w/load.php?... >> directly from the Wikipedia host, where that path is blocked by robots.txt. >> >> You can see how we render the pages with Fetch as Google in Webmaster >> Tools / Search Console, you can also see most of that with the test-page at: >> >> https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fe… >> >> Some of the pages still pass the test there (example >> <https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fe…>), >> but the CSS is broken there too since it's blocked. " >> >> Any ideas what can be causing this? >> >> Regards, >> Wes >> >> >> _______________________________________________ >> reading-wmf mailing list >> reading-wmf(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/reading-wmf >> >> > _______________________________________________ > reading-wmf mailing list > reading-wmf(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/reading-wmf > >

5 5

API returns empty strings for boolean fields?
by Brian Gerstle 29 May '15

29 May '15

For example: "mainpage" field is omitted when querying Barack Obama <https://en.wikipedia.org/wiki/Special:ApiSandbox#action=mobileview&format=j…> : > { > "mobileview": { > "pageprops": [], > "sections": [] > } > } But, it's present when querying Main Page <https://en.wikipedia.org/wiki/Special:ApiSandbox#action=mobileview&format=j…> : > { > "mobileview": { > "pageprops": [], > "mainpage": "", > "sections": [ ... ] > } } Is this the desired behavior? -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

4 5

Testing pywikibot on beta wikis (Was: Simplifying the WMF deployment cadence)
by John Mark Vandenberg 29 May '15

29 May '15

On Fri, May 29, 2015 at 2:09 AM, Brian Wolff <bawolff(a)gmail.com> wrote: > Shouldnt such [pywikibot] tests be run against beta wiki not testwiki? Primarily this hasnt happened because pywikibot doesnt have a family file for the beta wiki, but that is our issue, so I've done a simple test run on beta wiki four initial beta wiki problems: - no https (not nice - that means test accounts must be created and accessed using passwords that are sent in essentially cleartext - so sharing passwords with the same account name on the real wikis is a security risk) - invalid siteinfo interwiki map; includes entries to wikis that do not exist. That means pywikibot cant parse wikitext links, as it cant distinguish between iwprefix: and namespace: (pywikibot team might be able to reduce the impact of this wiki config problem) - paramInfo failure that breaks pywikibot's dynamic api detection; pywikibot batch loads the paraminfo for all modules, for example issuing the following API as part of the initialisation, and it is a 503 Service Unavailable http://en.wikipedia.beta.wmflabs.org/w/api.php?action=paraminfo&modules=abu… A little digging shows that the problematic module is fancycaptchareload http://en.wikipedia.beta.wmflabs.org/w/api.php?action=paraminfo&modules=fan… "Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes. If you report this error to the Wikimedia System Administrators, please include the details below. Request: GET http://en.wikipedia.beta.wmflabs.org/w/api.php?action=paraminfo&modules=fan…, from 127.0.0.1 via deployment-cache-text02 deployment-cache-text02 ([127.0.0.1]:3128), Varnish XID 855090368 Forwarded for: [your IP], 127.0.0.1 Error: 503, Service Unavailable at Fri, 29 May 2015 07:57:09 GMT " Could someone investigate this / fix that module? Pywikibot devs could also help reduce the impact of this type of problem in the future, by falling back from batch mode fetch to loading individual modules in order to skip buggy modules. - no SUL with the real wikis (probably the best choice given no https on the beta cluster, but it complicates adding beta wiki to our existing Travis-CI test matrix which includes real wikis) actual results at https://travis-ci.org/jayvdb/pywikibot-core/builds/64532033 -- John Vandenberg

4 5

Mailing list maintenance window - 2015-06-02 17:00 UTC to 19:00 UTC
by Rob Halsell 28 May '15

28 May '15

Mailing list maintenance window - 2015-06-02 17:00 UTC to 19:00 UTC I'll be taking the mailing list server offline for a (hopefully) short window. At the time of this announcement, this will be simply to process a single request. There is a good chance another request or two will be appended to this one before the actual window arrives. The downtime will start on 2015-06-02 @ 17:00 UTC and end at 19:00 UTC. Current Tasks: T100707 - Rename pywikipedia-l to pywikibot https://phabricator.wikimedia.org/T100707 Some may recall the last mailman maintenance window wasn't without incident: https://wikitech.wikimedia.org/wiki/Incident_documentation/20150519-Mailman This has been taken into account, and further testing of changes and mailman both before and after maintenance have been expanded. During this time, all mailing list traffic, as well as online archives, may become unavailable. Once the window has ended, all mail routing should resume normally, and any messages sent during the window will then be delivered accordingly. All associated tasks and changes are linked from https://phabricator.wikimedia.org/T100711. This mail has (initially) been send to the lists administrators list and wikitech-l. Please feel free to forward to any other lists or parties that would need to know about this maintenance window. -- Rob Halsell Operations Engineer Wikimedia Foundation, Inc. E-Mail: rhalsell(a)wikimedia.org Office: 415.839.6885 x6620 Fax: 415.882.0495

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

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