In the account view, I'm entering a transaction. In the column where I fill the other account of this transaction, when I start typing, a drop-down shows with accounts filtered that contain the substring I have already typed. However, this doesn't work when the typed substring contains non-ASCII characters. In Czech, they are typically ěščřžýáíéůú. In alphabets with punctuation like "´" or "ˇ" in Czech, users often type without the punctuation. So the bug could for example be fixed in this UX-enhancing way: It would be nice if "Aktiva:Karlův Účet" showed in the suggestions drop-down after typing substring "ucet". For your inspiration, I often use the following code in Java: String asciiStr = java.text.Normalizer.normalize(nonAsciiStr, java.text.Normalizer.Form.NFD).replaceAll("[^\\x20-\\x7E]", ""); That is: 1) normalize to NFD form 2) strip all characters except for \x20-\x7E This might be related to https://bugs.gnucash.org/show_bug.cgi?id=797989
> This might be related to https://bugs.gnucash.org/show_bug.cgi?id=797989 It's not, that's about reports failing to observe localized collation. String asciiStr = java.text.Normalizer.normalize(nonAsciiStr, java.text.Normalizer.Form.NFD).replaceAll("[^\\x20-\\x7E]", ""); Your hack is amusing but very Euro-centric. Not all languages decompose into ASCII + combining marks.
I might have formulated it in a confusing way when I just said "doesn't work" and then I immediately started suggesting enhancement. Still I consider it a bug that typing substring "Účet" (including punctuation and even capital letter) doesn't show any suggestions in the drop-down, even though "Aktiva:Karlův Účet" is an existing account. > Not all languages decompose into ASCII + combining marks. You are, of course, right. I forgot about other than latin-based alphabets.
Sorry, I didn't understand that this was about the match failing when you type the actual string. That would be akin to bug 797843 that we thought was fixed. I have M$'s Czech keyboard installed and I can replicate the problem with účet (how do you make the uppercase ú?) and čet. In fact it reproduces in Linux too.
Thanks for looking into it. > how do you make the uppercase ú? If this wasn't a rhetorical question, then the simplest way is with CapsLock: Ú = [CapsLock]; [ú/]; [CapsLock] Č = [CapsLock]; [č4]; [CapsLock] The Shift way is: Ú = [´ˇ]; [Shift] + [U] Č = [Shift] + [´ˇ]; [Shift] + [C] Key [´ˇ] is next to [Backspace].
Ironically it turned out to be that we were normalizing the account names but not the search string. Worked fine on e.g. Cyrillic because there's no difference between normalized and non-normalized code points. A simple fix once I figured out the problem. Please test in tomorrow's nightly build from https://code.gnucash.org/builds/win32/maint.
*** Bug 798023 has been marked as a duplicate of this bug. ***
I can confirm that it is fixed in version 4.4 Thanks
