https://bugs.freedesktop.org/show_bug.cgi?id=59571
--- Comment #15 from Patrick Ohly <[email protected]> --- (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Things should work now according to those tests. > > > > > > https://git.gnome.org/browse/evolution-data-server/tree/tests/libebook/ > > > client/test-client-change-country-code.c?h=openismus- > > > work&id=8051c2a1802d4b04cbea0409ff026f05598ce146#n331 > > > > > > https://git.gnome.org/browse/evolution-data-server/tree/tests/libebook/ > > > 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 [[email protected]] entered the room. (12:30:35 PM) kendy_ [[email protected]] 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 index. (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 number. (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_ [[email protected]] 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 freedesktop.org standard for setting the current location. (12:50:18 PM) mcrha: I'm not forcing them, they can do it, but it's not mandatory (12:50:19 PM) Jignesh [[email protected]] 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, freedesktop.org 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} [[email protected]] 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 address (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, right? (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: You are on the CC list for the bug.
_______________________________________________ Syncevolution-issues mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution-issues
