Mediawiki-api

mediawiki-api@lists.wikimedia.org

1264 discussions

[Mediawiki-api-announce] New features: Alternative multi-value separator and Unicode normalization warnings
by Brad Jorsch (Anomie) 30 Aug '16

30 Aug '16

Both of these changes should be deployed to WMF wikis with 1.28.0-wmf.17, see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule. == Alternative multi-value separator == With the merging of Gerrit change 305126,[1] if a value for a multi-valued parameter must contain pipe characters (U+007C, "|"), it will now be possible to use the Unit Separator character (U+001F) instead. As this character is not otherwise valid input for any strings in MediaWiki, its use here should not conflict with any valid input. To signal that you're using this feature, the whole multi-value parameter must also be prefixed with the Unit Separator character. For example, you can now use meta=allmessages to parse the "search-rewritten" message with the text "foo|bar" as $1 and "foo|baz" as $2: https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&meta=allmessag… <https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&meta=allmessag…> Client libraries should consider updating to use this feature when asked to send a multi-valued parameter with one or more values containing pipe characters. == Unicode normalization warnings == The API has always expected input as NFC-normalized Unicode represented as UTF-8. Non-NFC-normalized UTF-8 input would be silently normalized, and in the query string non-UTF-8 input would be interpreted as being in a fallback encoding (such as Windows-1252) and converted to Unicode. This sometimes led to subtle bugs when input was unexpectedly converted. With the merging of Gerrit change 306491,[2] the API will now issue a warning when input was subject to such conversion, which is hoped to make it more obvious to clients when their input was subject to conversion. When this happens in the 'titles' parameter for ApiPageSet-using modules, the response will also include the conversion of each title in the existing 'normalized' element. Since the API result cannot directly represent non-normalized data, these entries will have the 'from' element percent-encoded and a 'fromencoded' boolean will be included alongside to indicate this. This normalization step is separate from the existing Title normalization (uppercasing the first letter and replacing underscores with spaces), so two entries may be generated in the 'normalized' element. See https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&titles=a%CC%8A… for an example showing the new warning and normalization entries. [1]: https://gerrit.wikimedia.org/r/#/c/305126/ [2]: https://gerrit.wikimedia.org/r/#/c/306491/ -- 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-announce] Section edit REST API end point to be replaced next week
by Gabriel Wicke 25 Aug '16

25 Aug '16

Hello, REST API users. We are planning to deploy a new REST API endpoint for section editing next week. This will replace the current /transform/sections/to/wikitext/ <https://en.wikipedia.org/api/rest_v1/#!/Transforms/post_transform_sections_…> end point, and will provide the same functionality in a more streamlined and extensible format. The existing end point is classified as unstable <https://www.mediawiki.org/wiki/API_versioning#Unstable>, which guarantees that we are making an effort to avoid breaking existing clients. According to our data, the end point is basically unused at present, which is why we are aiming at a fairly speedy deploy around Tuesday next week (Aug 30). If you are using this end point at present & have concerns about its removal, then let us know here. Best regards, the WMF Services Team <https://www.mediawiki.org/wiki/Wikimedia_Services>. -- 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

Finding out Wikidata item out of Wikipedia article via API
by Adrian Tineo 11 Aug '16

11 Aug '16

Hi all This is my first post in this list. I'm not clear if this is the best place for me to ask this question, so feel free to recommend some other contact point. Context: I am trying to find out via API what is the Wikidata item from a Wikipedia page. This is visible in the Tools side bar in the Wikipedia page but I can't figure out how to get this information from the API. Question: How can I get via API the Wikidata item matching a given Wikipedia article? Example: Say that the starting point is Albert Einstein's page in the English Wikipedia (https://en.wikipedia.org/wiki/Albert_Einstein). I can get the page content via API like so: https://en.wikipedia.org/w/api.php?action=query&format=json&titles=Albert Einstein&prop=revisions&rvprop=content I can get plenty of other info by using some other params to the query action. Some I have tried include: prop:extlinks, prop:info, meta:filerepoinfo, etc. None of these contain the Wikidata item matching the article though. I couldn't find out anything about it in the MediaWiki API help. As of now, the best I can do is: 1. Query Wikidata with the page title like so: https://www.wikidata.org/w/api.php?format=json&action=wbsearchentities&sear… Einstein&language=en 2. Browse through the output for the desired Albert Einstein entry among: * Q937, Albert Einstein, German-American physicist and founder of the theory of relativity * Q13426745, Albert Einstein, Studio album by Prodigy and The Alchemist * Q15990626, Albert Einstein, Wikimedia disambiguation page * 3 more entries This adds a complication, as I need the intelligence to tell which is the Wikidata item I was looking for, whereas in the Wikipedia page in the browser I can access the item (Q937) directly. Any help much appreciated. Regards, Adrian Tineo

2 2

API login
by John 07 Aug '16

07 Aug '16

Why in the hell has basic API logins stopped working? I now need to either set up an Oauth provider/client or use Special:Botpassword. Having a standard login option should be available, otherwise anyone who codes for using the API is going to get screwed. Apparently it will require setting up special permissions and login processes depending on what version of MW the wiki is using... Why cant we just keep a standard process and allow for more options?

