https://bugs.freedesktop.org/show_bug.cgi?id=64176
--- Comment #12 from Tristan Van Berkom <[email protected]> --- (In reply to comment #11) > (In reply to comment #9) > > > 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. > > > > I'm not convinced of that, from what I understand your requirements > > are described by ICU as "phonebook" order, where "phonebook" order > > does not exist in 'zh' locales, and the the default in 'zh' locales > > is already "pinyin" (if your requirement was instead "pinyin", then > > you would not expect "phonebook" order in de_DE locale at all). > > My expectation is that EDS does "the right thing" by default for each field, > without some non-existent entity having to tell it what that is. By all > means, let's add overrides for the default behavior in EDS, but let's keep > these overrides optional. > > The overrides would be: > - "phonebook" - enable phonebook > - "no-phonebook" - disable phonebook > - "pinyin" - enable pinyin > - "no-pinyin" - disable pinyin > > And the defaults should be: > - use "phonebook" for name fields (and only for name fields) in > "de" and "fi" locales > - use "pinyin" with Chinese Pinyin and Latin characters mixed (which is > *not* the default in ICU) for all strings in Chinese Right, this is not exactly 'pinyin' according to ICU (as mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=64173#c3) And it might even mean using a different API altogether than UCollator (not sure yet what exactly is a 'Han-Latin transliterator'), but of course, sounds like something doable underneath an abstraction API (such as the ECollator API I've been working on). Also, I know you would rather not mix subjects but there is overlap here, what happens when we want this specific interleaved brand of 'pinyin' to be the sort order, and we also want to navigate to the results starting with '江', or the results starting with 'J' ? If the results are interleaved with latin characters, it's unclear at this point if this can work properly when combined with AlphabetIndex. > It's quite likely that this knowledgebase will grow over time as more > localization experts tell us about the preferences in their country. EDS > might not be the best place to store such a knowledgebase, but where else > can we put it? I've been thinking, if there is a consensus on what this knowledgebase is, it might be very appropriate to have this behaviour in: https://developer.gnome.org/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-collate Which is already documented as: "Compares two strings for ordering using the linguistically correct rules for the current locale" And it looks like this knowledgebase is exactly that, i.e. what are the "linguistically correct rules". Perhaps it might even make sense to add something like: g_utf8_collate_key_for_addressbook() Which might be acceptable for Glib, seeing as there is already an existing function: g_utf8_collate_key_for_filename() (also, we can't very well suddenly change the behaviour of the existing g_utf8_collate_key() function, as that would certainly break existing applications). Of course, we'd have to be very sure about the value of this knowledebase before proposing something like that for Glib, and it might help to have the code live in EDS as a proof of concept before trying to push it into Glib. > > By not storing the default in the source config, we can fix the wrong > default by upgrading EDS. If we were to put the setting into the config, it > would be difficult to change later, because it would be uncertain whether it > merely represents the old, incorrect default value or was chosen > intentionally. -- 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
