Movatterモバイル変換

[0]ホーム
URL:

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview
List overview
Download

Mediawiki-apiFebruary 2014

mediawiki-api@lists.wikimedia.org
  • 7 participants
  • 12 discussions
Start a nNew thread

20 Jan '26
Hi there,I'm using the API to extract the raw wiki text from my pages, usingthe "?action=query&titles=Main_Page&export&exportnowrap" syntax. Thatworks perfectly.Now I would like to get the templates expanded out in the result, so Iuse: "?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 tohelp process the wiki text in subsequent steps).Is there a way to expand templates with the API, but leave thecomments intact?Thanks,Kevin
4 5
0 0
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 pagegiven the title of the wikipedia page. I have done some research and foundout that the abstract with be in rvsection=0 So for example if I want the abstract of 'Eiffel Tower" wiki page then I amquerying 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 <revxml:space="preserve"> which represents the abstract of the wikipedia page.But this wiki text also contains the infobox data which I do not need. Iwould like to know if there is anyway in which I can remove the infobox dataand get only the wikitext related to the page's abstract Or if there is anyalternative method by which I can get the abstract of the page directly.Looking forward to your help.Thanks in AdvanceAditya Uppu
4 3
0 0
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 withUploadWizard" 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 withUploadWizard" 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
0 0

09 Jun '14
Hi, in response to bug 54607 [1], we've changed the semantics of themobileformat 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 problematicbecause 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 bemobile-friendly", regardless of value. And the output structure willbe the same. For compatibility with older callers,mobileformat=(html|wml) will be special-cased to return the olderstructure at least for 6 month from now. These changes will startbeing rolled out to the WMF sites starting from tomorrow, TuesdayOctober 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=...&mobileformatSame 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
0 0

25 Feb '14
The API has long had difficulty in reporting the redirects to a title:the best that could be done was to uselist=backlinks&blfilterredir=redirects, but that has issues if theredirect 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 newprop=redirects to query the redirects table directly. There is also anew list=allredirects, corresponding to existing modules such aslist=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 usinglist=imageusage or list=categorymembers, unless the target file orcategory is also included in the non-redirect content. They will bereported 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 EngineerWikimedia Foundation_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
1 0
0 0

25 Feb '14
Hello everyone,I am Diwanshi Pandey, an OPW intern. I'd like to have your feedback on thecourse I have created on codecademy for mediawiki api with help of mymentor Yuri Astrakhan.A little insight:The course is about parsing and querying mediawiki api.Initially we created one course which included 44 exercises but accordingto codecademy's guidelines their course are for beginners and should havemaximum 30 exercises in one course.So we did a split up into two courses:One is Introduction to WikipediaAPI<http://www.codecademy.com/courses/web-beginner-en-vj9nh/0/1>andother is Wikipedia:QueryAPI <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 arewaiting 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
0 0
>> 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 thexml can be mechanically turned into json - the text body of an element istreated like an attribute * so that if that element had attributes theycould also be represented.-bawolff
3 2
0 0
---------- Forwarded message ----------From: Yuvi Panda <yuvipanda(a)gmail.com>Date: Thu, Feb 20, 2014 at 9:05 PMHello!Account creation[1] was enabled on Wikimedia wikis a few weeks ago.There is a bug[2] in the implementation that returns status codes inall lower case ('success', 'needtoken') rather than in CamelCase('Success', 'NeedToken'), which is what all other parts of the APIuse. There is a patch[3] that will make action=createaccount behavesimilar to the other actions.If you have code that uses action=createaccount, you might have totweak 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 Thttp://yuvi.in/blog-- Brad Jorsch (Anomie)Software EngineerWikimedia Foundation_______________________________________________Mediawiki-api-announce mailing listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
1 0
0 0
Confermation
by Mikey Duzan 15 Feb '14

15 Feb '14
1 0
0 0

13 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 AMSubject: Modification to FlaggedRevs timestamp outputsA patch is currently in Gerrit [1] to alter the way the FlaggedRevsextension 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, arechanged to use an ISO-formatted timestamp (2014-02-13T11:00:00Z) in theoutput, instead of the current internal format (20140213110000).This change brings the timestamp formatting of FlaggedRevs into line withthe rest of the MediaWiki API, and allows external users to parse thetimestamp 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 listMediawiki-api-announce(a)lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
1 0
0 0
Results per page:
[8]ページ先頭
©2009-2026 Movatter.jp