I have quite a lot of "Extra:_" dictionaries installed, but all mine are single language Eng-Eng dictionaries rather than translation dictionaries.

I was able to get all mine working again by manually editing the Name column of the Dictionary table in the Kobo SQLite database. In the hope that you'll be able to extrapolate a similar solution for your translation dictionaries here is an example of the minor change I made for one of mine:

Before edit:
Suffix: -oc
Name: Eng_OxfordConcise

After edit:
Suffix: -oc
Name: Extra:_oc

You might need to do a full power off/on after changing the database.
After the change my dictionary drop-down menu shows Extra:_oc as one of the items (just like it did in fw 4.7.10413) and selecting it accesses the physical dictionary file .kobo/dict/dicthtml-oc.zip

Hope this helps :)

Thanks Geoff, oren64, and everyone else who helped! Everything works well.

Thanks! That works for translation dictionaries, too.
Before: Dansk - English
After: Extra:_da - English

BTW, it seems that it also partially works for something like "Extra:_Dansk - English" (with "Dansk" instead of "da" in the ExtraLocales line of Kobo.conf) - as long as you don't mind that "English - English" is displayed in the header of the dictionary window (the definition that is shown is from the chosen dictionary).

Unfortunately, using a non-breaking space instead of "_" doesn't work anymore but this could be due to the application I use for manipulating the database. I'm not sure if it actually inserts a non-breaking space or if just falls back to a "normal" space.

I haven't noticed any difference in the space between KePub page number and bezel on my Glo, but I am not using any of the nickel patches you list except for `Custom synopsis/details line spacing`. (I am using all of the libnickel patches you list except for `Brightness fine control`.)

I'd check that you haven't accidentally enabled `Custom reading footer style`, which is the only one I can think that would cause what you describe. But if not that then it might just be trial and error to find which patch is causing the problem.

GeoffR, right now I'm working on an improved version of patch32lsb which will have many improvements (it's listed on the README). I've finished the core stuff (and unit tests for it), but will not be done the rest until another 2 weeks at the earliest.

Basically, it will still support the same patch format, but will also support another one which I'll make based on YAML (or maybe JS). It will be able to do everything in one binary (which will be able to run on anything Go runs on and will not require additional tools to be included. It will also support zlib replacement and a few other useful things. It may also be able to make sure the right version of the firmware is being used. It's also way more readable than C code.

You were right I did - and it looks ok now. Thank you.

Thanks for the patch, guys! Everything is working perfectly on my first-generation Aura.

That sounds great. Thanks.

No problem. I just finished a drop-in replacement for patch32lsb for testing (don't actually use it yet). I already do preliminary checks for some of the patches, as my version should have identical results, but it would be nice if you could test it a bit (especially if you know any edge cases). It should have feature parity with the original patch32lsb (and it's about 30% the lines of code). The binaries are here: https://github.com/geek1011/kobopatc...ses/tag/v0.1.0

Once this is perfected, I'll work on the all-in-one version and zlib support. DO NOT USE THIS ON AN ACTUAL DEVICE YET (there are known issues). It will probably be ready in a few weeks.

BTW, the keyboard patch is broken at the line which is like: replace_string = FFFFFFD4, `ƒ\0`, `ƒ`

Do you mean the FFFFFFD4? The addresses/offsets have 32-bits, so that should give the same result as writing a negative:

It does not work even in the original patch32lsb. I'm also reading into a 64-bit integer, so I'll change that and see, but I cannot find the string even using a hex editor.

I've released v0.3.0 of my patcher: https://github.com/geek1011/kobopatc...ses/tag/v0.3.0

It should now have perfect compatibility with the original patch32lsb. I've tested it with most of the patches enabled on multiple versions and the output matches.

It would be nice if it could be tested by other people (by comparing the output, NOT actually installing the patched firmware) with patches which may include edge cases which I might have missed.

The letter `ƒ` is a script-f (U+0192). In libnickel.so.1.0.0:

`Disable QuickTurn` patch
 

This patch disables the new QuickTurn feature. (Edit: Where a touch-and-hold near the bottom of the screen in KePub books causes pages to keep turning until the hold is released.)

libnickel.so.1.0.0.patch, firmware 4.8.10956:

Yes, I figured that out.

I've now finished my new patch format. See a demo (with documentation and a list of the format's advantages) of it here and a sample patch here. Please tell me what you think of it, and if I could make it better in any way.

I'll also make a conversion utility to convert from the old format later.

I've also finished a working POC (I haven't uploaded binaries yet) of the all-in-one patcher. I even tried patching my kobo with it and it worked! The directory structure and config files looks like this (minus README.md and oldpatches). You would then place the kobopatch binary in the same dir along with the update file, and then all you need to do is run the kobopatch binary. It already does things faster and more reliably (e.g. it keeps all file attributes, it has more error checking) than the shell script. I'll upload binaries once I finish the log file, patch group checking, and add some unit tests. Please tell me what you think of it so far.

Also, keep in mind that I won't be comfortable to release this as stable until I test it more (and wait another few weeks for any bug reports to surface). Once I upload binaries, you can still try it if you are comfortable with the (small) possibility of needing to reimage your SD card.