Great find! Since we're mentioning similar features, the Google Dictionary
<https://chrome.google.com/webstore/detail/google-dictionary-by-goog/mgijmajocgfcbeboacabfgobmjgjcoja>
Chromium
/ Chrome extension (by Google) performs a similar function.
[image: Inline image 1]
--stephen
On Mon, Jun 8, 2015 at 2:04 AM, S Page <sp...@wikimedia.org> wrote:
> On Thu, Jun 4, 2015 at 10:45 PM, Dmitry Brant <dbr...@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 <be...@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
> <https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Linking#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
> <https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en>
> 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 <
> jhernan...@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-...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>
_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