3 2

[Mediawiki-api-announce] BREAKING CHANGE: Removal of lgtoken, cookieprefix, and sessionid response values from action=login
by Brad Jorsch (Anomie) 29 Jul '16

29 Jul '16

These response values, deprecated in December 2015, will no longer be returned in the response to action=login. This change should be deployed to WMF wikis with 1.28.0-wmf.13, see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule. Note that the lgtoken *parameter* to action=login is not removed, nor is the 'token' response value included along with a NeedToken response. This is expected to have a low client impact, since proper handling of the Set-Cookie headers (rather than manually building cookies using these response values) has been effectively required for some time now. The original deprecation announcement is quoted below: On Tue, Dec 15, 2015 at 11:11 AM, Brad Jorsch (Anomie) < bjorsch(a)wikimedia.org> wrote: > Long ago, the only mechanism for session management in MediaWiki was > certain cookies set by the User class. When ApiLogin was written, in > addition to setting these cookies as usual it also returned some of the > values needed to construct these cookies on the client. Presumably this was > to make things easier for clients that somehow couldn't handle the standard > cookie headers. > > Then CentralAuth came along. Now, constructing the cookies manually would > log you in to the local wiki only, without taking advantage of the SUL > mechanism. > > Then T55032[1] happened, and clients that were using the > manual-construction mechanism had to update their code because one of the > cookie names changed and that wasn't part of the data being returned. > > And soon, we'll have SessionManager and AuthManager, which will make it > possible for login to easily happen in ways that don't involve cookies at > all. > > So it's time to eliminate the pretense that clients can manually construct > the cookies instead of handing the standard HTTP cookie headers. Tentative > plan is to deprecate them now and then remove them sometime during 1.28; if > anyone objects to this schedule, please raise your concerns in > https://phabricator.wikimedia.org/T121527. > > > [1]: https://phabricator.wikimedia.org/T55032 > > -- > 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

[Mediawiki-api-announce] ApiParse: Deprecation of prop=headitems (and removal of partial ResourceLoader code)
by Brad Jorsch (Anomie) 28 Jul '16

28 Jul '16

The 'headitems' property for action=parse has been deprecated, and using it will return a warning. If constructing a page from scratch, you should use prop=headhtml instead. If updating an existing on-wiki page, use prop=modules|jsconfigvars and load them into the existing ResourceLoader code with mw.config.set() and mw.loader.using(). Also, the 'headitems' property will no longer return code related to ResourceLoader. Loading ResourceLoader would require additional data that is not sent by 'headitems', and given the deprecation it's not worth the trouble to add that data. -- 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-announce] Shutting down deprecated rest.wikimedia.org by September 1st
by Gabriel Wicke 22 Jul '16

22 Jul '16

We are going to finally switch off the deprecated domain rest.wikimedia.org by September 1st. This should not affect any REST API users, as this domain has been officially deprecated since January & sunset since April [1]. Since then, requests to that domain have returned an error informing users about the move. Access to the REST API is exclusively through the main project domains, following the following pattern: https://en.wikipedia.org/api/rest_v1/?doc Thank you for your cooperation, -- Gabriel Wicke Principal Engineer, Wikimedia Foundation [1]: https://lists.wikimedia.org/pipermail/wikitech-l/2016-April/085309.html _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

Where are information about copyright, assessments, license, attribution, url?
by Luca Libonati 28 Jun '16

28 Jun '16

Hi all, looking at https://dumps.wikimedia.org/commonswiki/latest/, I'm not able to find where information about copyright, assessments, license, attribution, url are. Inside image table in img_metadata field there are other image information but not the one said before. If I call the url https://en.wikipedia.org/w/api.php?action=query&format=xml&prop=imageinfo&t… I can see all theese information Which is the dump that stores copyright, assessments, license, attribution, url...? Thank you. Best, Luca

2 3

[Mediawiki-api-announce] [BREAKING CHANGE] meta=notifications outputs array instead of object since 1.27.0-wmf.22
by Roan Kattouw 28 Jun '16

28 Jun '16

As of 1.27.0-wmf.22 (deployed to WMF wikis April 26-28) and MediaWiki release 1.27 (specifically, this change <https://phabricator.wikimedia.org/rECHOb10bd700333d2eef10c7df0a9946b87fd451…> in Echo), meta=notifications will return its result as an array rather than an object. Previously, the meta=notifications output looked like: { "query": { "notifications": { "list": { "12345": { "id": "12345", "type": "edit-user-talk", ... }, ... } Now, it looks like: { "query": { "notifications": { "list": [ { "id": "12345", "type": "edit-user-talk", ... }, ... ] My apologies for the late announcement, and thanks to APerson and Cienca Al Poder for noticing <https://phabricator.wikimedia.org/T138690> and encouraging me to write this announcement. _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

please unsubscribe me I can't
by François Colonna 27 Jun '16

27 Jun '16

Hello could you please unsubscribe me. I have got an issue with mailman : I could not received my password and thus login. Thanks François Colonna

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api