In the accounts view, sorting by columns "account name" or "description" doesn't comply with alphabet of the locale if there are non-ASCII characters in the strings. It might be related to https://bugs.gnucash.org/show_bug.cgi?id=723353 My example: I use GNUCash in Czech language (even though my Windows is in English). The correct ordering of these Czech words should be: Citron Částka Člen Další Havárie Chlazení Internet Problems with my example: (1) Letters like ěščřžýáíéůú should be right after their ascii alternatives (escrzyaieuu respectively). However, they are put at the end after "z". (2) "ch" is considered one letter composed of two characters in Czech and it belongs between "h" and "i" in the alphabet. Standard libraries for locale handling should be able to provide locale-based alphabet sorting.
I can confirm this behaviour for LANG=de_DE. I would expect O,Ö,U but get O,U,Ö for sorting the register by description. So we have CoA and register, but I watch it also e.g. in the transaction report.
Does anyone know whether GnuCash has a locale-sensitive string-comparison function? Returns -1, 0 or 1? Transaction Report could use it instead of guile's string sorting.
Not quite that simple, but see https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf8-collate-key. There's an example of using it in gnucash/gnome/dialog-sx-editor.c line 500ff. I think it would make sense to create a gnc_collation_compare in core-utils somewhere, something like (untested) int gnc_collation_compare (const char* a, const char* b) { char* akey = a ? g_utf8_collate_key (a, -1) : NULL; char* bkey = b ? g_utf8_collate_key (b, -1) : NULL; int result = g_strcmp0 (akey, bkey); g_free (akey); g_free (bkey); return result; } We also use g_utf8_collate_key for sorting menus in gnc-menu-extensions.c, and GtkTreeView sorting also uses it. That covers most of our needs in the UI but it wouldn't hurt to check every use of strcmp and g_strcmp0 and replace any that are used for localized or user-created strings.
Interesting dialog-sx-editor.c#L500 g_utf8_collate_key was done in 2005. The keys are discarded immediately; why not use g_utf8_collate? See recent thread on ICU-support: https://sourceforge.net/p/icu/mailman/icu-support/thread/CAFYQx%2BDB%2BKXA7GqFxL35vk54Pp3SMwmQO2Q7pst%2B__Wj15HgRA%40mail.gmail.com/#msg37137856 subject "Options for Immutable Collation"
Good point. The basic version of g_utf8_collate is nearly identical to my gnc_collation_compare, the difference being that repeats g_utf8_collate_key's internals rather than calling it. If profiling were ever to show a performance problem related to natural language sorting we could we could use g_utf8_collate_keys. As for the discussion on the ICU list, I found it amusing but not particularly informative: The points made by the ICU contributors were intuitively obvious and the questioner clearly hadn't thought through his question.
Should fixed on latest maint. Try tomorrow's nightly at https://code.gnucash.org/builds/win32/maint/ and report back.
