https://bugs.freedesktop.org/show_bug.cgi?id=64176
--- Comment #7 from Tristan Van Berkom <[email protected]> --- (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 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. What would be expected is de_DE@collation=pinyin, and a fallback to de_DE if no "pinyin" tailoring rule exists for de_DE. So I refer to the previous question, on what grounds do we claim that "phonebook" order is expected for the de_DE locale ? If there is any logic behind these expectations, then perhaps we should indeed hard code a list into EDS. Since I don't see any rationale in hard coding it right now, I've went with a configuration instead. > 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). -- 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
