1:34 a.m.
https://bugs.freedesktop.org/show_bug.cgi?id=64176
--- Comment #8 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(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.