Mediawiki-api

mediawiki-api@lists.wikimedia.org

1264 discussions

[Mediawiki-api-announce] Wikimedia REST API hits v1.0
by Gabriel Wicke 07 Apr '17

07 Apr '17

It is official: The Wikimedia REST API <https://www.mediawiki.org/wiki/REST_API>, your scalable and fresh source of Wikimedia content and data in machine-readable formats, is now ready for full production use. The 1.0 release means that you can now fully rely on the stability guarantees set out in the API versioning policy <https://www.mediawiki.org/wiki/API_versioning>. Read more about the stability levels, use cases, as well as technical background on how the REST API integrates with our caching layers in our blog post: https://blog.wikimedia.org/2017/04/06/wikimedia-rest-api/ We are looking forward to your feedback at https://www.mediawiki.org/wiki/Talk:REST_API, or here on-list. This release was made possible by the hard work of many. First of all, the Services team <https://www.mediawiki.org/wiki/Wikimedia_Services> (Marko Obrovac, Petr Pchelko and Eric Evans), created the general API proxy and storage functionality, and curated the API documentation <https://en.wikipedia.org/api/rest_v1/>. The actual end points are co-designed with, and largely backed, by services developed by the following WMF teams: Editing (Parsing <https://www.mediawiki.org/wiki/Parsing> and citoid <https://www.mediawiki.org/wiki/Citoid>), Reading <https://www.mediawiki.org/wiki/Reading> (Infrastructure <https://www.mediawiki.org/wiki/Wikimedia_Reading_Infrastructure_team> and Web <https://www.mediawiki.org/wiki/Reading/Web>), and Analytics <https://www.mediawiki.org/wiki/Analytics>. Volunteer Moritz Schubotz and the MathJax <https://www.mathjax.org/> community contributed the math end points, and the PDF end point is powered by the open source electron-render-service <https://github.com/msokk/electron-render-service> project. Finally, the WMF techops team <https://www.mediawiki.org/wiki/Wikimedia_Technical_Operations> runs the excellent caching infrastructure that makes this API scale so well, and have helped with many aspects from hardware procurement to firewalling. Thank you all for your hard work! We are looking forward to continuing to work with you all on making this API an even better platform for building user experiences, services, and tools. Cheers, Gabriel and the Services team -- Gabriel Wicke Principal 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

Uploading files to Commons using MediaWiki API
by Ferdinand Zippstein 05 Apr '17

05 Apr '17

Dear MediaWiki developers, I've tried to upload a picture to Commons using api.php, but the MediaWiki API help seems to be somewhat incomplete. For mass uploads I would like to use my own tools or do you recommend using Vicuna or Commonist? Yours sincerely. Fred Zippstein

1 0

Hello. Can i parse somehow wiki pages via API?
by Furkan Gözükara 05 Apr '17

05 Apr '17

For example can i parse this page via an API call? https://tr.wiktionary.org/wiki/gitmek

3 3

Pageview data is now included in the Wikimedia action APIs
by Gergo Tisza 24 Mar '17

24 Mar '17

Pageview information about Wikimedia sites, which has been available for a while through the standalone Pageviews REST API [1], is now available in the action API as well, through the prop=pageviews [2], list=mostviewed [3] and meta=siteviews [4] API modules. An example: https://en.wikipedia.org/w/api.php?action=query&format= jsonfm&errorformat=plaintext&prop=pageviews&list=mostviewed&meta=siteviews& titles=Main+Page&formatversion=2&pvipdays=3&pvimlimit=3&pvisdays=3 The new API modules basically act as a proxy to the REST API, and are meant as a less flexible but more convenient alternative for people who already use the action API. [1] https://wikitech.wikimedia.org/wiki/Analytics/PageviewAPI [2] https://en.wikipedia.org/w/api.php?action=help&modules=query%2Bpageviews [3] https://en.wikipedia.org/w/api.php?action=help&modules= query%2Bmostviewed [4] https://en.wikipedia.org/w/api.php?action=help&modules=query%2Bsiteviews

2 1

[Mediawiki-api-announce] Change in behavior for list=allpages&apfilterredir=(redirects|nonredirects)
by Brad Jorsch (Anomie) 21 Mar '17

21 Mar '17

