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
Hi All,
I'm writing an API module that I'd like to take 'complex' data for one of
the parameters, e.g.
{
"action": "example",
"token": "<some csrf token>",
"data": [
{"key": "value1", "otherkey": "othervalue1"},
{"key": "value2", "otherkey": "othervalue2", "optionalkey":
"optionalvalue"},
{"key": "value3", "otherkey": "othervalue3"}
]
}
The list in data can grow to several hundred elements all of which contain
the same 2 keys with an optional third. For reference, I'm developing on
mw1.31, but I can swap to something more recent if that's where new
possibilities become available.
This module takes POST requests, so I'd just send it as part of the request
body, but when it comes to deserialising it, I'm not really sure what to
deserialise it to as everything seems to assume primitive values, e.g.
strings, integers, etc. when it comes to setting the parameter type. I'm
not averse to claiming it's a string and deserialising it myself, but my
attempts so far haven't proved successful. I also tried writing a phpunit
test which displayed different behaviour (it seems to have quietly lost the
value) and using the mwapi python library for an integration/end-to-end
test which caused a third behaviour by quietly joining the elements in the
list into a string. I get the feeling what I'm trying to do is at the very
least non-standard for mediawiki.
Does anyone have experience in trying to do this or know of prior art that
does something similar?
Cheers,
Matt
Just out of curiosity, is there any recommended way to parse out "which" parameter goes wrong. For example, we have "unknown_action" before. Now it gets merged into "badvalue", and the response looks like this:
{
"error": {
"code": "badvalue",
"info": "Unrecognized value for parameter \"action\": test.",
"*": "See https://test2.wikipedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
},
"servedby": "mw1361"
}
Do I have to parse into .error.info content to know the parameter name? Would its content change (such as localized) under certain situation?
Thanks,
Xinyan
-----Original Message-----
From: Mediawiki-api <mediawiki-api-bounces(a)lists.wikimedia.org> On Behalf Of mediawiki-api-request(a)lists.wikimedia.org
Sent: Wednesday, February 5, 2020 8:00 PM
To: mediawiki-api(a)lists.wikimedia.org
Subject: Mediawiki-api Digest, Vol 150, Issue 4
Send Mediawiki-api mailing list submissions to
mediawiki-api(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
or, via email, send a message with subject or body 'help' to
mediawiki-api-request(a)lists.wikimedia.org
You can reach the person managing the list at
mediawiki-api-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Mediawiki-api digest..."
Today's Topics:
1. [Mediawiki-api-announce] BREAKING CHANGE: Parameter
validation error codes (Brad Jorsch (Anomie))
2. [Mediawiki-api-announce] BREAKING CHANGE: Stricter validation
of integer-type parameters (Brad Jorsch (Anomie))
3. Re: [Mediawiki-api-announce] BREAKING CHANGE: Parameter
validation error codes (Furkan Gözükara)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Feb 2020 13:24:32 -0500
From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org>
To: mediawiki-api-announce(a)lists.wikimedia.org
Subject: [Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE:
Parameter validation error codes
Message-ID:
<CAEepRSsewEZrOO97166BXLsEQxXc2QZ5Gdyxetkwj21yLfdsZw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The error codes that may be changing are some of those representing invalid values for API parameters. Notably, the following will change:
- "noX", indicating that a required parameter was not specified, becomes
"missingparam".
- "unknown_X", indicating that an unrecognized value was specified for
an enumerated-value parameter, becomes "badvalue".
- "too-many-X", indicating that too many values were supplied to a
multi-valued parameter, becomes "toomanyvalues".
- "baduser_X", "badtimestamp_X", and so on become "baduser",
"badtimestamp", and so on.
Note this is not a comprehensive list, other codes may be changing as well.
These changes make the error codes more predictable, at the expense of not indicating in the code which parameter specifically triggered the error. If you have a use case where knowing which parameter triggered the error is needed, please let us know (by replying to this message or by filing a request in Phabricator) and we'll add the necessary error metadata.
The human-readable text is also changing for some of these errors (with or without error code changes), and for a few the error metadata may be changing (e.g. "botMax" changes to "highmax" for limit-type warnings in non-back-compat error formats).
This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/mediawiki-api/attachments/20200204/54…>
-------------- next part --------------
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
------------------------------
Message: 2
Date: Tue, 4 Feb 2020 13:24:34 -0500
From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org>
To: mediawiki-api-announce(a)lists.wikimedia.org
Subject: [Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE:
Stricter validation of integer-type parameters
Message-ID:
<CAEepRSs8vkkwQD_xKv2WR+qmJnzxhD9Uv_LfRc81bUQeYw5KoA(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Various unusual values for integer-type parameters to the Action API will no longer be accepted. Acceptable values will consist of an optional sign (ASCII `+` or `-`) followed by 1 or more ASCII digits.
Values that were formerly allowed, and will now result in a "badinteger"
error, include:
- Values with extraneous whitespace, such as " 1".
- "1.9", formerly interpreted as "1".
- "1e1", formerly interpreted as either "1" or "10" at various times.
- "1foobar", formerly interpreted as "1"
- "foobar", formerly interpreted as "0".
Most clients should already be using correct formats, unless they are taking direct user input without validation.
This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/mediawiki-api/attachments/20200204/31…>
-------------- next part --------------
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
------------------------------
Message: 3
Date: Tue, 4 Feb 2020 23:52:58 +0300
From: Furkan Gözükara <monstermmorpg(a)gmail.com>
To: "MediaWiki API announcements & discussion"
<mediawiki-api(a)lists.wikimedia.org>
Subject: Re: [Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE:
Parameter validation error codes
Message-ID:
<CAB+rNzBACGY79rSbtm0bRz8JFwEEeNW5kYSskPGY2rS55ocaTA(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
How can i get file full path from file template?
For example * {{audio|en|en-us-dictionary.ogg|Audio (US, California)}}
On Tue, Feb 4, 2020 at 9:25 PM Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>
wrote:
> The error codes that may be changing are some of those representing
> invalid values for API parameters. Notably, the following will change:
>
> - "noX", indicating that a required parameter was not specified,
> becomes "missingparam".
> - "unknown_X", indicating that an unrecognized value was specified for
> an enumerated-value parameter, becomes "badvalue".
> - "too-many-X", indicating that too many values were supplied to a
> multi-valued parameter, becomes "toomanyvalues".
> - "baduser_X", "badtimestamp_X", and so on become "baduser",
> "badtimestamp", and so on.
>
> Note this is not a comprehensive list, other codes may be changing as well.
>
> These changes make the error codes more predictable, at the expense of
> not indicating in the code which parameter specifically triggered the
> error. If you have a use case where knowing which parameter triggered
> the error is needed, please let us know (by replying to this message
> or by filing a request in Phabricator) and we'll add the necessary error metadata.
>
> The human-readable text is also changing for some of these errors
> (with or without error code changes), and for a few the error metadata
> may be changing (e.g. "botMax" changes to "highmax" for limit-type
> warnings in non-back-compat error formats).
>
> This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
> See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.
>
> --
> 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
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/mediawiki-api/attachments/20200204/2a…>
------------------------------
Subject: Digest Footer
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
------------------------------
End of Mediawiki-api Digest, Vol 150, Issue 4
*********************************************
Hi folks.
*This is my first time using this mail list*, so if this is not the right
place to ask this kind of question please lemme know about how I should
proceed in this case.
*Question*
I have basically downloaded from MediaWiki API a lot of pages related to
mathematics. Some of them are just *duplicated of the same Article*, but
with one difference being their title, such as different way os calling the
same subject, or letter that differs from one and another, ao so on and so
forth.
One example that I can show you right away is:
- "Adição_de_*s*egmentos", and
- "Adição_de_*S*egmentos",
both written in portuguese (my native language). The only difference
between the titles are just the lowercase and uppercase of the letter
"s".As I was testing on the URL's, it seems that *they both are the same
article, but redirecting from different links to the official "title".*
Keeping in mind those kind of duplicates, when I've started *to analyse the
statistics of views on a specific article*, while going through its cases,
I was expecting to receive the following structure of data:
- The old ones (deprecated) would hold views until some day X, and then
it would have nothing to further count and show;
- The up-to-date titles would have data starting from day X and then
would hold until the last day that I want to analyse.
Nothing too crazy to expect from the database. But that was not what
happened. *There are plenty of articles that are still receiving views even
though they all redirect to another article*. At first, I've just thought
that people are getting to the articles's content with different links
available on search engines, such as google, so all views must be
independent from one another. The problem is, after testing on the google
platform different search for *the same Wikipedia's article I can only get
the* *up-to-date articles, not the old ones.*
1. How can this be possible?
2. But more important for me, are all acesses on the deprecated articles
made by bots or old links available on old pages from other sites?
3. Are the count on all different article's title independent?
4. If so, how could I be able to even track all the possible acesses on
a particular subject to create an effective study o it?
Anyway, this is (if I remember well) the fourth time I'm trying to get a
proper answer for my question, and I'm hopping I'll get it soon.
Thanks!
Marco Antonio
Graduando em Matemática Pura na USP | Divulgador Científico
<https://www.facebook.com/ViaSaber> <https://www.linkedin.com/in/magcastro/>
<https://www.instagram.com/marcoantoniograziano/>
The error codes that may be changing are some of those representing invalid
values for API parameters. Notably, the following will change:
- "noX", indicating that a required parameter was not specified, becomes
"missingparam".
- "unknown_X", indicating that an unrecognized value was specified for
an enumerated-value parameter, becomes "badvalue".
- "too-many-X", indicating that too many values were supplied to a
multi-valued parameter, becomes "toomanyvalues".
- "baduser_X", "badtimestamp_X", and so on become "baduser",
"badtimestamp", and so on.
Note this is not a comprehensive list, other codes may be changing as well.
These changes make the error codes more predictable, at the expense of not
indicating in the code which parameter specifically triggered the error. If
you have a use case where knowing which parameter triggered the error is
needed, please let us know (by replying to this message or by filing a
request in Phabricator) and we'll add the necessary error metadata.
The human-readable text is also changing for some of these errors (with or
without error code changes), and for a few the error metadata may be
changing (e.g. "botMax" changes to "highmax" for limit-type warnings in
non-back-compat error formats).
This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.
--
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
Various unusual values for integer-type parameters to the Action API will
no longer be accepted. Acceptable values will consist of an optional sign
(ASCII `+` or `-`) followed by 1 or more ASCII digits.
Values that were formerly allowed, and will now result in a "badinteger"
error, include:
- Values with extraneous whitespace, such as " 1".
- "1.9", formerly interpreted as "1".
- "1e1", formerly interpreted as either "1" or "10" at various times.
- "1foobar", formerly interpreted as "1"
- "foobar", formerly interpreted as "0".
Most clients should already be using correct formats, unless they are
taking direct user input without validation.
This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.
--
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
I posted the topic below at
https://www.mediawiki.org/wiki/Extension_talk:ReadingLists and was
hoping for some feedback
> I'm trying to use the readinglists setup command and running in to a
> permission denied message.
>
> I think the problem is that my bot does not have editmyprivateinfo
> enabled.
>
Now that I think about it, it looks like Special:BotPasswords requires
editmyprivateinfo be set by the user before a bot password is created.
If a bot had this permission, then it could set its own password, which
might be bad. This suggests that perhaps the ReadingList functionality
should use a different permission?
>
> Below are the details.
>
> This is a bit of a newbie question as I'm just starting out with the
> api. Please forgive me if this is not the right place to start this
> discussion. I considered adding something to Phabricator, but this
> issue is more of a user problem then a problem with the software.
>
> Anyway...
>
> I have a test program where I get a login token, login, get a csrf
> token and then call setup.
>
> #!/opt/local/bin/python3
>
> """
> setup.py
>
> Invoke the readinglists setup command
>
> MIT License
>
> """
>
> import requests
>
> URL = "https://en.wikipedia.org/w/api.php"
> #URL = "https://www.mediawiki.org/w/api.php"
>
> S = requests.Session()
>
> # Retrieve login token first
> PARAMS_LOGIN_TOKEN = {
> 'action':"query",
> 'meta':"tokens",
> 'type':"login",
> 'format':"json"
> }
>
> R = S.get(url=URL, params=PARAMS_LOGIN_TOKEN)
> DATA = R.json()
>
> LOGIN_TOKEN = DATA['query']['tokens']['logintoken']
>
> print("Got logintoken")
>
> # Send a post request to login. Using the main account for login is not
> # supported. Obtain credentials via Special:BotPasswords
> # (https://www.mediawiki.org/wiki/Special:BotPasswords) for lgname &
> lgpassword
>
> PARAMS_LOGIN = {
> 'action':"login",
> 'lgname': BOT_NAME_HERE,
> 'lgpassword': BOT_PASSWORD_HERE,
> 'lgtoken':LOGIN_TOKEN,
> 'format':"json"
> }
>
> R = S.post(URL, data=PARAMS_LOGIN)
> DATA = R.json()
>
> print("After login")
> print(DATA)
>
> # GET the CSRF Token
> PARAMS_CSRF = {
> "action": "query",
> "meta": "tokens",
> "format": "json"
> }
>
> R = S.get(url=URL, params=PARAMS_CSRF)
> DATA = R.json()
>
> CSRF_TOKEN = DATA['query']['tokens']['csrftoken']
>
> # Call setup
> PARAMS_SETUP = {
> "action": "readinglists",
> "command": "setup",
> "format": "json",
> "token": CSRF_TOKEN
> }
>
> print("About to setup")
> R = S.post(URL, data=PARAMS_SETUP)
> print("After attempting to call setup")
> print(R)
> print(R.text)
>
>
>
> The message I get is:
>
> |bash-3.2$ ./setup.py
> Got logintoken
> After login
> {'login': {'result': 'Success', 'lguserid': 208882, 'lgusername':
> 'Cxbrx'}}
> About to setup
> After attempting to call setup
> <Response [200]>
> {"error":{"code":"permissiondenied","info":"You don't have permission
> to edit your private information.","*":"See
> https://en.wikipedia.org/w/api.php for API usage. Subscribe to the
> mediawiki-api-announce mailing list at
> <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce>
> for notice of API deprecations and breaking
> changes."},"servedby":"mw1316"}
> bash-3.2$ |
>
> In a separate script, I'm able to retrieve my readinglists, so I know
> that logging in is working.
>
> I think the problem is that my bot does not have editmyprivateinfo
> enabled.
>
> Looking at the code, I can see ApiReadingLists.php at
> https://github.com/wikimedia/mediawiki-extensions-ReadingLists/blob/869ffc5…
> checks for editmyprivateinfo
>
> Does anyone know if editmyprivateinfo is the problem? If so, is it
> possible to enable it for a bot?
>
_Christopher