Mediawiki-api February 2014

mediawiki-api@lists.wikimedia.org

7 participants
12 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

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

Changes in API action=parse&mobileformat=...
by Max Semenik 10 Jun '14

10 Jun '14

Hi, in response to bug 54607 [1], we've changed the semantics of the mobileformat parameter to action=parse == Summary == Previously, it used to accept strings 'html' or 'wml', later just 'html' and modify the structure of output (see below). This was problematic because you needed to retrieve the HTML from output in different ways, depending on whether mobileformat is specified or not. Now, mobileformat is a boolean parameter, that is if there's a 'mobileformat' parameter in request, it will be treated as "the output should be mobile-friendly", regardless of value. And the output structure will be the same. For compatibility with older callers, mobileformat=(html|wml) will be special-cased to return the older structure at least for 6 month from now. These changes will start being rolled out to the WMF sites starting from tomorrow, Tuesday October 24th and this process will be complete by October 31st. == Examples == === Non-mobile parse === api.php?action=parse&format=xml { "parse": { "title": "...", "text": { "*": "foo" } } } api.php?action=parse&format=json <?xml version="1.0"?> <api> <parse title="..." displaytitle="..."> <text xml:space="preserve">foo</text> </parse> </api> === Parse that outputs mobile HTML, old style === api.php?action=parse&format=json&mobileformat=html { "parse": { "title": "API", "text": "foo" } } api.php?action=parse&format=xml&mobileformat=html <?xml version="1.0"?> <api> <parse title="..." text="foo" displaytitle="..."> </parse> </api> === Parse that outputs mobile HTML, new style === api.php?action=parse&format=...&mobileformat Same as for non-mobile parses. == FAQ == Q: I didn't use mobileformat before, does anything change for me? A: No. Q: I use mobileformat=html, will my bot/tool be broken now? A: No, you will have 6 months to switch to new style. Q: I'm only planning to use mobileformat, what should I do? A: Just use the new style. Q: How did this format discrepancy appear in the first place? A: To err is human. ----- [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=54607 -- Best regards, Max Semenik ([[User:MaxSem]])

2 2

[Mediawiki-api-announce] Redirect querying changes and improvement
by Brad Jorsch (Anomie) 25 Feb '14

25 Feb '14

The API has long had difficulty in reporting the redirects to a title: the best that could be done was to use list=backlinks&blfilterredir=redirects, but that has issues if the redirect has additional wikilinks in the non-redirect content (e.g. bug 57057[1]). It also had issues with file and category redirects (e.g. bug 27621[2]). With the merge of Gerrit change 104764,[3] the API has a new prop=redirects to query the redirects table directly. There is also a new list=allredirects, corresponding to existing modules such as list=alllinks. This should be deployed to WMF sites with 1.23wmf16.[4] In addition, since Gerrit change 105829 (deployed with 1.23wmf10[4]) file and category redirects will no longer show up when using list=imageusage or list=categorymembers, unless the target file or category is also included in the non-redirect content. They will be reported in list=backlinks instead. [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=57057 [2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=27621 [3]: https://gerrit.wikimedia.org/r/#/c/104764/ [4]: https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap [5]: https://gerrit.wikimedia.org/r/#/c/105829/ -- 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

Feedback for mediawiki api development course on codecademy.
by Diwanshi Pandey 25 Feb '14

25 Feb '14

Hello everyone, I am Diwanshi Pandey, an OPW intern. I'd like to have your feedback on the course I have created on codecademy for mediawiki api with help of my mentor Yuri Astrakhan. A little insight: The course is about parsing and querying mediawiki api. Initially we created one course which included 44 exercises but according to codecademy's guidelines their course are for beginners and should have maximum 30 exercises in one course. So we did a split up into two courses: One is Introduction to Wikipedia API<http://www.codecademy.com/courses/web-beginner-en-vj9nh/0/1>and other is Wikipedia:Query API <http://www.codecademy.com/courses/web-beginner-en-yd3lp/0/1>. Also due to api security and restrictions we couldn't implement tutorial on "editing wiki pages through api call" from a non wiki site yet. We are waiting till we find a good and easy way to demo that. Feedback may include: * Are the exercises easy to understand for novice users/developers? * Are changes needed in the look of exercises? * Are there any exercises which need not to be implemented or in too depth? * Any other thing? Thanks, -- *Regards,* *Diwanshi Pandey*

1 0

Re: [Mediawiki-api] Stripping paragraph tags from parse output
by bawolff 22 Feb '14

22 Feb '14

> > On Feb 5, 2014 8:38 AM, "Zachary Harris" <zacharyharris(a)hotmail.com> wrote: > > > > 1) Is there a way to tell the Parser that you don't want the initial DOM > > element wrapped in paragraph tags? (For example, if you are client-side > > injecting the mw-api contents into already existing content and you > > don't want a paragraph break there?) It seems this same question was > > effectively asked at > > http://www.mediawiki.org/wiki/API_talk:Parsing_wikitext and hasn't been > > answered yet. > > If the parser can't be configured in this way and I have to strip > > possibly undesired openings tags myself do I have any guarantees on what > > to expect? Not really. Even innternally in core (in OutputPage and in Message class) we regex out the <p> when its not wanted. (Icky!) > > > > > 2) Why do JSON results come back, for example, in the form of > > parse.text['*'] rather than just parse.text? With format=XML the result > > is just <parse><text>the stuff</text></parse>. Why the "*"? Sorry if > > this question is dumb. > > >From what i've heard, historical reasons mostly. I believe its so that the xml can be mechanically turned into json - the text body of an element is treated like an attribute * so that if that element had attributes they could also be represented. -bawolff

3 2

[Mediawiki-api-announce] Small breaking change to the case of result returned by action=createaccount
by Brad Jorsch (Anomie) 20 Feb '14

20 Feb '14

---------- Forwarded message ---------- From: Yuvi Panda <yuvipanda(a)gmail.com> Date: Thu, Feb 20, 2014 at 9:05 PM Hello! Account creation[1] was enabled on Wikimedia wikis a few weeks ago. There is a bug[2] in the implementation that returns status codes in all lower case ('success', 'needtoken') rather than in CamelCase ('Success', 'NeedToken'), which is what all other parts of the API use. There is a patch[3] that will make action=createaccount behave similar to the other actions. If you have code that uses action=createaccount, you might have to tweak your client to uppercase a few characters. [1]: https://www.mediawiki.org/wiki/API:Account_creation [2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=61663 [3]: https://gerrit.wikimedia.org/r/#/c/114473/ -- Yuvi Panda T http://yuvi.in/blog -- 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

Confermation
by Mikey Duzan 16 Feb '14

16 Feb '14

1 0

[Mediawiki-api-announce] Modification to FlaggedRevs timestamp outputs
by Brad Jorsch (Anomie) 14 Feb '14

14 Feb '14

(Sorry for the double post, mediawiki-api subscribers) ---------- Forwarded message ---------- From: This, that and the other <at.light(a)live.com.au> Date: Thu, Feb 13, 2014 at 5:46 AM Subject: Modification to FlaggedRevs timestamp outputs A patch is currently in Gerrit [1] to alter the way the FlaggedRevs extension formats some timestamps in its API output. Specifically, the "expiry" attribute generated by action=stabilize, and the "protection_expiry" attribute generated by action=query&prop=flagged, are changed to use an ISO-formatted timestamp (2014-02-13T11:00:00Z) in the output, instead of the current internal format (20140213110000). This change brings the timestamp formatting of FlaggedRevs into line with the rest of the MediaWiki API, and allows external users to parse the timestamp more easily. (This may well affect nobody at all: [2] comes to mind!) TTO -- [1] https://gerrit.wikimedia.org/r/#/c/76460/ [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=44468#c5 _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api February 2014