Re: Normalizing Phone Number entry with libphonenumber

[Lara Rennie]

Hey,

Just some thoughts on what you're trying to do here.

* First of all, you shouldn't ask people for their area code separately from their main number. If you need to calculate it for legacy American-designed backends, you can do this later on the server side.

* You can try and validate your numbers when people are signing up, to check they are an appropriate length: that would consider the second number in your example to be invalid since it's too short. Note if you do this you want to make sure you are keeping up-to-date with metadata changes. If you want to do it afterwards, you are going to have to write more complex logic, and really, you shouldn't be fixing your user's numbers silently - you should be getting them to fix them instead.

* You probably shouldn't strip the dashes on the client side; the library will do this when parsing, but it uses punctuation to help it know how to correctly parse something. Dashes are usually harmless but not always.

* Maxlength of 12 is too small for international phone numbers for the "phone" value.

* A drop-down for country code with the name of the country would be helpful; many people otherwise enter wrong country codes ... yes, I know.... 

Lara

2013/7/12 Eddie Shipman <mrbase...@gmail.com>

I have these phone numbers being entered from our website with the entry fields below:

1-406-4331411-

1-928-445-4600

1-732-308-3868

1-252-886-1596

1-318-5378386-

1-570-6227200-130

1-505-8833683-

1-763-574-7447

{For Domestic-US customers)

&lt;label for="Phone" id="phonelabel"  class="required"&gt;Phone (AreaCode Number Extension)&lt;em&gt;*&lt;/em&gt;&lt;/label&gt;

&lt;input type="text" id="CountryCode" name="CountryCode" value="1" size="3"  maxlength="3"  class=" register_input hidden" /&gt;

&lt;input type="text" id="AreaCode"    name="AreaCode"    value=""  size="4"  maxlength="4"  class=" register_input" /&gt;

&lt;input type="text" id="Phone"       name="Phone"       value=""  size="12" maxlength="12" class="validate[required] register_input" /&gt;

&lt;input type="text" id="PhoneExt"    name="PhoneExt"    value=""  size="10" maxlength="10" class=" register_input" /&gt;

Note: When a country different than US is selected, the hidden class is removed from the CountryCode and the Label text is changed.

{For International customers)

&lt;label for="Phone" id="phonelabel"  class="required"&gt;Phone (CountryCode AreaCode Number Extension)&lt;em&gt;*&lt;/em&gt;&lt;/label&gt;

&lt;input type="text" id="CountryCode" name="CountryCode" value="" size="3"  maxlength="3"  class=" register_input" /&gt;

&lt;input type="text" id="AreaCode"    name="AreaCode"    value="" size="4"  maxlength="4"  class=" register_input" /&gt;

&lt;input type="text" id="Phone"       name="Phone"       value="" size="12" maxlength="12" class="validate[required] register_input" /&gt;

&lt;input type="text" id="PhoneExt"    name="PhoneExt"    value="" size="10" maxlength="10" class=" register_input" /&gt;

The dashes are stripped out of the Phone field before it is sent to our web service. Then the value is sent to our Oracle server which

inserts the data like this into our DB (using the first two numbers above as an example):

Field           #1      #2

--------------  ------- ----

COUNTRY_CODE_1: 1       1

AREA_CODE_1:    406     928

MAIN_PHONE:     4331411 445

EXTENSION_1             4600

That being said, it is apparent that our domestic customers are tabbing out of the Phone field and entering the last 4 digits of their phone number into the PhoneExt field.

How can libphonenumber help me to "normalize" these numbers and prevent this from happening? We will be using the C# port as our web service is written in C#.

--
You received this message because you are subscribed to the Google Groups "libphonenumber-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libphonenumber-di...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Eddie Shipman]

Those are some good recommendations. I like the idea of just skipping the CountryCode entry and defaulting it to the CC for the selected Country.

Most of the more current UI patterns for phone number entry allow for free form entry. I mean, I, too would like to let them enter it however they are accustomed to and store it in a single field, however, due to our "stringent" storage requirements, we really do have to get the "parts" as we now do. It's just when they screw up that we're screwed, too. 

Due to support for int'l numbers, we need to be able to parse the entry for storage keeping in mind the int'l formats. The MAIN_PHONE field is currently varchar(20) in our DB so we can increase the size of the Phone field to 20.

We've been looking at a jQuery masked input plugin for formatting phone numbers and would like to know if there is a list of int'll formats where we can build the masks for each country? This way, it would come over WITH the masked placeholders and then libphonenumber would be able to better parse it, do you think?

Also, someone on UIExchange had a good suggestion that we have a checkbox to allow them to enter an extension and show the field upon check, otherwise hide it.

[Lara Rennie]

Good idea with the checkbox and extension. On the other hand, if you don't have a separate box, and users prefix it with something like "ext." the parse function will handle it for you.

I don't know what you mean "masked input plugin"; do you mean you'd record the "-" but you wouldn't show it to users?

I'm also not sure why the storage requirements require breaking the number up into parts... but even if this is required, you can get the library to do the breaking up for you; it'll be more consistent and reliable than getting people to do it. You can parse the number, then format it in international format, and split on non-digits.

2013/7/12 Eddie Shipman <mrbase...@gmail.com>

[Mr. Baseball 34]

Does the library already break the number up into different parts? Or does it just format the parts to the string format for the locale?

--
You received this message because you are subscribed to a topic in the Google Groups "libphonenumber-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libphonenumber-discuss/5iS8p7yN4E4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libphonenumber-di...@googlegroups.com.

[Lara Rennie]

Breaking it up into different parts is the same as formatting, if you really want to break it up at all; area codes are always formatted together. (It depends why you're breaking up the number at all, but if you want to break it up for some reason, this is the best way to do it.)

2013/7/15 Mr. Baseball 34 <mrbase...@gmail.com>