How to cannonicate numbers in international form
tilman at baumann.name
Fri Jul 18 00:11:41 CEST 2008
Am 17.07.2008 um 22:45 schrieb Joachim Breitner:
> Am Donnerstag, den 17.07.2008, 22:14 +0200 schrieb Tilman Baumann:
>>> In most cases, just a simple "n last digits match" test would be
>>> sufficient. That's what all the usual phones do anyway, and false
>>> matches are very rare. But hey, we can be more sophisticated :-)
>> But way resort to such methods if the only reason is some crazy
> For me, it’s not a corner case: I just don’t want to read phone
> such as +49703212345 in my address book, where I have to look closely
> where the area code starts and ends,
I like to.
> so as a user, I expect my phone to
> know that I the call I made to 0703212345 (dialed manually) is
> to the person with the number +49703212345 or even 07032/12345 in the
> contact list.
> Do you disagree here already, or is this still a valid expectation?
We agree somehow. But it is a half baked solution which only solves
_one_ issue to a maybe acceptable degree. Which is matching
international numbers on local address book entries.
Making your phone book with crappy local address work abroad needs a
> Then, going to the question of implementation, I see three options:
> A) Having the user specify the details how he interprets phone numbers
> (mostly, the country code prefix, I guess). Then the phone can fully
> qualify every incomplete it sees for a reliable comparison (not for
> display, though), and for reliable use of the phonebook in foreign
In my eyes this is the only method that works reliably and exactly.
Well, if you really need to. Make fuzzy match a fallback.
My point is, there is a way to _exactly_ transform numbers. (At least
almost every number if do not add some special code for known freak
Come on, this phone is primarily for geeks. Please don't gnome withe
those stupid gnome arguments.
Like anything, _any_ user might not understand or like to use, is a
The right way is to give full flexibility if the user knows what he
wants. But make reasonable default choices if he does not.
Only matching the last 7 digits only qualifies somehow for the latter.
> B) Do not expect the user to enter anything, and do „best guess“
> matches. Here we have two alternatives:
> B1) Have code that handle the various specialities around the world to
> understand various number themes.
> B2) Compare the last n (maybe 7) digits, and leave it to the user to
> use fully qualified phone numbers when he encounters an (unlikely)
Well, no need to ask the user anything.
A fuzzy match like B2 could only be used to match numbers against the
If this fails, bummer. But no real harm done.
> I think A) is not good because it needs user intervention, and B1) is
> too complicated – so that’s why :-)
User intervention is not bad. We just must not force the user to deal
with stuff he wants to ignore.
It's a smart phone after all.
>>> By the way, I don't think requiring people to enter canonical
>>> is a good idea. When you travel, you often enough get numbers that
>>> work if you dial them locally "as is", but you may not necessarily
>>> have a good enough understanding of the local numbering plan to turn
>>> them into fully qualified numbers.
>> Well, if you (as a user) can not provide these data (because you
>> understand it) you just have to live without the benefits. No big
> I think it is a big loss. Especially those users who can not provide
> data (becaus they don’t care any mostly stay in one country) are the
> ones that will expect their phone features to work without having to
> type "+49" before every call.
Well, its not so much about phone features to work.
The only feature a fuzzy macht can deliver is a number match against
known numbers from the address book. Only visual eye candy, no big
But go ahead, make some fuzzy callback for that. But please a callback
and not a default.
For making non international phone numbers from the address book work,
we ne nothing else than a _exact_ method to transform numbers.
Anything 'fuzzy' is not good enough for that.
And please acknowledge that this is a major feature.
More information about the devel