ebook-reader-dict VS libu8ident

I just stumbled across Kobo dictionaries, but none in a format which could be imported into Calibre, for further upload to Kindle. Copying the actual files or directories obtained by extraction of one of the Kobo dictionaries, into the documents directories of Kindle (as I've done to Littré and Roberts, to make them avail in the dictionary settings of Kindle) leads nowhere, either, so I am pretty much stuck.

I just had a look at a .dict from ebook-reader-dict (where the content comes from Wiktionary too, and they seem to deal with inflections too); "unfortunately" they seem to use .syn file too to store the inflections, so the behavior with the default dictionary app is similar... About further coding, I'll play with their code1 this week to check how the converting/compiling is done (who knows, maybe I/we can help there? :) ). So their is hope for a relatively quick solution :)

One can also access the whole content of Wikipedia -and a looot more- offline, thank to among others the project "Kiwix" (Wiktionaries can be found here, other readings are available also to download trough the app, and finally, you can always "ZIM it", if you don't find what you want in the lists). Kiwix doesn't have to be used in a "stand-alone" fashion, as you can access it within the pop-up window in NeoReader as shown in the 3rd pic (working on firmware 3.3.1 too). At last but not least, another offline solution based on Wiki AND in the StarDict format is the "e-book-reader-dict" project (thank to cerank for sharing it! I have to admit I didn't find it by myself before starting this...)

I use a stardict version of Wiktionary I have found on Github (others languages are available like French, German, ...)

I have no experience with studying/reading German books on a Kobo, so I cannot comment on that. However, the Kobo dictionaries are generally not very good for languages with a lot of inflection such as Spanish, Russian, etc. It seems there is a good French dictionary for it (but I don't read French either, so I cannot confirm): https://github.com/BoboTiG/ebook-reader-dict. (They also have a German dictionary that should support conjugated forms - check it out!)

You could look at https://github.com/BoboTiG/ebook-reader-dict

Wiktionary

I am trying to install these dictionaries using this guide.

I have not heard of the .dic format. Just check this link: https://github.com/BoboTiG/ebook-reader-dict You just need to download a zip file and copy it where you already tried to copy your other file.

Here are other Spanish dictionaries: https://github.com/BoboTiG/ebook-reader-dict/releases/tag/es

In programming languages it's much worse. Identifiers can either be unidentifiable, and if so everybody has a different opinion what "identifiable" means. Even the standard on identifiers, UTF-39, is buggy and has too many interpretations, leading to a complete disaster. https://github.com/rurban/libu8ident/blob/master/doc/c11.md

In punycode domain names it's quite simple still.

With other names, it's even worse. No-one cares. Linkers do not, username and filesystem drivers do not. The Apple HFS+ did care a bit one day, until someone in the higher ranks decided that no-one needs unicode security anymore and switched the new APFS to unsafe again.

No, it's definitely not safe to use unrestricted Unicode in a compiler. See https://github.com/rurban/libu8ident/ for identifier rules, and http://www.unicode.org/reports/tr55/ for much worse problems.

That's why unicode published the security guidelines and mechanisms to avoid such attacks. In 2004 already.

The problem is that nobody cared. Browsers invented punycode instead of following tr39, email ditto. But ok, at least something. Java did it, cperl did, rust did it.

Everybody else is vulnerable. Esp. most other programming languages, filesystems and login systems. https://github.com/rurban/libu8ident/blob/master/doc/c11.md

I'm maintaining such a library.

coreutils, diff, grep, patch, sed and friends all cannot find Unicode strings, they have no string support. They can only mimic filesystems, finding binary garbage. Strings are so rthi g different than pure ASCII or BINARY garbage. Strings have an encoding and are Unicode.

Filesystems are even worse because they need to treat filenames as identifiers, but do not. Nobody cares about TR31, TR39, TR36 and so on.

Here is an overview of the sad state of Unicode unsafeties in programming languages: https://github.com/rurban/libu8ident/blob/master/c11.md