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 2008

mediawiki-api@lists.wikimedia.org
  • 12 participants
  • 12 discussions
Start a nNew thread
new bug in category members query?
by Minh Lê Ngọc 28 Feb '08

28 Feb '08
I'm having trouble with querying English pronunciation from commons by mybots. Take a look at queries below: - title=<http://commons.wikimedia.org/w/api.php?action=query&list=categorymembers&cm…>Category:English pronunciation<http://commons.wikimedia.org/w/api.php?action=query&list=categorymembers&cm…> - title=Category:English pronunciation&cmcontinue=usedto.ogg|<http://commons.wikimedia.org/w/api.php?action=query&list=categorymembers&cm…>There are 4 items appear twice in these 2 queries: wherewithal, wires, wire,wired and items are sorted in no order.What's up?
5 9
0 0
blredirect
by Roan Kattouw 25 Feb '08

25 Feb '08
As of r31260 [1], the blredirect, eiredirect and iuredirect parameters, for the backlinks, embeddedin and imageusage modules respectively, are now available. Setting these parameters will make the API list links through redirects as well, à la Special:Whatlinkshere. Since this is not really useful for embeddedin (redirects hardly ever embed pages) or for imageusage (image redirects haven't been implemented yet), I'll use blredirect in the example below.api.php?action=query&list=backlinks&bltitle=Foo&blredirect&bllimit=3 will generate the following output:<?xml version="1.0" encoding="utf-8"?><api> <query-continue> <backlinks blcontinue="0|Foo|44|72" /> </query-continue> <query> <backlinks> <bl pageid="36" ns="0" title="Test" /> <bl pageid="44" ns="0" title="Redir" redirect=""> <redirlinks> <bl pageid="34" ns="0" title="Bar" /> <bl pageid="45" ns="0" title="Blah" /> <bl pageid="54" ns="0" title="Main Page" /> </redirlinks> </bl> <bl pageid="57" ns="0" title="New page" /> </backlinks> </query></api>This means [[Test]] and [[New page]] link to [[Foo]], while [[Bar]], [[Blah]] and [[Main Page]] link to [[Redir]], which in turn redirects to [[Foo]]. Note that bllimit=3 applies both to the first level (three pages linking to [[Foo]] are listed) and the second level (three pages linking to redirects to [[Foo]] are listed) separately. Because of this, bllimit is capped at 250 (2500 for bots and sysops) if blredirect is set.We continue the request with:api.php?action=query&list=backlinks&blcontinue=0|Foo|44|72&blredirect&bllimit=3<?xml version="1.0" encoding="utf-8"?><api> <query> <backlinks> <bl pageid="44" ns="0" title="Redir" redirect=""> <redirlinks> <bl pageid="72" ns="0" title="Dummy1" /> </redirlinks> </bl> <bl pageid="57" ns="0" title="New page" /> <bl pageid="71" ns="0" title="Redir2" redirect=""> <redirlinks> <bl pageid="72" ns="0" title="Dummy1" /> </redirlinks> </bl> </backlinks> </query></api>Because the list of links to [[Redir]] wasn't finished yet, the continued request starts there, and lists [[New page]] again.Of course, list=backlinks behaves exactly the way it used to when blredirect is not set, so this is not a breaking change.Roan Kattouw (Catrope)[1]http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31260
2 1
0 0
BREAKING CHANGE in limit=max handling
by Roan Kattouw 25 Feb '08

25 Feb '08
In r31258 [1], the output for limit=max was changed. The previous implementation returned<limits limit="500" />when limit=max was used. However, a request like api.php?action=query&list=logevents&prop=revisions&lelimit=max&rvlimit=max&rvprop=content&titles=Foo caused the following problems:* The code would try to overwrite the already set <limits> tag, causing a fatal error* prop=revisions&rvprop=content enforces a stricter limit (200) than list=logevents (500)These issues have been resolved by changing the output format to:<limits logevents="500" revisions="200" />This change is expected to be included in the upcoming 1.12 release (unless Brion throws it out).Roan Kattouw (Catrope)[1]http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31258
1 0
0 0

24 Feb '08
I don't think it can be done. The RSS of the wiki is for general changes only (Special:Recentchanges). You could query the category via the api, as inhttp://en.wikipedia.org/w/api.php?action=query&list=categorymembers&generat… but a) The output format is not the one of RSS and b) the sorting won't be the most appropiate.However, i think it's a quite interesting option, so i'm CCing to the mediawiki-api list for input about that.Another option is to create an account and use the rss of your watchlist. This gives you the maximum liberty about which articles to include/exclude.Once you have one of such feeds, you can see them with your preferred news aggregator, include on a web using a custom system, a plugin... Specifically, mediawiki has several extensions able to include content from external RSS feeds:http://www.mediawiki.org/wiki/Category:RSS_ExtensionsCary Bass wrote:> Hey, can someone take this one on? Thanks.> -> > Cary Bass> Volunteer Coordinator> Your continued donations keep Wikipedia running! Support the Wikimedia> Foundation today:http://donate.wikimedia.org > > Wikimedia Foundation, Inc.> Phone: 727.231.0101> Fax: 727.258.0207> E-Mail: cbass(a)wikimedia.org> > > -----Original Message-----> From: Sue Gardner [mailto:sgardner@wikimedia.org] > Sent: Friday, February 22, 2008 5:14 PM> To: Cary Bass> Subject: Partnerships FAQ: question about subscribing to content> > Is there a way for me to subscribe to particular kinds of content out of> Wikipedia (e.g., articles about folk music, or articles about Canada), so> that my encyclopedia benefits automatically from the ongoing contributions> of Wikipedia contributors?> > Cary, could you try to find someone to answer this question on the> partnerships FAQ? (I am assuming the answer is no, but I'm not sure.) No> rush, anytime :-)> > Thanks,> Sue
2 1
0 0
user_id from revision
by Ian Pye 20 Feb '08

20 Feb '08
Is it possible to retrieve the user_id of the user who made a givenrevision? I see that there is a ids element to rvprop, and a userelement, but neither of these give me the user_id. Alternatively, isthere a way I'm not seeing to map a user name to user_id?Thanks for your help,Ian
3 4
0 0
Gzip Compression
by Ian Pye 14 Feb '08

14 Feb '08
Hi,I apologize if this has been mentioned earlier and I missed it, but:I infer that GZip compression is available when making api calls, butI can't find any documentation on it. Can someone point me in theright direction to get started?Thanks,Ian
2 1
0 0
APIEdit and hooks
by Bryan Tong Minh 13 Feb '08

13 Feb '08
Hello,I was looking at hooks, in particular ArticleDeleteComplete, andnoticed that they are called from a function that is quite in thefront end 'doDelete'. When an article is deleted via the API, it callsthe backend function 'doDeleteArticle'. This means that the hooksrelated to article deletion are never called. Is this intended?Bryan
2 3
0 0
BREAKING CHANGE to list=categorymembers
by Roan Kattouw 07 Feb '08

07 Feb '08
Great, sent this e-mail to the wrong address and didn't notice until three days later...In r30533 [1], the following changes were made to list=categorymembers:* The cmtitle parameter was added, which is intended to replace cmcategory in the long run. The difference is that cmtitle requires the Category: prefix, whereas cmcategory does not. (Example: cmtitle=Category:Living_people and cmcategory=Living_people)* The cmcategory parameter is now deprecated, and WILL BE REMOVED in early March (probably around March 3rd)* A few error messages have been changed:** <error code="cmparam_category" info="Category parameter is required"> was changed to <error code="cmnotitle" info="Either the cmcategory or the cmtitle parameter is required">*** The message will be changed to "The cmtitle parameter is required" in early March (when cmcategory has been removed). The error code (cmnotitle) won't change.** <error code="cmparam_category" info="Category name $1 is not valid"> was changed to <error code="cminvalidcategory" info="The category name you entered is invalid">*** This error will also be thrown if cmtitle is a valid title but not in the Category: namespace.** <error code="cmtitleandcategory" info="The cmcategory and cmtitle parameters can't be used together">*** This error will be removed once cmcategory has been removed (in early March), because it won't make sense anymore at that timeFor extra clarity: this doesn't break any code *yet*. Users of list=categorymembers have until *early March* to update their code, after that code using the cmcategory will break.Roan Kattouw (Catrope)[1]http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=30533
1 0
0 0
Agree, backwards compatibility is important, but it has to be balancedwith efforts required to maintain query.php.. Every db schema changemust be looked at to see if query.php must be updated. Internal apichanges may also impact its functions and performance. IIRC, there arealready some queries not working as intended.At the very least, we can analyze web logs to see which query.phpfunctions are being used, and disable the rest. There was loggingfunctionality built into query.php, and the server should have analternative log that could be grep-ed. Can a server admin look atthat?Thx!On 2/2/08, Tim Starling <tstarling(a)wikimedia.org> wrote:> Yuri Astrakhan wrote:> > For those who use old query.php API interface:> >> > Perhttp://bugzilla.wikimedia.org/show_bug.cgi?id=12881 , query.php has> > been fully ported to the api.php, and thus no longer needed. Unless> > there are significant reasons to keep it around, it will be removed both> > from the extensions and from the mediawiki sites fairly soon.> >>> Isn't backwards compatibility enough of a reason? Surely it's a lot easier> to keep it around than to rewrite everything that uses it.>> -- Tim Starling>>> _______________________________________________> MediaWiki-l mailing list> MediaWiki-l(a)lists.wikimedia.org>http://lists.wikimedia.org/mailman/listinfo/mediawiki-l>
2 1
0 0
This change will break backwards compatibility, so I'm forwarding itto this mailing list.Bryan---------- Forwarded message ----------From: bugzilla-daemon(a)mail.wikimedia.org <bugzilla-daemon(a)mail.wikimedia.org> Date: Feb 3, 2008 9:47 PMSubject: [Bug 12898] imageusage and categorymembers lack consistencyTo: wikibugs-l(a)lists.wikimedia.orghttp://bugzilla.wikimedia.org/show_bug.cgi?id=12898Roan Kattouw <roan.kattouw(a)home.nl> changed: What |Removed |Added---------------------------------------------------------------------------- CC| |roan.kattouw(a)home.nl Status|NEW |ASSIGNED Summary|imageusage and |imageusage and |categorymembers lacks |categorymembers lack |consistency |consistency--- Comment #1 from Roan Kattouw <roan.kattouw(a)home.nl> 2008-02-0320:47:51 UTC --- To clarify what might seem unclear to some: list=imageusage currently takes itsiutitle parameter as Image:Example.jpg, while list=categorymembers takes itscmcategory parameter as Living_people (as opposed to Category:Living_people). The suggestion is that cmcategory be renamed to cmtitle and require theCategory: prefix.I'll implement this when I get around to it.--Configure bugmail:http://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: -------You are watching all bug changes._______________________________________________Wikibugs-l mailing listWikibugs-l(a)lists.wikimedia.orghttp://lists.wikimedia.org/mailman/listinfo/wikibugs-l
3 2
0 0
Results per page:
[8]ページ先頭
©2009-2026 Movatter.jp