I’d expect sorting that doesn’t take letter case into account. administrativní poplatek should be the first item.
1 Like
The preferred sorting universally should be case insensitive, accent sensitive. But since we are here, maybe we could make this configurable the same way as date format?
The configuration is a good idea.
default:
case insensitive, accent sensitive.
configuration in appsettings will contain:
- case sensitivity
- accent sensitivity
@tvavrda should the configuration actually apply to all sorting everywhere in Origam or just sorting of the combo boxes in the client? And what about filtering? Wouldn’t it be strange if we don’t apply the same configuration to the filtering too?
This is potentioanlly a lot of work in the client and the server. Case sensitivity of the database can be adjusted by configuration but accent sensitivity probably not.
Case/accent sensitivity can be configured for an MS SQL database at least. But then we must have an option to configure the same for the client application as well. Which we don’t.
So the answer is: YES, it should also be related to filtering etc. If the database is accent sensitive, case insensitive, the frontend should also be configured this way (both sorting and filtering).
In theory, the database can be configured to sort/filter in different collation for each query (e.g. if the database column is named something like TranslationSpanish then you can force the server to order/filter in Spanish collation. But we don’t support that in ORIGAM.
I’ve made tests with the countries. It seems, that sorting doesn’t respect national norms.
Accent Sensitive
"ClientSortingAndFilteringConfig": {
"CaseSensitive": "false",
"AccentSensitive": "true"
},
Česká republika is still near the bottom of the table. I’d expect following sequence: Česká Republika, Čína, Dánsko.
I’ve also made an observation that server delivers data from the server ordered correctly.
Accent Insensitive
"ClientSortingAndFilteringConfig": {
"CaseSensitive": "false",
"AccentSensitive": "false"
},
This seems to be correct.
This is because ordering has actually nothing to do with accent sensitivity. With filtering it is important but for sorting it is kind of irrelevant. This is my fault. What we did was to “latinise”, i.e. remove accents and sort (in case of “accent-insensitive”). Maybe it should be ok to use this also when “accent-sensitive” is turned on.
The question is if latinisation will correctly implement national ordering rules. Also it would be interesting to see what does it do with non-latin? Some of our users definitely use Arabic.
@jsusen was latinisation the only way to implement this? Aren’t there ways how to support national ordering in a good way? What about this?
There obviously are. As you mentioned there was a misunderstanding as to how the accent sensitivity should be implemented and where it should be used. So should we use the localeCompare for ordering always and keep using the accentSensitivity option in the appsettings for filtering?
Yes, I think we should do it this way.
I’ve made another round of tests.
Accent Sensitive
"ClientSortingAndFilteringConfig": {
"CaseSensitive": "false",
"AccentSensitive": "true"
},
Česká republika is not near the bottom of the table anymore. But still countries starting with C have to be before Č according to the Czech stardard. I’d expect following sequence: Curaçao, Čad, Černá Hora, Česká republika, Čína, Dánsko .
Accent Insensitive
"ClientSortingAndFilteringConfig": {
"CaseSensitive": "false",
"AccentSensitive": "false"
},
This seems to be correct, but…
Letter CH
CH is considered as a letter in Czech and other languages (Ch (digraph) - Wikipedia). Thus countries Chile and Chorvatsko should be put between Honkong and Indie.
It turned out I wasn’t in Czech locale while testing it. Everything seems to be OK when Czech locale is set.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.