Mediawiki-api September 2014

mediawiki-api@lists.wikimedia.org

14 participants
16 discussions

How to expand templates, but leave comments
by Kevin Dunn 20 Jan '26

20 Jan '26

Hi there, I'm using the API to extract the raw wiki text from my pages, using the "?action=query&titles=Main_Page&export&exportnowrap" syntax. That works perfectly. Now I would like to get the templates expanded out in the result, so I use: "?action=query&titles=Main_Page&prop=revisions&rvlimit=1&rvprop=content&rvexpandtemplates", which does the job, as expected, but it also strips out the comments. My problem is that the comments are meaningful to me (I use them to help process the wiki text in subsequent steps). Is there a way to expand templates with the API, but leave the comments intact? Thanks, Kevin

4 5

Need to extract abstract of a wikipedia page
by aditya srinivas 23 Nov '23

23 Nov '23

Hello, I am writing a Java program to extract the abstract of the wikipedia page given the title of the wikipedia page. I have done some research and found out that the abstract with be in rvsection=0 So for example if I want the abstract of 'Eiffel Tower" wiki page then I am querying using the api in the following way. http://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Eiffel… and parse the XML data which we get and take the wikitext in the tag <rev xml:space="preserve"> which represents the abstract of the wikipedia page. But this wiki text also contains the infobox data which I do not need. I would like to know if there is anyway in which I can remove the infobox data and get only the wikitext related to the page's abstract Or if there is any alternative method by which I can get the abstract of the page directly. Looking forward to your help. Thanks in Advance Aditya Uppu

4 3

[Mediawiki-api-announce] Deprecation of list=allusers 'recenteditcount' result property
by Brad Jorsch (Anomie) 16 Apr '19

16 Apr '19

