https://bugs.freedesktop.org/show_bug.cgi?id=64176
--- Comment #8 from Patrick Ohly <[email protected]> --- (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > [...] > > > > > > The idea is that "phonebook" collation is a preference that is either > > > available under the current locale, or not. > > > > > > When a locale change has been detected, the sort keys will be generated > > > under the "phonebook" collation of the new locale... this will fallback > > > to the default ICU rules for the given locale if "phonebook" tailoring > > > is not available. > > > > So the "phonebook" keyword is just a hint that this field is meant to be > > sorted according to phone book rules if applicable? Is there value in having > > to configure this, instead of hard-coding it for each field? Well, perhaps, > > because then it can be enabled for other fields, too, without having to > > modify the source code. > > I'm asking myself the opposite question actually. > > Does it make sense to assume that an addressbook should be sorted > using "phonebook" rules ? and apply that everywhere ? I am less sure whether it should be applied to non-name fields. Not that sorting by address is useful, but in theory it is possible. But in general I agree, always using "phonebook" (in de and fi) and "pinyin" (in China) sounds right. The only reason for making it configurable is to accomodate for personal user preferences (both Pinyin and non-Pinyin sorting are valid), which (as far as I can tell) is not a useful use case (because Pinyin is sufficiently popular, and explaining to the user that they have the choice is too confusing). > > I don't see much value in being able to turn off "phonebook" for name > > fields, though. > > > > How would this work for Pinyin? In other words, what would > > CollationFields=family_name,pinyin:given_name,pinyin do when switching from > > zn_CN (where Pinyin is expected) to de_DE (where phone book is execpted)? > > If "pinyin" was explicitly specified as the collation rule for a given > field, then "phonebook" would definitely not be expected for de_DE. Then that's where configuring the collation in the source config breaks down, because we don't have some entity which would rewrite the config when the locale changes - other than EDS itself, of course. And if EDS rewrites the config, the option becomes useless. > > It looks to me that "phonebook" in EDS should be merely a flag for certain > > fields which inside EDS gets translated into a suitable (hard-coded?!) > > collation per current locale (ICU "phonebook" in de and fi, ICU "pinyin" in > > Chinese locales). See also bug #64173. > > > > Note that Pinyin may require additional work, see bug #64173 comment #3. > > Nod, also indexing anything by first letter/character seems to need the same > type of attention, there is AlphabetIndex which can be used for this: > www.icu-project.org/apiref/icu4c/classicu_1_1AlphabeticIndex.html > > My thoughts on this are, for sorting, one could use 2 sort keys for any > given field, the primary sort key would be the 'bucket' (character) which a > given word falls under according to AlphabetIndex, and the actual sort key > of the word would be the secondary sort key. > > This would also require some API churn at higher levels, i.e. any view > which wants to display a sorted list with letter/character grouping, would > need to first query the addressbook to know which characters are valid > for the current locale (and in what order those groups should be displayed). This grouping is a separate problem. Let's keep it out of the discussion for now. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
_______________________________________________ Syncevolution-issues mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution-issues
