Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make dictionaries folder location configurable #5995

Closed
wmlive opened this issue Mar 21, 2020 · 8 comments · Fixed by #5999
Closed

Make dictionaries folder location configurable #5995

wmlive opened this issue Mar 21, 2020 · 8 comments · Fixed by #5999

Comments

@wmlive
Copy link

wmlive commented Mar 21, 2020

  • KOReader version: 2020.02 (Android)
  • Device: Onyx Boox Note

Issue

Enhancement proposal:

koreader uses its own private location for dictionaries at koreader/data/dict as common storage for external stardict dictionaries. If users would be possible to reconfigure this storage location it would be able to share an already existing location between multiple reader applications. On the Onyx Boox devices there is typically an upper level folder named dicts used for storing stardict dictionaries for its internal applications. If users would be able to simply point koreader's dictionary location to that same location there would be no need anymore to maintain duplicate dictionary files on the device and save considerable storage capacity.

@pazos
Copy link
Member

pazos commented Mar 21, 2020

Not exactly what you asked for, but a workaround: You can invoke onyx dictionary app and use it in KO instead of internal implementation. For that you'll need to know the kind of intent that onyx uses to do lookups.

If you're interested you can do it:

  1. Install and enable https://f-droid.org/en/packages/de.k3b.android.intentintercept/
  2. Open stock application, do a dictionary search
  3. Create /sdcard/koreader/dictionaries.lua, using android: allow overrides on 3rd party dictionary list #5664 (comment) as a template.

Feel free to ask If you're stuck on step 3 or if intercept intent isn't triggered on step 2. 😄

@wmlive
Copy link
Author

wmlive commented Mar 22, 2020

Thanks for the quick feedback!

Installed and enabled android.intentintercept but see no kind of information feedback whatsoever. And i see no way to redirect this application to explictly perform an interception on anything other but bluetooth and itself.

I won't pursue this route any further as this workaround would not help to keep using koreader's internal dictionary app which IMHO is much more useful than the Onyx one. But thanks for the suggestion!

Configuring an alternate location where koreader's built in dictionary application could search for dictionay files would be much nicer, of course.

Thanks again! :)

@pazos
Copy link
Member

pazos commented Mar 22, 2020

@wmlive: then you need to use a patch yourself, mainly because android is a nasty platform.

Create a new document with

local android = require("android")
local ffi = require("ffi")
local path = android.getExternalStoragePath()
ffi.C.setenv("STARDICT_DATA_DIR", path .. "/dicts", 1)

and save it as /sdcard/koreader/patch.lua. Please use an editor with unix line endings, like Notepad++.

The patch will survive updates 👍

@wmlive
Copy link
Author

wmlive commented Mar 22, 2020

Agreed, Android definitely is a nasty platform. I only use editors with Unix line endings, constantly switching between Emacs and lovely vim. Wouldn't touch anything else for text editing. ;)

That patch indeed did it for me! Now koreader is using the same dictionary files location as the Onyx stock dict application. Thanks a lot!

It would be nice though if this could be added as an option to koreader for normal users.

@retrue
Copy link
Contributor

retrue commented Mar 22, 2020

Hi
I would like to ask to carry this feature to other devices too, not only to Android devices.
Explanation: I own a Kobo Mini, that has only 2 GB of storage, and I have installed in addition of the official Kobo software, KOReader and Vlasovsoft's PBChess.
CoolReader y KOReader use the same format for dictionaries. But if want to use the same dictionaries in both programs I have to install those dictionaries twice, losing a lot of useful storage.
The solution I proppose would be to add in the Dictionary menu configuration an option to add manually a second path for dictionaries, so I could use the dictionaries installed in PBChess or any other software.
Thanks.

@pazos
Copy link
Member

pazos commented Mar 22, 2020

@wmlive @retrue: resources are limited and most features are still undocumented. Adding whatever GUI option for something trivial won't make things easier because new people normally ask before checking the entire GUI options.

Also, documenting a GUI option is harder than telling people please modify the environmental variable "STARDICT_DATA_DIR". Please see https://github.com/koreader/koreader/search?q=STARDICT_DATA_DIR&unscoped_q=STARDICT_DATA_DIR.

I agree that having a way to override defaults that survives updates is desired. That actually happens on android with the patch.lua mentioned above, but won't happen on the rest of platforms, where koreader.sh will be updated over the air.

@Frenzie
Copy link
Member

Frenzie commented Mar 22, 2020

The same thing might work in defaults.persistent.lua? (Didn't test atm.)

@retrue
Copy link
Contributor

retrue commented Mar 22, 2020

Hmm, another solution that would work for me (and people who have PBChess installed too) would be to add in the code another paths for dictionaries, without adding any GUI configurable location.
That is, for KOBO readers add the paths: .kobo/vlasovsoft/dictionary and .adds/vlasovsoft/dictionary
And similar default paths for PBChess in other devices like Kindle.
Dunno if there are other software for Kobo, Kindle, Pocketbook in addition to PBChess that use stardict dictionaries. In that case, those default dictionary paths could be added too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants