How to cannonicate numbers in international form

[Tilman Baumann]

Number normalisation is really no big magic.

The only thing you need to know is how you (user) format your numbers 
when not using international form.
This would be the dial plan the user is accustom to.
There is nothing fuzzy about  this. Because you organize your umbers 
only in relation to _one_ dial plan.
(Anything else would explode your head)

So you need co tell your phone once how your dialplan works.
And since we could probably just ask the SIM or the network where we are 
  or how dialing works here we could even do this automaticly.
Or use some rather crude location based approach.

This is a perl method we use in our company for that. Please note that 
publicAccessPrefix and pbxCode are superflous for our purpose. Because 
we are not behind some PBX.
Sorry for the email line breaks.

I added some comments for values Germans would choose.
sub canonicalForm {
         my $number  = shift;

         my $PAPrefix = publicAccessPrefix;  # No PBX. But usually 0
         my $IDPrefix = internationalPrefix; # 00
         my $LDPrefix = longDistancePrefix;  # 0

         my $Country = countryCode; # 49
         my $Area    = areaCode;    # 761
         my $PBX     = pbxCode;     # external number of your PBX

         $number =~ s/[^+0-9]*//g;    # strip white space etc.

         if ( $number =~ m/^[^+]/ ) {
                 $number =~ s/^$PAPrefix$IDPrefix/+/;    # replace int. 
dialing code
                 if ( $number =~ m/^[^+]/ ) {
                         $number =~ s/^$PAPrefix$LDPrefix/+$Country/; 
  # long distance number
                         if ( $number =~ m/^[^+]/ ) {
                                 $number =~ 
s/^$PAPrefix/+$Country$Area/;    # local number
                                 if ( $number =~ m/^[^+]/ ) {
                                         $number =~ 
s/^(.*)/+$Country$Area$PBX$1/;    # else cononicalize
                                 }
                         }
                 }
         }
         return $number;
}



I make some assumptions. Please correct me if they are not true.
- GSM works with international numbers. If a call comes in it will be 
always formatted in international form.
- The user uses only one dial plan. (Anything else would be a usability 
disaster but doable)

First usage:
Calls comes in. Try to match it against our telephone book.
Just transform every number before matching.

Second usage:
Transform every number after user put it in his phone book. Only save 
internationalized numbers if possible.
This would condition the user to use international form and acknowledge 
its existence and significance.
This should be done in some user visible way. So he sees what happens 
with his number.

If we find no location based or SIM based approach that works, we could 
ask the user on first entry of any number after his local dialing habits.
If a user is not capable of answering this question we just ignore 
number transformation. This would not screw usability too much. The user 
would just not be able to have the benefit of a seamless usage of phone 
numbers.



Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, den 16.07.2008, 17:43 +0100 schrieb Chris Lord:
>> On Wed, 2008-07-16 at 18:04 +0200, Joachim Breitner wrote:
>>> Hi,
>>>
>>> Am Dienstag, den 15.07.2008, 23:20 +0200 schrieb Jay Vaughan:
>>>>> What would be a good way to tackle this issue? Anything else but tell
>>>>> our users always to write +49172..., even when dialing by hand?
>>>> Match the phone numbers backwards from right to left instead of left  
>>>> to right, and throw away 'whitespace' which would be defined as  
>>>> 'anything that isn't a number'.
>>> thx, it’s simlar to what I’m doing already in my openmoko-messages2
>>> patches. My question was rather: Is this the right way to fix it? There
>>> are a lot of places where the comparison of phone numbers happens, down
>>> into evolution-data-server, so I’m wondering if there is consensus that
>>> this is the right way.
>> Unfortuantely, this is one of the things I didn't get round to doing
>> while working on openmoko-messages2/phonekit/etc. It'd be good if there
>> was a small static library for handling phone-number normalisation, so
>> this code isn't reimplemented in different ways all over the place.
> 
> Some code is already present in my patches. Remaining issue with the
> normalization is that currently, the country prefix (+49) is hardcoded.
> I see two possibilities:
> 
> * Every user of this code needs to figure out what prefix to use.
> * We never do normalization, but only provide a comparison function (and
> a hash function compatible with this comparison). This way, we never
> choose the “wrong” prefix, but we might match a non-fully-qualified
> number to a equal looking number in a different country (a very rare
> case, IMHO).
> 
>> With regards to how this should be done with eds-dbus, there are a
>> number of ways to go about it... A feasible way would be to store the
>> normalised number primarily and the entered number as secondary/custom
>> field. When searching, search for the normalised number, then in the
>> case of multiple results, use some kind of heuristic to retrieve the
>> desired contact (or if you're lazy, just pick the first, the likelihood
>> of multiple matches is pretty low :))
> 
> Well, the main reason I want human readable numbers in eds is that it
> can be exactly the same data as on my laptop’s evolution, so this does
> not sound like a good idea.
> 
> Maybe adding a (match-number number1 number2) operator to the query
> s-exp parser in e-d-s is not too bad after all. It’s a local change that
> does not break anything that doesn’t use this feature, and then we could
> use the feature in libjana.
> 
> Do we currently use eds unmodified, or do we already have some patches?
> (I wouldn’t ask if I knew where to look :-)
> 
> 
>> All this code would go in the aforementioned static library, to be used
>> by any application that's attempting to handle storage/searching of
>> phone numbers.
> 
> Sounds sensible. I’d be interested in implementing this, but who should
> I then talk to when it comes to integrating the patches? And what code
> base should I make the changes again? (I’m new to Openmoko, and so far I
> haven’t found the equivalent of "apt-get source" in Debian, which gives
> me the exact source package for the current binary package :-))
> 
> 
> Greetings,
> Joachim
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> devel mailing list
> devel at lists.openmoko.org
> https://lists.openmoko.org/mailman/listinfo/devel


-- 
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.