When list=allusers is used with auactiveusers, a property 'recenteditcount' is returned in the result. In bug 67301[1] it was pointed out that this property is including various other logged actions, and so should really be named something like "recentactions". Gerrit change 130093,[2] merged today, adds the "recentactions" result property. "recenteditcount" is also returned for backwards compatability, but will be removed at some point during the MediaWiki 1.25 development cycle. Any clients using this property should be updated to use the new property name. The new property will be available on WMF wikis with 1.24wmf12, see https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule. [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=67301 [2]: https://gerrit.wikimedia.org/r/#/c/130093/ -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 1

A question about UPLOAD update
by Liu Chenheng 02 Dec '14

02 Dec '14

Hi, All, I found in some of the UPLOAD update, there is no page id: <rc type="log" ns="6" title="File:Lucian A. Sperta- Nunez.jpg" rcid=" 114549183" pageid="0" revid="0" old_revid="0" user="Azarel63"oldlen="0" newlen="0" timestamp="2014-01-05T11:09:38Z" comment="User created page with UploadWizard" logid="77242320" logtype="upload"logaction="upload" img_sha1=" sf9t03wg27tl73nnde3jzfuxncefux9" img_timestamp="2014-01-05T11:09:36Z"/> <rc type="log" ns="6" title="File:Gingerbread spices (annotated).jpg" rcid=" 114549185" pageid="30485540" revid="0" old_revid="0"user="SKopp" oldlen="0" newlen="0" timestamp="2014-01-05T11:09:37Z" comment="User created page with UploadWizard" logid="77242318"logtype="upload" logaction="upload" img_sha1=" q84abqjr2n4bmn7o6j4uovpl5ufs2gq" img_timestamp="2014-01-05T11:09:37Z"/> The first one has no page id but the second one has. Does anybody can tell me the differences? Thanks, Ethan Liu

4 6

[Mediawiki-api-announce] Announcement of breaking change planned for MediaWiki 1.26
by Brad Jorsch (Anomie) 23 Oct '14

23 Oct '14

The API supports two methods for continuing action=query when more results are available, the simple method[1] and the raw method.[2] The raw method is currently the default for historical reasons, but as the simple method is much easier for new users to use *correctly* that really should be the default. To make this transition easy for clients, the current plan is to make the change on the following timetable: * Starting with 1.24wmf22,[3][4] action=query will recognize a "rawcontinue" boolean input parameter. Clients that wish to continue using the raw method for continuation should begin supplying this parameter with all action=query queries. * Sometime during the MediaWiki 1.25 development cycle, the API will begin reporting warnings when neither "continue" nor "rawcontinue" are supplied with action=query.[5] * Sometime during the MediaWiki 1.26 development cycle, simplified continuation will become the default.[6] Note this is also documented at < https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Simplified_…>. See other sections on that page for additional planned API changes. [1]: https://www.mediawiki.org/wiki/API:Query#Continuing_queries [2]: https://www.mediawiki.org/wiki/API:Raw_Query_Continue [3]: https://gerrit.wikimedia.org/r/#/c/154092/ [4]: See https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule of deployments to WMF wikis. [5]: https://gerrit.wikimedia.org/r/#/c/160222/ [6]: https://gerrit.wikimedia.org/r/#/c/160223/ -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 1

[Mediawiki-api-announce] Backlinks, imageusage, and embeddedin as prop modules
by Brad Jorsch (Anomie) 18 Sep '14

18 Sep '14

With the success of prop=redirects, in Gerrit change 155592[1] I added new prop modules prop=linkshere, prop=fileusage, and prop=transcludedin, which are roughly equivalent to list=backlinks, list=imageusage, and list=embeddedin but can work on a list of titles (including titles from a generator). They should be deployed to WMF wikis with 1.25wmf1 (unless we call it 1.24wmf23 after all), see https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule. I'm considering deprecating list=backlinks, list=imageusage, and list=embeddedin at some point in favor of these new prop modules. Opinions on this are welcome. [1]: https://gerrit.wikimedia.org/r/#/c/155592/ -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

quotas
by jim andrews 16 Sep '14

16 Sep '14

I am hoping that the mobile app I create that uses your API will sell lots of copies. Could happen. You never know. It’s a fun app. The only thing I’ve read about quotas indicates that if one is calling the API from a JavaScript page, which I am, then the URL does not have to have an identifier like id=vispo.com or whatever, so that the service is free and there are no limiting quotas. This seems too good to be true. Can you point me to the appropriate doc, please? Thanks, Jim Andrews http://vispo.com

1 0

request: please include article summary in
by jim andrews 16 Sep '14

16 Sep '14

Do you know if there are any plans to include an article summary in the list=geosearch results? That would be terrific. I’ve been using the geonames.org API for retrieving Wikipedia articles, and it returns a brief (350-400 character?) article summary which seems to be the first 350-400 characters (or so) of the Wikipedia articles. This is very useful in search results, of course. The user can use that information to decide which of the several links to click. The title alone is often rather mysterious. It often does not provide enough info for the user to make a decision as to which link to click, if any. Currently, the info I get back from your service ( https://www.mediawiki.org/wiki/Extension:GeoData#API ) has these fields: <gs pageid="167267" ns="0" title="City Lights Bookstore" lat="37.7976" lon="-122.407" dist="1331" primary="" /> I’m suggesting it also include a ‘summary’ field consisting of the first 350-400 characters of the article. Is that feasible? What I currently do is use geonames as first choice and if that fails, I use your service. It would be nice to be able to use your service as first choice. Thanks, Jim Andrews

3 10

[Mediawiki-api-announce] Deprecation of action=query&prop=categorymembers cmstartsortkey and cmendsortkey
by Brad Jorsch (Anomie) 13 Sep '14

13 Sep '14

The fact that the hex-encoded sortkey must be converted to binary format for prop=categorymembers cmstartsortkey and cmendsortkey has long been an odd wart in the API. Bug 70690[1] showed that the binary values for these parameters is actively breaking on some wikis. In Gerrit change 159746[2] these parameters have been deprecated in favor of new parameters cmstarthexsortkey and cmendhexsortkey which take the sortkey in the same hex-encoded format that is returned by the API. This change should be deployed to WMF wikis with 1.24wmf22, see https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule. [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=70690 [2]: https://gerrit.wikimedia.org/r/#/c/159746/ -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

Re: [Mediawiki-api] [Wikitech-l] OPW final report and thanks to you all
by Sumana Harihareswara 11 Sep '14

11 Sep '14

Frances, thank you for your work and for your final report. I wish you well in your ongoing task ("Finish writing search function for JWBF") and your future endeavors. I think Frances's internship went pretty well, and I wrote up a case study of why it worked out: http://www.harihareswara.net/sumana/2014/08/13/1 (team of mentors, frequent communication, strong relationship, Frances is great, scope small & cuttable, metacognition). Thanks so much to Tollef Fog Heen, Brad Jorsch, Merlijn van Deen, and everyone else who helped mentor or advise this project. On Wed, Sep 10, 2014 at 2:02 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote: > > PS: Good luck with the Growstuff API! I've just signed up, so keep me in > the loop about any cool applications you develop. :) > > Dan > <https://lists.wikimedia.org/mailman/listinfo/wikitech-l> Dan, here's more information on the Growstuff features awaiting funding for Frances to work on them: https://www.indiegogo.com/projects/growstuff And I've already pointed one new contributor to https://www.mediawiki.org/wiki/API:Client_code/Gold_standard -- new folks who know various programming languages can now follow Frances's lead by reading the standard, reviewing existing libraries, and writing evaluations. Which is cool. best, Sumana Harihareswara

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api September 2014