Firmware 4.24.15672

[Terisa de morgan]

Originally Posted by geek1011

To clarify one thing, the ExtraLocales isn't mandatory anymore. If you don't specify it, it will just use the zip filename as the dictionary name.

Also, if you do choose to use ExtraLocales, you won't need to use the patch anymore since the bug with language splitting for "Extra: " has been fixed.

Note that if you use the same locale as a built-in dictionary, it will not conflict since all custom ones matching a valid locale will have " (Custom)" appended to the name.

Also, the bug with custom dictionary sizes in the settings and with it saying it needs to sync has been fixed along with a bunch of other bugs related to dictionary lookup.

When you install this firmware version, it should automatically move your custom dictionaries.

I will add support for the new install method in dictutil later this week.

See the dictutil issue on GitHub I linked near the top of this thread for more details about this.

An internal detail which might be interesting is that there's a new dicthtml v3 format for built-in dictionaries (custom ones use v2). I'll be adding support to dictutil later, but it's a lower priority for me. This format adds a prefix_exceptions file (for the same reason as the dictutil workaround with duplicating variant entries) and a new option to set the credit text by adding a global zip archive comment. The word matching appears to be the same. It will work fine with existing v2 dictionaries, but v3 dictionaries which use prefix_exceptions will not be fully functional if used on older firmware versions.



For anyone currently using my TOC patches, note that these changes are essentially the same thing. I will be removing the two TOC patches and replacing them with one which allows you to change the indentation.

Thank you, as I use both custom dictionaries and TOC patches, I'll wait for them (or I'll go to github )

[davidfor]

Originally Posted by geek1011

To clarify one thing, the ExtraLocales isn't mandatory anymore. If you don't specify it, it will just use the zip filename as the dictionary name.

Also, if you do choose to use ExtraLocales, you won't need to use the patch anymore since the bug with language splitting for "Extra: " has been fixed.

Note that if you use the same locale as a built-in dictionary, it will not conflict since all custom ones matching a valid locale will have " (Custom)" appended to the name.

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.

[John Hopper]

Originally Posted by Braid

That's amazing news (for me).

Me too. This is excellent news.

The next improvement I'd really like is predictive text on the virtual keyboard, and an easy way to save annotations and access them later outside the book.

Sent from my SM-N976B using Tapatalk

[geek1011]

Originally Posted by Terisa de morgan

Thank you, as I use both custom dictionaries and TOC patches, I'll wait for them (or I'll go to github )

The patches are almost ready (jackie_w just has to finish updating a few), and will be released towards the end of this week. I just finished figuring out the changes for the dictionaries, so it's now just a matter of having time to implement them (you don't need to wait if you're just using existing dictionaries since the firmware will move them automatically, and v2 dictionaries will work perfectly fine on v3). My other mods/tools like NickelMenu, NickelSeries, and kepubify will work fine with this version as-is.

[geek1011]

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.

[gabryele]

Originally Posted by DNSB

One update in 4.24.15672 that some may find interesting is that Kobo has updated most of the dictionaries and are now using Oxford except for the unilingual French dictionary which is still Merriam-Webster.

so the dictionaries taken in https://www.mobileread.com/forums/sho...d.php?t=196931 should be overwritten by the update?

[davidfor]

Originally Posted by gabryele

so the dictionaries taken in https://www.mobileread.com/forums/sh...d.php?t=196931 should be overwritten by the update?

Hopefully so. From the 1st of October, most of the dictionaries are changing. Some are changing suppliers (the English dictionary will come from Oxford University Press) and some are changing versions (the Dutch dictionaries appear to be a different version). From comments elsewhere, the English dictionary is a much better dictionary. Hopefully the same can be said for the others.

The changes for custom dictionary handling will simplify adding or replacing the dictionaries.

At this point, I would suggest removing the custom dictionaries and trying the new ones. If you don't like them, you can always change back.

[toancv]

Originally Posted by geek1011

To be specific about what I tested and looked at:

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.

This is what I am looking for. Thank you for your time and works.

[JSWolf]

Originally Posted by PeterT

I believe you'll find that the dictionaries have yet to change; wait for October 1st.

Also this is the usual limited release, release so unless you manually install it you might not see it.

How would we get the new dictionaries if they are not available now?

[Uncle Robin]

Originally Posted by davidfor

From comments elsewhere, the English dictionary is a much better dictionary. Hopefully the same can be said for the others.

Better dictionaries would definitely close the gap in one major area where Kobo lags behind Kindle, for sure