For performance reasons,[1] when "miser mode" is enabled, as it is on WMF wikis, queries to list=allpages using apfilterredir=redirects and apfilterredir=nonredirects may begin returning fewer than the requested aplimit results before continuation. In extreme cases, zero results may be returned. This change[2] has just been made and will be deployed in the next few hours so Special:AllPages may be re-enabled. This is not classified as a breaking change since the API has reserved the right (since 2009[3] if not earlier) to do this sort of thing as it may become necessary. [1]: https://phabricator.wikimedia.org/T160916 [2]: https://gerrit.wikimedia.org/r/#/c/343681/ [3]: https://phabricator.wikimedia.org/rSVN46845 -- Brad Jorsch (Anomie) Senior 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

MediaWiki APi doubts Liquid Galaxy Project
by Guillem Barbosa 08 Mar '17

08 Mar '17

Hello, my name is Guillem and I'm a student that I'm working in Liquid Galaxy project, and now I have some questions and doubts that I would like to resolve to continue with the project. I have been working with WIkimedia API, I found some information about it and I tried diferent actions to get responses and compare. For example, in my case I want to obtain the most populated cities in the world. First of all, my query will be: " https://en.wikipedia.org/w/api.php?action=query&format=xml &titles=List_of_cities_proper_by_population&prop=revisions&rvprop=content " (in this page there are a list of most populated cities in the world) The response is all the Wikipedia page, and the information text is inside <rev> tag. Then, my task is to parse the text response and obtain the cities name in the list. I would like to know if ther are some posibility to obtain only the cities list, and it will be more easy to get it. Once I have the names of the cities, the next step is to obtain the coordinates for each one. Here I have two possibilities: a new query with API (" https://en.wikipedia.org/w/api.php?action=query&format=xm l&titles=Shanghai&prop=revisions&rvprop=content ") I put the city name in the parameter "title", and then the response is so extended, but I get only the Infobox part to obtein the mainly information about the city. And the second option is to use bdpedia, I find this option searching and it also can be a posibility, but my doubt is: when I search " dbpedia.org/data/Tokyo <http://dbpedia.org/resource/Tokyo> " the properties and values are the same in the wikimedia page for the city? I have discoverd that I can obtain the response in json or xml format. In this way, I could get some information about the city, and search for each tag or property that is well identified. I haven't found the way to obtain more detailed some information about in this case a city (I would like to have the mainly information organizated in tags and then it will be more easy to obtain the results). So, the other option is to do the proces that I have explained, this requires more work but also will be valid. Thanks for you time your sincerely, Guillem.

2 3

Question re getting citation for a particular page
by Fred Zimmerman 28 Feb '17

28 Feb '17

Hi, I would like to get the citation info for a page -- i.e. the bibliographic information about the page itself -- in a JSON, YAML, or BibTex format. How do I accomplish that? I see there is a CiteThisPage extension but I can't get the syntax right. Fred --- Install PageKicker's Algorithmic Publishing Toolkit: git clone http://github.com/fredzannarbor/pagekicker-community.git cd pagekicker-community ./simple-install.sh # build your first book: cd pagekicker-community/scripts bin/builder.sh --seedsviacli "Algorithms; Thomas Cormen; Introduction to Algorithms" --booktitle "Algorithm Demo"

4 3

Re: [Mediawiki-api] [discovery] Some Issues on API:Opensearch
by byeh＠yahoo-inc.com 24 Feb '17

24 Feb '17

Thank you so much for your kind help and clear explanation. The use case is indeed a Chinese-language project, and the examples provided posed a nice illustration of how three kinds of possible outcomes will show in different versions. Here I would like to add another scenario in hope for a further understanding to Wikimedia's language conversion. If you search for "川普" ( Donald Trump in Traditional Chinese ) at OpenSearch API layer with redirects=resolve, [1] the first description should be "唐納·約翰·川普（英語：Donald John Trump，1946年6月14日－），第45任美國總統、著名企業家、作家和節目主持人。他生於紐約市皇后區，為川普集團前任董事長兼總裁及川普娛樂公司的創辦人，他在全世界經營房地產、賭場和酒店，但在就任美國總統後把集團交給他兩名兒子小唐納·川普及艾瑞克·川普管理。", which is Traditional Chinese; however, if the profile parameter is set to restrict,[2] the first description should become "唐纳德·约翰·特朗普（英语：Donald John Trump，1946年6月14日－），第45任美國總統、著名企業家、作家和節目主持人。他生于紐約市皇后区，为特朗普集團前任董事长兼總裁及特朗普娱乐公司的創辦人，他在全世界经营房地产、赌场和酒店，但在就任美國總統後把集團交給他兩名兒子小唐納·川普及艾瑞克·川普管理。, which is Simplified Chinese. This scenario indicates that language conversion happens not just in display time, but also at API layer. To add another interesting point, the API use cases mentioned above [1][2] can even have various outcomes in different machines. The ultimate issue now should be how such language conversions can happen at API layers and how can it be controlled? -- Ben Yeh [1] https://zh.wikipedia.org/w/api.php?action=opensearch&search=%E5%B7%9D%E6%99… [2] https://zh.wikipedia.org/w/api.php?action=opensearch&search=%E5%B7%9D%E6%99… 在 2017年1月26日星期四上午4:24:05 [台北]， Trey Jones<tjones(a)wikimedia.org> 寫道：Let's see if I can help, either directly, or indirectly via Cunningham's Law.[1] I'm reading this as you are searching a Chinese-language project (like zh.wikipedia.org), and getting results that are mixed Traditional and Simplified Chinese. If that's not the case, please elaborate! My understanding, which is admittedly incomplete, is that the text for Chinese-language projects is stored however it was entered (Traditional or Simplified), and is converted at display time. If you look at the main page of zh.wikipedia.org[2] today without being logged in (or in a private browsing window), the featured article link has this text: "2007年欧洲冠军联赛決賽", which uses both 赛 and 賽, with 赛 being the Simplified version of Traditional 賽.[3] If you request the zh-cn version of the page,[4] the text is "2007年欧洲冠军联赛决赛", and both are Simplified "赛". If you request the zh-tw version of the page[5], the text is "2007年歐洲冠軍聯賽決賽", and both are Traditional "賽". So, I believe that explains why you are seeing mixed Traditional and Simplified results. What to do about it? I can't get the Opensearch API to do the conversion in place, but there is a separate API that does the conversion: Parsing wikitext.[6] Unfortunately, I can only get the API to do the conversion (which is based on the uselang parameter) when I submit the text as wikitext,[7][8] which adds some additional tags and a long comment to the results. \u-formatted input doesn't work, and I can't get the conversion to work for json input (i.e., the result of the Opensearch call). That doesn't mean it isn't possible, just that I haven't figured it out. I hope that points you in the right direction, and maybe inspires someone who knows this stuff better than me to help out. —Trey [1] https://meta.wikimedia.org/wiki/Cunningham's_Law[2] https://zh.wikipedia.org/wiki/Wikipedia:%E9%A6%96%E9%A1%B5[3] https://en.wiktionary.org/wiki/%E8%B5%9B[4] https://zh.wikipedia.org/zh-cn/Wikipedia:%E9%A6%96%E9%A1%B5[5] https://zh.wikipedia.org/zh-tw/Wikipedia:%E9%A6%96%E9%A1%B5[6] https://www.mediawiki.org/wiki/API:Parsing_wikitext[7] https://zh.wikipedia.org/w/api.php?action=parse&format=json&prop=text&usela… [8] https://zh.wikipedia.org/w/api.php?action=parse&format=json&prop=text&usela… Trey Jones Software Engineer, Discovery Wikimedia Foundation On Wed, Jan 25, 2017 at 11:22 AM, Adam Baso <abaso(a)wikimedia.org> wrote: +discovery list On Wed, Jan 25, 2017 at 10:15 AM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org> wrote: On Wed, Jan 25, 2017 at 2:09 AM, <byeh(a)yahoo-inc.com> wrote: While I was developing some services based on API:Opensearch, I found that the response of the same url request can be either Simplified Chinese or Traditional Chinese. To be more specific, I would love to know how can I determine the response language form from API layer ( Or other factors that may have impact ) ? Since the document of API:Opensearch doesn't seem to take language into consideration, The OpenSearch Suggestions extension specification[1] does not allow for returning additional metadata such as language with the response. You may want to look at the prefixsearch query module[2] instead which allows for returning the same results in a different format, although I don't know the details of how language variants are handled in the search output. [1]: http://www.opensearch.org/Spec ifications/OpenSearch/Extensio ns/Suggestions/1.1 [2]: https://www.mediawiki.org/wiki /API:Prefixsearch -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation ______________________________ _________________ Mediawiki-api mailing list Mediawiki-api(a)lists.wikimedia. org https://lists.wikimedia.org/ma ilman/listinfo/mediawiki-api ______________________________ _________________ discovery mailing list discovery(a)lists.wikimedia.org https://lists.wikimedia.org/ mailman/listinfo/discovery

2 4

Invalid Token
by Michael 21 Feb '17

21 Feb '17

Sorry, if it turns out as a stupid mistake, but I am at the end of my own knowledge to solve this issue on my MediaWiki 1.28 installation: I am using a python3 script to 1) get the token, and 2) login via 'clientlogin', but I always receive the "error": { "code": "badtoken", "info": "Invalid token", The taken is coming from 'action': 'query', 'meta': 'tokens', 'type': 'login', and I strip the last '\'. This is my submission for Login: Type: <class 'urllib.request.Request'> Contents: {'_full_url': 'https://wiki.xxxxat.com/api.php', 'unredirected_hdrs': {}, '_tunnel_host': None, 'fragment': None, '_data': b'password=Lxxxxxxxx7&action=clientlogin&rememberMe=1&username=Admin&returnu rl=https%3A%2F%2Fwiki.xxxxat.com%2F&logintoken=8f2d58f9cc8336543c7f67cf8a592 6d058a95ede%2B%5C&requestid=byMichael', 'origin_req_host': 'wiki.xxxxat.com', 'selector': '/api.php', 'headers': {'Content-type': 'application/x-www-form-urlencoded'}, 'type': 'https', 'unverifiable': False, 'host': 'wiki.xxxxat.com'} Following the same procedure via ApiSandbox is working fine. Thank you for your help!

3 4

[Mediawiki-api-announce] BREAKING CHANGE: Passwords and other sensitive fields for authentication must be in the POST body
by Brad Jorsch (Anomie) 16 Feb '17

16 Feb '17

As was previously announced, passing the lgpassword or lgtoken parameters to action=login in the query string rather than the POST body will begin to return an error starting with 1.29.0-wmf.13. See https://www.mediawiki.org/wiki/MediaWiki_1.29/Roadmap for the deployment schedule. On Mon, Oct 31, 2016 at 2:44 PM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org > wrote: > Over the past 30 days, there has been exactly one hit to > action=clientlogin with sensitive data in the query string, and none to > action=createaccount, action=linkaccount, and action=changeauthenticationdata. > Beginning in 1.29.0-wmf.1 (to be deployed this week) these actions will now > begin throwing errors if sensitive fields are included in the query string. > > Over the past 30 days, logins have been attempted via action=login for 28 > different user names[1] with sensitive data (lgpassword or lgtoken) in the > query string. This will continue to work for now; my current plan is to > turn that warning into an error on February 15, 2017. > > > [1]: I can't post the list publicly at this time. If you want to know if > you're one of the 28, put your user agent into https://meta.wikimedia.org/ > wiki/Special:ApiFeatureUsage and look for "login-params-in-query-string". > > > On Fri, Aug 19, 2016 at 3:24 PM, Brad Jorsch (Anomie) < > bjorsch(a)wikimedia.org> wrote: > >> For improved safety, passwords and other sensitive fields for >> authentication should not be included in the request URI during a POST. >> Instead, they should be in the POST body where they are less likely to be >> included in log files. With the merge of Gerrit change 305545,[1] the API >> will now produce a warning if such fields are detected in the URI. This >> should be deployed to WMF wikis with 1.28.0-wmf.16, see >> https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule. >> >> This affects the following modules and fields: >> * action=login: 'lgpassword' >> * action=clientlogin, action=createaccount, action=linkaccount, and >> action=changeauthenticationdata: Any fields reported as "sensitive" by >> action=query&meta=authmanagerinfo or by UI or REDIRECT responses. >> Currently, this affects the 'password' and 'retype' fields. >> >> The 'lgtoken' field for action=login will now also issue a warning if >> placed in the request URI. The error code for other tokens being in the >> request URI has changed from 'mustposttoken' to 'mustpostparams'. >> >> To check if your client's user agent is detected making such submissions, >> you can also use ApiFeatureUsage[2] and look for >> '<action>-params-in-query-string' once 1.28.0-wmf.16 is rolled out to >> wikis your client is logging in to. >> >> It is planned that these warnings will be changed to errors during 1.29. >> Let's avoid having a repeat of T142155,[3] update your code ASAP instead of >> waiting until it breaks. Thanks. >> >> [1]: https://gerrit.wikimedia.org/r/#/c/305545/ >> [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage >> [3]: https://phabricator.wikimedia.org/T142155 >> >> -- >> Brad Jorsch (Anomie) >> Senior Software Engineer >> Wikimedia Foundation >> > > > > -- > Brad Jorsch (Anomie) > Senior Software Engineer > Wikimedia Foundation > -- Brad Jorsch (Anomie) Senior 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api