The behavior of prop=imageinfo with redirects, particularly redirects
in foreign repos such as Commons, has always been a bit strange and
confusing. Depending on the source of the file, sometimes &redirects=1
is needed in the query to get the imageinfo for a redirect and
sometimes this is done regardless.
Recent changes to the file repository backend code will cause
prop=imageinfo to now always return the info for the target file, even
when querying a redirect without specifying "&redirects=1" in the
query. A new iiprop is also available, iiprop=canonicaltitle, to
indicate the title associated with the file info itself.
These changes will be deployed to WMF sites with 1.23wmf7, see
https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the
schedule.
A change is also being planned by Brian Wolff to change prop=imageinfo
back in the other direction: file redirects would never be followed
unless &redirects=1 is included. Feedback is welcome, particularly on
edge cases that will need to be handled.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Fowarding on behalf of Benny and legoktm.
This change in the Echo API was announced on wikitech-l earlier, but
failed to make it to the API list.
"it will be removed once ..." from the message below has now happened:
https://gerrit.wikimedia.org/r/#/c/84870/ will be merged today, and
will be deployed to Wikimedia wikis in phases between December 12th
and December 19th.
---------- Forwarded message ----------
From: Benny Situ <bsitu(a)wikimedia.org>
Date: Mon, Nov 18, 2013 at 6:19 PM
Subject: [Wikitech-l] Update to Echo api
To: mobile-tech <mobile-tech(a)wikimedia.org>, Wikimedia developers
<wikitech-l(a)lists.wikimedia.org>, mediawiki-api(a)lists.wikimedia.org,
Kunal Mehta <legoktm(a)wikimedia.org>
Hello,
We made some change to Echo api recently. The api ApiEchoNotifications
mixed both read and write actions, we have migrated the 'markasread' action
to its own api module - ApiEchoMarkRead. The 'markasread' function still
works in ApiEchoNotifications but it will be removed once all external api
calls have been migrated to the new API.
Example about how to use the new API is in here:
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FEcho.git/40ea204cdc…
Thanks,
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
---------- Forwarded message ----------
From: Max Semenik <maxsem.wiki(a)gmail.com>
Date: Wed, Oct 23, 2013 at 1:56 PM
Subject: [Wikitech-l] Changes in API action=parse&mobileformat=...
To: MediaWiki API announcements & discussion
<mediawiki-api(a)lists.wikimedia.org>, Wikimedia developers
<wikitech-l(a)lists.wikimedia.org>
Hi, in response to bug 54607 [1], we've changed the semantics of the
mobileformat parameter to action=parse
== Summary ==
Previously, it used to accept strings 'html' or 'wml', later just
'html' and modify the structure of output (see below). This was problematic
because you needed to retrieve the HTML from output in different ways,
depending on whether mobileformat is specified or not. Now,
mobileformat is a boolean parameter, that is if there's a 'mobileformat'
parameter in request, it will be treated as "the output should be
mobile-friendly", regardless of value. And the output structure will
be the same. For compatibility with older callers,
mobileformat=(html|wml) will be special-cased to return the older
structure at least for 6 month from now. These changes will start
being rolled out to the WMF sites starting from tomorrow, Tuesday
October 24th and this process will be complete by October 31st.
== Examples ==
=== Non-mobile parse ===
api.php?action=parse&format=xml
{
"parse": {
"title": "...",
"text": {
"*": "foo"
}
}
}
api.php?action=parse&format=json
<?xml version="1.0"?>
<api>
<parse title="..." displaytitle="...">
<text xml:space="preserve">foo</text>
</parse>
</api>
=== Parse that outputs mobile HTML, old style ===
api.php?action=parse&format=json&mobileformat=html
{
"parse": {
"title": "API",
"text": "foo"
}
}
api.php?action=parse&format=xml&mobileformat=html
<?xml version="1.0"?>
<api>
<parse title="..." text="foo" displaytitle="...">
</parse>
</api>
=== Parse that outputs mobile HTML, new style ===
api.php?action=parse&format=...&mobileformat
Same as for non-mobile parses.
== FAQ ==
Q: I didn't use mobileformat before, does anything change for me?
A: No.
Q: I use mobileformat=html, will my bot/tool be broken now?
A: No, you will have 6 months to switch to new style.
Q: I'm only planning to use mobileformat, what should I do?
A: Just use the new style.
Q: How did this format discrepancy appear in the first place?
A: To err is human.
-----
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=54607
--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
---------- Forwarded message ----------
Date: Tue, 10 Sep 2013 12:11:56 +0200
From: Daniel Kinzler <daniel.kinzler(a)wikimedia.de>
Hi all.
With today's deployment, the Wikibase API modules used on wikidata.org
will change from using lower-case IDs (q12345) to upper-case IDs
(Q12345). This is done for consistency with the way IDs are shown in
the UI and used in URLs.
The API will continue to accept entity IDs in lower-case as well as
upper-case. Any bot or other client that has no property or item IDs
hardcoded or configured in lower case should be fine.
If however your code looks for some specific item or property in the
output returned from the API, and it's using a lower-case ID to do so,
it may now fail to match the respective ID.
There is potential for similar problems with Lua code, depending on
how the data structure is processed by Lua. We are working to minimize
the impact there.
Sorry for the short notice.
Please test your code against test.wikidata.org and let us know if you
find any issues.
Thanks,
Daniel
PS: issue report on bugzilla:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53894
Due to a security issue,[1] the deprecated "gettoken" parameter to
action=block and action=unblock has been removed. Clients should use
action=tokens to fetch tokens of types "block" or "unblock" instead.
This also applies to the security release 1.21.2.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=49090
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
If your bot checks meta=userinfo&uiprop=hasmsg to determine if a talk
page message has been posted in order to stop running, it is currently
broken since Echo disables that along with the orange bar.
This issue is being tracked at
https://bugzilla.wikimedia.org/show_bug.cgi?id=47962
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
Language links added by Wikidata are currently stored in the parser
cache and in the langlinks table in the database, which means they
work the same as in-page langlinks but also that the page must be
reparsed if these wikidata langlinks change. The Wikidata team has
proposed to remove the necessity for the page reparse, at the cost of
changing the behavior of the API with regard to langlinks.
Gerrit change 59997[1] (still in review) will make the following
behavioral changes:
* action=parse will return only the in-page langlinks by default.
Inclusion of Wikidata langlinks may be requested using a new
parameter.
* list=allpages with apfilterlanglinks will only consider in-page langlinks.
* list=langbacklinks will only consider in-page langlinks.
* prop=langlinks will only list in-page langlinks.
Gerrit change 60034[2] (still in review) will make the following
behavioral changes:
* prop=langlinks will have a new parameter to request inclusion of the
Wikidata langlinks in the result.
A future change, not coded yet, will allow for Wikidata to flag its
langlinks in various ways. For example, it could indicate which of the
other-language articles are Featured Articles.
At this time, it seems likely that the first change will make it into
1.22wmf3.[3] The timing of the second and third changes are less
certain.
[1]: https://gerrit.wikimedia.org/r/#/c/59997
[2]: https://gerrit.wikimedia.org/r/#/c/60034
[3]: https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
It was recently noticed[1] that the xmldoublequote parameter to
format=xml has been broken since r55641,[2] merged in August 2009 and
released with MediaWiki 1.16. Since it has been broken for over 3.5
years, it was decided to just remove the parameter.[3]
Background: The xmldoublequote parameter was added in response to bug
11401,[4] as a workaround for the fact that XPath 1.0 did not specify
any mechanism for escaping quotes in string literals. It caused all
attribute values and text content to be double-encoded, e.g. a double
quote would be represented as &quot;, and an ampersand would be
represented as &amp;.
Workaround: XPath 2.0, released in 2007, does include a quoting
mechanism. Clients using XPath 1.0 may use string concatenation as a
workaround.[5]
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=46626
[2]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/55641
[3]: https://gerrit.wikimedia.org/r/#/c/58261/
[4]: https://bugzilla.wikimedia.org/show_bug.cgi?id=11401
[5]: e.g. http://stackoverflow.com/questions/6937525/escaping-xpath-literal-with-pyth…
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
Remember that clients should not be depending on the specific query string
data returned inside the query-continue node, with either the old-style or
new style continuation.
As a partial fix for bug 24782[1], Gerrit change 22742 will cause
action=query&list=recentchanges to start returning rccontinue for
continuations rather than rcstart as it has done in the past. Changes of
this type may be coming to other modules as well as further fixes to bug
24782 are implemented.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=24782
[2]: https://gerrit.wikimedia.org/r/#/c/22742/
--
Brad Jorsch
Software Engineer
Wikimedia Foundation