Comment # 15 on bug 59571 from
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > Things should work now according to those tests.
> > > 
> > >
> > > client/test-client-change-country-code.c?h=openismus-
> > > work&id=8051c2a1802d4b04cbea0409ff026f05598ce146#n331
> > > 
> > >
> > > client/test-client-custom-summary.c?h=openismus-
> > > work&id=8051c2a1802d4b04cbea0409ff026f05598ce146#n429
> > 
> > These are the relevant commits:
> > 7748a56 sqlitedb: Only create indexes after introspection
> > 606b360 sqlitedb: Use proper length of default country code
> > 74e3f1e sqlitedb: Fix another issue phonenumber matching issue
> > 3443ed1 sqlitedb: Assing country-code to address summary
> > 
> > They reestablish rewriting the summary when the local changes. This solution
> > still needs to be upstreamed.
> Again, we've still had issues convincing Milan that the addressbook data
> needs to be re-written on a locale change (or at least for a country code
> change), that still needs to be upstreamed.

I think I managed to convince Milan that rewrites on "preferred location"
change are necessary. From IRC (sorry, don't know the date):

(12:28:30 PM) mcrha: yes, and no. I believe the index rebuild is not needed
(12:29:17 PM) tristan left the room (quit: Read error: 148 (No route to host)).
(12:30:14 PM) heroux [] entered the
(12:30:35 PM) kendy_ [] entered the room.
(12:30:37 PM) mcrha: to clarify that we talk about the same: the problem
discussed here is that the phone number indexes doesn't work correctly for
phone numbers without country codes, because eds currently stores guessed
country codes there (based on current locale or whatever), while keeping the
contact as is?
(12:31:43 PM) pohly: mcrha: no. EDS does not store guessed country codes in the
(12:31:57 PM) pohly: Let's take an example.
hasselmm_ heroux heroux_ 
(12:33:16 PM) pohly: For the US, libphonenumber parses 1234 as local number 234
because 1 is a local dialing prefix. I think hasselmm_ was wrong earlier when
he said that 1 is turned into the +1 country code.
(12:33:39 PM) pohly: In other countries, 1234 is used as it is as the local
(12:33:57 PM) xtian is now known as xtian|munch
(12:33:57 PM) pohly: In both cases, the country code is explicitly marked as
unset by libphonenumber.
(12:34:19 PM) pohly: In EDS, that means that the country code for that number
is unset in the index.
(12:34:36 PM) pohly: But the local part in the index is different: 234 in the
US, 1234 elsewhere.
(12:35:10 PM) heroux_ left the room (quit: Ping timeout: 600 seconds).
(12:35:35 PM) pohly: When the lookup happens when outside the US, it is done
with 1234 as local part. This fails when the index was created in the US.
(12:37:31 PM) pohly: Suppose the number really is a local German number 1234.
Should the lookup fail just because I imported the contact while the country
was set to US? No.
(12:38:14 PM) pohly: Therefore EDS needs to re-evaluate such ambiguous numbers
when the country changes.
(12:39:42 PM) mcrha: right, it makes me feel like it being a proof why using
application current locale for this is wrong.
(12:39:46 PM) kendy left the room (quit: Ping timeout: 600 seconds).
(12:40:21 PM) pohly: mcrha: what's the alternative? Use a fixed country that
cannot be changed by the user?
(12:40:44 PM) kendy_ left the room (quit: Ping timeout: 600 seconds).
(12:41:00 PM) mcrha: No. As I mentioned above, a user visible option.
(12:41:21 PM) pohly: And what if the user changes that option? Same problem ->
index becomes invalid.
(12:41:58 PM) pohly: Or are you saying that changing that option should trigger
a rewrite the DB, with that code living where the option is handled?
(12:42:05 PM) mcrha: then you can rebuild the index (which will most likely
cause writes in DRA, maybe not)
(12:43:01 PM) pohly: But you would rebuild in EDS itself, right?
(12:43:49 PM) mcrha: pohly, you convinced me that rewrite might be done. I want
an explicit option for default country code for phone numbers, thus it'll not
be guessed from nowhere.
(12:43:56 PM) mcrha: yes, in eds
(12:44:36 PM) pohly: Okay, so we agree that rewriting is necessary on country
changes. Now we can focus on where that information is supposed to come from
when EDS starts.

He likes to see some more explicit code for detecting the country. Deriving it
from the locale is just a heuristic. I agree with him on that, but I am not
sure what the right solution is. Milan and I seem to disagree on that:

(12:44:36 PM) pohly: Okay, so we agree that rewriting is necessary on country
changes. Now we can focus on where that information is supposed to come from
when EDS starts.
(12:45:14 PM) pohly: It can't be in Evolution, because Evolution might not be
running and EDS should not depend on settings of one particular GUI.
(12:45:56 PM) mcrha: where you get the value for that explicit option is up to
you, being it a GSettings key, a phone-provided country, system setting country
(like system timezone?), or whatever is not that important, just do not use
current locale, which doesn't tell you where the person actually is
(12:46:40 PM) mcrha: right, for eds on linux it might be eds' GSettings key.
(12:46:53 PM) mcrha: "on linux desktop" it is
(12:47:14 PM) pohly: And who sets that key?
(12:47:35 PM) mcrha: anyone?
(12:48:07 PM) kendy_ [] entered the room.
(12:48:25 PM) pohly: Let's ignore other desktop systems and look at just GNOME.
Which GUI component in GNOME would set the value?
(12:48:27 PM) mcrha: current locale is also set by anyone
(12:48:47 PM) mcrha: evolution will have that option available for sure
(12:49:10 PM) mcrha: if others will want to touch it, then they can too.
(12:49:37 PM) pohly: I doubt that you'll be able to convince other software
developers to write an EDS specific GSettings key.
(12:49:53 PM) pohly: What we need is a standard for setting the
current location.
(12:50:18 PM) mcrha: I'm not forcing them, they can do it, but it's not
(12:50:19 PM) Jignesh [~Jignesh@] entered the room.
(12:51:16 PM) mcrha: if I would want to do that simple, then I say to read the
key value on start of the addressbook factory and work with it all its runtime.
As it influences only indexes, then it should not be a problem, right?
(12:52:04 PM) mcrha: pohly, would be interesting, but as long
as it's for eds only... Maybe once other parts of the system will need it
(12:52:53 PM) mcrha: pohly, hmm, is this "only" about indexes?
(12:53:00 PM) {srinidhi} [~srinidhi@] entered the room.
(12:53:09 PM) pohly: I'm not convinced. Depending on a setting that is likely
to be unset unless the user explicitly sets it in Evolution (and knows about
it!) seems to me a step backwards compared to guessing based on the locale,
which is guaranteed to be set. I'm merely pragmatic here. IMHO we should have
an explicit setting and the locale based approach as fallback.
(12:53:35 PM) pohly: Indices and lookups.
(12:54:10 PM) mcrha: right, index and lookup
(12:55:19 PM) mcrha: pohly, will the index work properly if a US number 1234
will be renormalized in Geramy in indexes, and you'll search for 234?
(12:55:35 PM) mcrha: *for Germany
(12:57:58 PM) mcrha: you said that US:1234 is turned into 1|234, thus if I
search either for 1234 or 234 I still get the same contact, but the Germany
changes 1234 to |1234, thus searching for 234 will not work "suddenly"?
(12:58:38 PM) pohly: mcrha: there is no "US:1234" - that would be "+1 1234".
(12:58:51 PM) pohly: There is just a contact with TEL:1234.
(12:59:08 PM) pohly: Where EDS doesn't know whether that number is a US or
German number.
(12:59:11 PM) mcrha: it was meant as my notation for "1234" with "US as the
default country code"
(01:00:21 PM) pohly: Correct, in the US, searching for 234 would match TEL:1234
and TEL:234. In Germany, 234 would not match TEL:1234.
(01:00:34 PM) pohly: Or rather, should.
(01:01:15 PM) mcrha: That would be very confusing for users, no?
(01:01:37 PM) pohly: Why?
(01:02:10 PM) kjetilho: god, I hate how that works most places.  so many places
assume that your phone number is located in the same country as your street
(01:02:15 PM) mcrha: if I want to search for 234 in evolution's UI, then I
expect consistent results
(01:02:32 PM) pohly: You are talking about a substring search. That still works
as before.
(01:02:36 PM) kjetilho: so you can't use a Swedish phone number if you live in
Denmark, since +45 is implied
(01:03:02 PM) pohly: The semantic search only applies when the search strings
is known to be a valid phone number.
(01:04:37 PM) pohly: This difference is important! The semantic search is
primarily meant to be used for caller IDs, which always have an explicit
country code.
(01:05:24 PM) Jignesh left the room (quit: Remote closed the connection).
(01:05:32 PM) pohly: So the search in Germany would be for +491234 or +49234.
The former matches TEL:1234, but not TEL:234, and vice versa.
(01:06:40 PM) pohly: When the user enters 234 with the intention to dial the
matching number from his address book, then a substring search must be done and
yes, that needs to find both TEL:1234 and TEL:234.
(01:08:00 PM) pohly: Strictly speaking, it shouldn't be an exact substring
match as currently done by EDS. A better solution would find both "TEL:12 34"
and "TEL:1234" when searching for "234" - we don't have that in EDS.
(01:10:20 PM) mcrha: ok pohly, we agreed that a) index rebuild is needed due to
contacts without country code when the default country code changes; b) the
default country code may come from trustful source, either some explicit
setting or, for your phone usecase, from phone 
(01:11:26 PM) mcrha: b) Using a default country code is wrong, because one may
miss contacts on lookup in certain cases?
(01:11:45 PM) mcrha: err, c) Using...
(01:12:34 PM) pohly: Please be more specific about case c). Using the default
country code for what?
(01:12:54 PM) pohly: We agree on a) and b).
(01:13:26 PM) mcrha: for the setting, as you wanted to fallback based on
current locale, if it's not set, while I would add a default value (other than
empty string)
(01:13:51 PM) mcrha: thus the setting is always set
(01:15:18 PM) pohly: Then we disagree about c. I think we need a fallback for
cases where the country is not set explicitly.
(01:16:51 PM) pohly: Using the current locale is more likely to be right than
falling back to a fixed value.
(01:17:08 PM) pohly: Or refusing to execute semantic searches.
(01:17:18 PM) pohly: That would be the alternative.
(01:18:15 PM) pohly: We do agree about c in the sense that a wrong guess can
lead to unexpected results.
(01:18:39 PM) pohly: So it certainly would be desirable to have a more visible
explicit setting that the user is aware of.
(01:19:21 PM) pohly: Need something to eat - will be back later.
(01:20:32 PM) mcrha: same here, feeding time :)
(01:21:07 PM) mcrha: by the way, for me the locale is wrong, I sit in Czech
Republic, but my locale is en_US.
(01:22:07 PM) pohly: mcrha: my setup is similar. But we are power users and
know better than entering ambiguous telephone numbers into our address books,
(01:22:34 PM) mcrha: One can guess less when examining the vCard more
thoroughly, like pairing home phone with home address' country, similar for
work phone & address, but it doesn't work always, and is a minor improvement
(01:22:48 PM) pohly: At least I switched to fully qualified numbers years ago,
because I wanted my address book to work everywhere.
(01:23:20 PM) mcrha: hehe, I enter 1234 or "home-phone" quite often into
Contacts in evo :) My phone is full of "no-country-code" phone numbers
(01:23:37 PM) pohly: Well, man up and fix that ;-)
(01:23:46 PM) mcrha: :)
(01:24:42 PM) mcrha: it seems the result of our chat will be "the best effort"
approach, which can fail in certain cases
(01:24:46 PM) pohly: It's necessary when you sync to a phone and travel,
because I guarantee you that the phone will not be able to dial these local
numbers from abroad.
(01:25:17 PM) pohly: mcrha: yes, it's all about heuristics and doing what is
right most of the time.
(01:25:27 PM) mcrha: yeah, I agree (and do not travel) :)
(01:25:44 PM) pohly: So now I really need to go....
(01:25:51 PM) mcrha: sure, later

You are receiving this mail because: