Hi, in response to bug 54607 , 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 ===
<parse title="..." displaytitle="...">
=== Parse that outputs mobile HTML, old style ===
<parse title="..." text="foo" displaytitle="...">
=== Parse that outputs mobile HTML, new style ===
Same as for non-mobile parses.
== FAQ ==
Q: I didn't use mobileformat before, does anything change for me?
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.
Max Semenik ([[User:MaxSem]])
It's strange for me why new pages hasn't been implemented in API yet.
We can retrieve recent changes and filter new pages (as we did in
pywikibot to retrieve new pages) but if we want new pages of English
Wikipedia in a certain day (or certain number) we need to retrieve ALL
of edits made during that period of time, which is bad for global
warming. Is there any reason not to implement new pages API
functionality. If it's okay, I'll start working on it
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
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)
Mediawiki-api-announce mailing list
I am quite new using
MediaWiki API. I want to get the revisions filtering out the revisions
made by all the 'anonymous users' and 'minor edit' for an article. The
parameter 'rvexcludeuser' is for filtering single user only.
Do you have any clue.
I am working on an application which requires the total wikipedia page counts that contain specific word or a pair of words. I have tried to to use advanced search to get these page counts and retrieve the the HTML page to extract that. Please see the attached snapshot is information pointed by the red arrow the actual total pages containing the name David Beckham ?. Any advice is highly appreciated.
Muhidin A. Mohamed,
School of Electrical, Electronic and Computer Engineering,
University of Birmingham,
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
Kunal Mehta <legoktm(a)wikimedia.org>
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:
Wikitech-l mailing list
Mediawiki-api-announce mailing list
per https://bugzilla.wikimedia.org/show_bug.cgi?id=57128 I have
submitted a patch that changes the api module prefix of
ApiQueryAllCampaigns from 'uc' to 'uwc', as 'uc' is already used by user
contributions. Please note that this change is a breaking API change and
it does not implement backwards compability.