Quote:
Originally Posted by davidfor
They must have changed that in one of the later beta's. I did some testing with them to get it working, but, didn't try removing the ExtraLocales line afterwards. For my examples, it is using the language codes to get the language names. It isn't getting this from inside the files, as I in at least one case, I just copied the supplied dictionaries to a different name.
|
To be specific about what I tested and looked at:
A dictionary will now appear and work correctly if you name it "dicthtml-X.zip" where X is alphanumeric/dashes. If it is a built-in locale, the localized language name will be used. If it is listed as a locale in ExtraLocales, it will be named "Extra: ..." (and the patch that replaced the space isn't necessary anymore to make it work). " (Custom)" will be appended to the locale if the dictionary is in the "custom-dict" folder. If it is not listed as a locale in ExtraLocales and if it isn't a built-in locale, the original zip filename will be used as-is.
For example:
- .kobo/dict-custom/dicthtml-en.zip -> "English (Custom)"
- .kobo/dict/dicthtml-xx.zip -> "dicthtml-xx.zip"
- .kobo/dict-custom/dicthtml-xx.zip -> "dicthtml-xx.zip"
- .kobo/dict-custom/dicthtml-xx-xx.zip -> "dicthtml-xx-xx.zip"
- .kobo/dict-custom/dicthtml-xx.zip + ExtraLocales=xx -> "Extra: xx (Custom)"
- .kobo/dict-custom/dicthtml-xx-xx.zip + ExtraLocales=xx -> "Extra: xx - Extra: xx (Custom)"
- .kobo/dict/dicthtml-xx.zip + ExtraLocales=xx -> "Extra: xx"
- .kobo/dict-custom/dicthtml-word1 word2.zip -> "dicthtml-word1 word2.zip" (but will fail to actually find entries)
In previous firmware versions, the dictionary had to be listed in ExtraLocales to actually appear in the menu, and the patch had to be applied if not using a built-in locale name to fix the bug with handling the space after "Extra:".
Note that the fix for the space bug only applies to the one after "Extra:" and before "(Custom)", which means you still can't include spaces in the custom dictionary name itself.
In short, this means dictutil can now just copy the dictionary file itself without touching the config file or database. I will add an option to force it to also add the dictionary to ExtraLocales, but it won't be the default anymore for 4.24.15672+.
See here for everything I know about the dictionary changes in this firmware version:
https://github.com/pgaskin/dictutil/...ment-698058632.
___
For dictutil's dictgen/kobodict, I'll add support for the new v3 format (which adds prefix_exceptions for redirecting words to different prefixes, and adds a new option for a custom dictionary-wide credit line), but it'll be disabled by default. Even though the new prefix_exceptions trie is cleaner and slightly more space-efficient than my current workaround of duplicating variants to all possible prefixes, I'm worried about bugs with the behaviour on complex dictionaries with variants and multi-word entries for the same word. In addition, prefix_exceptions doesn't give any real advantage over the workaround I use and unlike the workaround, it won't work on older firmware versions too.
Nevertheless, one unique (mis)use of the new prefix_exceptions trie I just came up with is for languages with too many prefixes for the zip (c.f. the complaints about Chinese dictionaries in the dictutil thread). I could use prefix_exceptions to map multiple words with different prefixes into a single file. I'll see what I can do with an implementation of this when I have more time.