[DrChiper]

Not "really" a bug, but when selecting as main language "Dutch", you get the impression that the same annotation menu option is available twice, while, for instance using "English" as the main language you then see the "beta" indication for the 2nd annotation menu option.
The menu is not properly sized, or sized maxed and chopped of the "beta" I guess.

[Quoth]

Originally Posted by John Hopper

Me too. This is excellent news.

The next improvement I'd really like is predictive text on the virtual keyboard, and an easy way to save annotations and access them later outside the book.

Sent from my SM-N976B using Tapatalk

The keyboard is already stupidly predictive on Caps and switching from punctuation to text. It half works.

Personally I think predictive text is pretty nasty. I turn it off on every phone, tablet, Programming Editor and Wordprocessor. I don't mind command line auto complete in a console that ONLY offers an option, if one exists and is the only one.

Convert Text as you type is also mostly pointless. I'm considering disabling Smart Quotes too as I now know how to type “”and ‘’ directly and it's actually dumb. It puts quotes where an apostrophe should be and for feet and inches marks (Prime Marks).

There are three easy ways to access Annotations:
There is a book menu item that can be added that exports the annotation. A line in reader.conf adds it. But you don't need it because the Annotations reading on Calibre via Kobo Utilities is brilliant. I use it a huge amount.
The Annotations Plugin on Calibre also works, but unlike the Book Menu Item on the device or the KoboUtilities it does more than one book at a time.

[GERGE]

Isn't the Oxford the same one Kindle uses?

[John Hopper]

Originally Posted by Quoth

The keyboard is already stupidly predictive on Caps and switching from punctuation to text. It half works.

Personally I think predictive text is pretty nasty. I turn it off on every phone, tablet, Programming Editor and Wordprocessor. I don't mind command line auto complete in a console that ONLY offers an option, if one exists and is the only one.

Convert Text as you type is also mostly pointless. I'm considering disabling Smart Quotes too as I now know how to type “”and ‘’ directly and it's actually dumb. It puts quotes where an apostrophe should be and for feet and inches marks (Prime Marks).

There are three easy ways to access Annotations:
There is a book menu item that can be added that exports the annotation. A line in reader.conf adds it. But you don't need it because the Annotations reading on Calibre via Kobo Utilities is brilliant. I use it a huge amount.
The Annotations Plugin on Calibre also works, but unlike the Book Menu Item on the device or the KoboUtilities it does more than one book at a time.

Re annotations, I'll look into those options, thanks. Though having it baked in would still be preferable for me.

When I read non-fiction, I tend to make a fair number of notes so having predictive text, as on the Kindle virtual keyboard, would speed up note taking on the Kobo considerably for me.

Sent from my SM-N976B using Tapatalk

[geek1011]

Originally Posted by geek1011

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.

I looked into this a bit more, and found that this won't be possible.

prefix_exceptions is somewhat of a misnomer, since it doesn't actually make exceptions for prefixes. Instead, it should be called word_redirects, since it just changes the word being looked up to another if it matches exactly. The target file must still have a variant/word matching the new one, and the original file won't be looked in at all.

This also means that there's already a bug in prefix_exceptions, albeit the inverse of the reason why prefix_exceptions was created. Previously, with v2 dictionaries, variants with a different headword prefix wouldn't be found (I worked around this in dictutil by duplicating the entries). Now, if you have a headword named after a redirected variant, it won't be found. For example, with the previous v2 behaviour, the entry for go/went would need to be duplicated into go.html and we.html, and you could also have another unique definition titled went in we.html. With the new v3 behaviour, you can just define it go/went in go.html and add a redirect entry like "went\tgo" to redirect it. But, this is where the new bug happens. Now, if you had a second entry in we.html named "went" (remember that Kobo dictionaries support multiple entries for a word), it won't be found since the words was redirected to "go". I can work around this bug by duplicating the headwords into the redirected files...which is just the counterpart to my previous workaround.

This bug could be fixed on Kobo's side by also looking up the original search term in addition to the redirected one.

Once Kobo releases the new dictionaries, I'm going to see if they have this bug (note: the current v2 dictionaries have the old bug with variant prefixes which are different than the headword prefix).

@davidfor, do you know anything about this behaviour/bug?

Edit: I just thought of a way to make the chinese dictionary hack possible even with the behaviour I discovered. I can hash each entry as a hidden variant, then add redirects for the real headwords to that hash (essentially limiting the number of prefixes to 2 ASCII alphanumeric characters).