Preview dictionary on reader-dict.com

[lasconic]

Follow up https://github.com/orgs/reader-dict/discussions/2529#discussioncomment-14539233

I love the idea, and it would be great to have web version of the dictionaries.
@BoboTiG Would you consider hosting them ?

The way I would do it (and partly did...)

1. Add a formatter to export the dictionnary as a set of json files aa.json ab.json etc... with 3 or 4 letters if necessary to have small files. (da-da is about 3MB uncompressed). I wouldn't use templates but rather export the data as raw as possible
2. An HTML/CSS/JS page to search, load the the right json, and display definitions as close as possible from the Kobo rendering (plus rendering for other apps if different).

[BoboTiG]

What do you have in mind exactly? A previewer with like 10 words for each dictionary, or a full dictionary search webapp?

[lasconic]

A full dictionary search webapp because I wouldn't know how to choose 10 words.
But technically, 10 words or 45000, it's close (except for storage and bandwidth).

For 10 words, we could maybe only automate screenshots from a device.

[BoboTiG]

Actually, I've in mind to create a full app (https://github.com/reader-dict/app). But maybe this approach would be better for a start.

The current process is quite good for this new usecase: we can reuse the JSON created by --render, it contains full cleaned HTML code already.
Then, it will be a mater of tweaking the display to mimic the Kobo/Kindle/etc (I imagine this part as CSS themes, while keeping in mind that the goal is to show the dictionary content, not to be a copy of a device).

I guess bottlenecks might be the network bandwith & data retreival performances (Maybe moving the JSON data into a SQLite database would be interesting here). About disk space, it should be good since the biggest file is EN with 936 Mo.

[lasconic]

I'll upload a test app and you tell me what you think

[BoboTiG]

I think the variants handling for jsonvolume could be improved. For example, it does not support multiple variants level deep (as we do for other primary formatters).

Example with the DA dict: "aer" -> "ae" -> "a"
Selecting "aer" should display "a" content. It currently displays an empty "ae" word.

Maybe could we leverage the word formatting from Kobo/DictFile formatters?

In the webpage, it would be interesting to display the full redirection list like "aer → ae → a" (very optional though).

[lasconic]

Maybe could we leverage the word formatting from Kobo/DictFile formatters?

It all depends what the end goal is. The current implementation was done to be flexible on the client side. The goal was to be able to do the templating on the client side and reflect the difference between kobo and dictfile so that a user could see exactly how it will look on his device before downloading. But we can change the goal, and focus on content only or debugging. You tell me.

[BoboTiG]

Rewording my request: variants multiple levels deep is a feature for all formats. We should have it for the webapp too.

I do not ask to use the whole formatter process from others, as they are too specific as you said. But the jsonvolume variants handling part could be improved to support back this feature.

[BoboTiG]

I will see if I can have something working tomorrow or Friday (if you didn't step in before ;).

[lasconic]

we can have "aer → ae → a" solved on the client side. See #2568

[BoboTiG]

That works like a charm, well done!

[BoboTiG]

If you have the DA dict working locally, can you find the word Østjylland via the webapp? I see it in last volume, but it doesn't show up in search suggestions 🤔

[lasconic]

Good catch. In fact, it's the case for any upper case initial...