Dictionary Integration in Thorium Reader:

[preeningrockdove]

Hi, I'd like this awesome reader to have dictionary lookup functionality which would help everybody immensely.
This is an essential feature in every single reader app. Without a built in dictionary, the reader is forced to copy-paste or write down the words in a separate browser window to lookup their definition.
The most convenient implementation would be "double click to lookup". Amazon Kindle Reader does it brilliantly. The Foliate Reader for Linux : https://github.com/johnfactotum/foliate is another great example.

There are great free dictionaries that are completely free to use and distribute; Wordnet for example. And we can always have Wikipedia and Wikionary look up built in too (Again, the foliate reader does it great). These online lookups aside, the users can be given the option to download offline dictionaries so that people with slow internet can get instant definitions without having to wait a few seconds for every double click. Wordnet aside, I found FreeDict https://freedict.org/ which also offers offline dictionary.

So, the features I request are:

1. Instant online look up for words on double click, preferably in a popup, with options to choose between Wikipedia, WIkionary and Wordnet.
2. When selecting a phrase consisting of multiple words, offering an tiny popup to look up the definition.
3. Option to download offline dictionaries, like Wordnet and FreeDict.
4. A toggle to choose between online lookup and offline lookup.

[danielweck]

I made some related comments here:
#169 (comment)

I have been looking into technical solutions to display user interface controls precisely over the publication document's text / content (including images), from outside the webview in order to avoid interfering with the rendering/layout engine which paginates documents and injects features to resolve character selection / highlights, compute character-level locations, handles keyboard focus, etc.
The webview is a strong isolated security sandbox, and its contents are potentially scaled independently, thereby making it challenging to overlay precisely from the host / top-level container (i.e. the application "chrome" / user interface)

Alternatively, a blocklist system could be used to identify HTML/CSS inside publication documents which are not meant to take part in document markup as such (we already use this approach for the popup footnotes UI, for example)

[danielweck]

bug triage: moving to a discussion until actionable issue (bug fix or new feature) is established.