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
When list=allusers is used with auactiveusers, a property 'recenteditcount'
is returned in the result. In bug 67301[1] it was pointed out that this
property is including various other logged actions, and so should really be
named something like "recentactions".
Gerrit change 130093,[2] merged today, adds the "recentactions" result
property. "recenteditcount" is also returned for backwards compatability,
but will be removed at some point during the MediaWiki 1.25 development
cycle.
Any clients using this property should be updated to use the new property
name. The new property will be available on WMF wikis with 1.24wmf12, see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=67301
[2]: https://gerrit.wikimedia.org/r/#/c/130093/
--
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
To operate correctly, action=purge needs to write to the database, which
means it should be done using a POST rather than a GET request.
As of Gerrit change 310560,[1] action=purge will begin emitting a warning
when used via GET. This should be deployed to WMF wikis with 1.28.0-wmf.20,
see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
Clients that use action=paraminfo to determine whether to use GET or POST
for an action should automatically switch to POST; any others should
manually switch to using POST for this action as soon as possible.
To check if your client's user agent is detected making such submissions,
you can also use ApiFeatureUsage[2] and look for 'purge-via-GET' once
1.28.0-wmf.20 is rolled out to wikis your client is using.
It is planned that this warning will be changed to an error 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/310560/
[2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
[3]: https://phabricator.wikimedia.org/T142155
--
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
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
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
Dear all,
We are using MediaWiki Version: 1.26.3 so the WikiEditor should be
preinstalled. But since it didn't even show up on the "special pages" -
"version" under the section "installed extensions", I searched the internet
and thought I will just install the extension myself.
I followed the instructions on the extension: WikiEditor page:
<https://www.mediawiki.org/wiki/Extension:WikiEditor>
https://www.mediawiki.org/wiki/Extension:WikiEditor
but the WikiEditor still doesn't show up under "installed extensions".
The LocalSettings.php had the line wfLoadExtension( 'WikiEditor' ); already
included from the beginning.
I tried changing it, using the configuration suggestions of the WikiEditor
page, and I also tried a suggestion of the Extension_Talk, where someone
used the old method: require_once
"$IP/extensions/WikiEditor/WikiEditor.php"; but it didn't work with this
line either.
I tried clearing browser cache, too, didn't make a difference. Now I am out
of guesses how we could make the extension work.
Who can help me
Karima & Doro
--
Dipl. Ing.in Dorothea Erharter
Geschäftsführerin
ZIMD Zentrum für Interaktion, Medien & soziale Diversität
+43 (0) 699-1136 9902
Währingerstraße 81/12
1180 Wien
Hi,
I haven't followed the latest modifications on action login, but users of
WPCleaner have been complaining for a few days that they couldn't do any
modifications through WPCleaner, getting an error message saying that they
must be logged in to update pages.
I was away for few days, so I didn't have a chance to look at that before
now. After a quick investigation, I found that action login doesn't return
a lgtoken in its answer, just a lguserid and a lgusername.
Is it normal that lgtoken is not returned anymore ? What's the correct way
to login through the API that won't break again in the next months ?
Thanks for any help
Nico
Hello!
The Wikimedia Developer Summit
<https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit> is the annual
meeting to push the evolution of MediaWiki and other technologies
supporting the Wikimedia movement. The next edition will be held in San
Francisco on January 9-11, 2017.
We welcome all Wikimedia technical contributors, third party developers,
and users of MediaWiki and the Wikimedia APIs. We specifically want to
increase the participation of volunteer developers and other contributors
dealing with extensions, apps, tools, bots, gadgets, and templates.
Important deadlines:
- Monday, October 24: This is the last day to request travel
sponsorship. Applying takes less than five minutes.
- Monday, October 31: This is the last day to propose an activity. Bring
the topics you care about!
More information:
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit*https://www.media…
<https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit>*
Subscribe to weekly updates: https://www.mediawiki.org/
wiki/Topic:Td5wfd70vptn8eu4
Please feel free to forward this email to anyone who might be interested in
attending!
Thanks,
Srishti
--
Srishti Sethi
ssethi(a)wikimedia.org
Dear Wikipedia and MediaWiki people,
Hers are some suggested ideas that may allow Wikipedia and MediaWiki to be
organized better in the future and for the future of organizing the worlds
open public information.
*Summaries - popup summaries for pages*
Using automated generation of content for the title attribute on the <a>
tag containing a summary containing either the content from an
<article><header><section id="summary"> or a designated section from
Wikimedia markdown a popup summary could be generated for quick browsing
for definition of terms on hyperlinks. This would vastly aid the user
experience.
*Categories - bread crumb like hierarchical and cross referencing
categorization and navigation*
By creating a set of categorical navigation pages the whole of fields of
knowledge on Wikipedia could be categorized.
By having a set of clickable list of hierarchical categories displayed like
'bread crumb' navigation lists under the page title the user could quickly
navigate this hierarchy.
By adding pop up menus to the separating chevrons with each subcategories
elements cross category navigation would be made possible.
Double clicking on chevrons should navigate to the categorical navigation
page.
*QuickLink - Quick Link Creation*
A hotkey and JavaScript script could allow the creation of links from a
selected highlighted bit of normal text to lookup a term, display its
summary and allow the user to confirm the generation of a new hyperlink
very quickly without having to edit markdown.
*Move towards semantic content*
By using new HTML elements like <article>, <section> and <header> and id's
and classes more of a semantic mapping of content may be established. Tis
maybe done incrementally and also for example by a bot auto generating new
summary information that maybe verified by either users or editors for
publishing.
*API*
API's from summaries, categories, and semantic content should be made
available.
More to come ...
Regards,
Aaron Gray
*Wikimedia Documents - PDF Scraping and creating living working documents*
Wikimedia should have a way of creating documents that can easily be
imported and exported to PDF, Word and other formats.
- Document versioning as well as history should be able to be provided.
- Authorship and control of authorship I also needed.
- Fixed and editable status should also be provided
- Document licensing should also be feature, this should allow management
of information from different sources.
Document licensing should allow copying and collation to be done in
controlled way allowing information dissemination.
By scraping the content of PDF documents that are put into the public
domain or under open license that permits modification and that permission
is given to subsume and render them into MediaWiki Pages in modifiable
state. Those that are in the public domain or under a fixed content license
may still be rendered into MediaWiki Pages.
Quick access to the original document and modification history should be
mandatory at the top of every original document page. Auto quotations and
citations can also be generated at the bottom of the pages
More to come ...
Regards,
Aaron Gray
On 9 October 2016 at 13:37, Aaron Gray <aaronngray.lists(a)gmail.com> wrote:
> Dear Wikipedia and MediaWiki people,
>
> Hers are some suggested ideas that may allow Wikipedia and MediaWiki to be
> organized better in the future and for the future of organizing the worlds
> open public information.
>
> *Summaries - popup summaries for pages*
>
> Using automated generation of content for the title attribute on the <a>
> tag containing a summary containing either the content from an
> <article><header><section id="summary"> or a designated section from
> Wikimedia markdown a popup summary could be generated for quick browsing
> for definition of terms on hyperlinks. This would vastly aid the user
> experience.
>
>
> *Categories - bread crumb like hierarchical and cross referencing
> categorization and navigation*
> By creating a set of categorical navigation pages the whole of fields of
> knowledge on Wikipedia could be categorized.
>
> By having a set of clickable list of hierarchical categories displayed
> like 'bread crumb' navigation lists under the page title the user could
> quickly navigate this hierarchy.
>
> By adding pop up menus to the separating chevrons with each subcategories
> elements cross category navigation would be made possible.
>
> Double clicking on chevrons should navigate to the categorical navigation
> page.
>
> *QuickLink - Quick Link Creation*
>
> A hotkey and JavaScript script could allow the creation of links from a
> selected highlighted bit of normal text to lookup a term, display its
> summary and allow the user to confirm the generation of a new hyperlink
> very quickly without having to edit markdown.
>
> *Move towards semantic content*
>
> By using new HTML elements like <article>, <section> and <header> and id's
> and classes more of a semantic mapping of content may be established. Tis
> maybe done incrementally and also for example by a bot auto generating new
> summary information that maybe verified by either users or editors for
> publishing.
>
> *API*
>
> API's from summaries, categories, and semantic content should be made
> available.
>
> More to come ...
>
> Regards,
>
> Aaron Gray
>
>