Great find! Since we're mentioning similar features, the Google Dictionary Chromium / Chrome extension (by Google) performs a similar function.

Inline image 1

--stephen

On Mon, Jun 8, 2015 at 2:04 AM, S Page <spage@wikimedia.org> wrote:
On Thu, Jun 4, 2015 at 10:45 PM, Dmitry Brant <dbrant@wikimedia.org> wrote:
 (I wonder what API they're using?)
api.log logs all API requests, but doesn't include referer. Cross-referencing warnings in api-feature-usage (below) suggests at least some requests like

action=query format=json titles=dotage redirects= prop=revisions rvprop=content rvlimit=1 rvsection=0
followed by
action=parse format=json title=Dotage text=%7B%7Bwiktionary%20redirect%7D%7D%7B%7BShort%20pages%20monitor%7D%7D
(the "Dotage" article returns a rather unhelpful {{wiktionary redirect}}{{Short pages monitor}}).

So Kindle sometimes retrieves the wikitext of the zero section of the article, then requests a parse of it.  Using TextExtracts would be so much better, prop=extracts&exintro= would give similar info in a single API call.

On Fri, Jun 5, 2015 at 7:39 AM, Bernd Sitzmann <bernd@wikimedia.org> wrote:
Nice find. I also like being able to swipe those cards left/right between different information sources. Looks like depending on the selected words it's: Dictionary, Wikipedia, Translation

That is awesome. Link preview and Hovercards should do the same, we do little to surface content in the non-pedia wikis beyond {{Sister project links}} at the bottom of some articles. (Hovercards would have a row of icons as well as the swipe gesture).
Which raises the question where should I phile a Reading proposal like that, rather than for each app's implementation of link preview and hovercards?

[Apple's OS-level integration]]
Link preview and Hovercards work on a link. But wikis intentionally only link the first use of a term and don't link every term per MOS: overlinking, which means I often scroll backwards searching for the first mention of a term. It would be nice if there were an affordance to be able to lookup any text, even if not explicitly linked.

Maybe WMF should offer its own browser- or OS-level integration, pushing the reading experience way beyond our sites.
https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists various browser addons, such as Lookup companion for Wiki that do this. Meanwhile https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has "Download 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on any word in any program on your screen for instant, accurate facts." Who knew?!, makes me want to bust out Windows 2000 :)

On Fri, Jun 5, 2015 at 10:59 AM, Joaquin Oltra Hernandez <jhernandez@wikimedia.org> wrote:
I wonder what will happen if one of our breaking api changes [breaks] one of these queries... They are probably running a proxy cached service to avoid any of those problems.

Good point. I'll forward to Kourosh, who deals with partnerships like this, and we can only hope people writing all these tools are on some mailing list.

fluorine:/a/mw-logs/api-feature-usage.log has a number of
   2015-06-07 06:26:39 mw1232 enwiki api-feature-usage INFO: "action=query&!rawcontinue&!continue" from user agents containing "Kindle". ApiQuery.php logs this along with the warning in the API result "Formatting of continuation data will be changing soon. ..."
So I hope someone notices the warnings in API responses.

--
=S Page  WMF Tech writer

_______________________________________________
reading-wmf mailing list
reading-wmf@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/reading-wmf