tel: link is improperly formatted

I'm reading http://www.ietf.org/rfc/rfc2806.txt and seeing that use of characters like 'w' or 'p' are acceptable as wait or pause characters. We should probably remove all non alpha-numeric characters? Do we strip out the plus sign or not for international?

the "+" char has meaning when it is not the first char (at least on iOS and Android) ... it means "wait for user input". Ex. 5555555555+123 will dial then number and then add a "Dial 123" button to the keypad screen

The comma means wait 2 seconds before continuing

As far as I can tell the "#" and "*" have no meaning, but they should not be removed because of things like conference numbers and voicemails. They are valid.

re #2 this is a slightly new version of the standard you referenced: http://tools.ietf.org/html/rfc3966#section-5.3 ... still old (circa 2004) but I cant find anything better.

That said, according to this the pause chars have been removed. However, since both android & ios support "+" and "," I think we should keep them. I'm working on an issue for html5_tools here: https://durpal.org/node/2062619 and plan to keep those characters in that issue FWIW.

@hass Converting + to 00 is a bad idea as not all countries use 00 as the international access code. The reason cellphone companies came up with the + as the international access code is so people would not need to figure out what country they were calling from and then figure out what access code to use.

However, since both android & ios support "+" and "," I think we should keep them

Is there anything left to be done here?

Wrote a test that checks if telephone numbers are properly formatted in the href attribute. This patch should fail.

Maybe would be an idea to use this library giggsey/libphonenumber-for-php for validating/formatting a phone number? It's a PHP port of Google's library for parsing, formatting, and validating international phone numbers.

I like the idea of using giggsey/libphonenumber-for-php. It is able to handle whatever local format people enter their number in, and convert it to a standard format. It also opens the door for some awesome future additions to the Phone module.

Should we create a #telephone form field herefore?

Isn't there already a form element #tel?

1. We already have #tel form element in place
2. I'm all into having giggsey/libphonenumber-for-php in root composer.json. Contrib modules already use it to provide validation to telephone field. We could use it for proper formatting, but we must first store it in right way.
3. I suggest creating separate issue for adding giggsey/libphonenumber-for-php to drupal core and make this one and similar issues be postponed by that one.

We don't haphazardly add dependencies to core so that future issues can use it. I think we should probably make a contrib module with an example implementation first which can later be considered for inclusion in core.
I have an example of a really simple libphonenumber based field here: https://www.drupal.org/project/libphonenumber

1. Bumping core version.

2. I created telephone_formatter module which adds extra telephone field formatter to core's telephone field and, by using giggsey/libphonenumber-for-php, formats the link using E164 format. If number cannot be parsed by giggsey/libphonenumber-for-php it displays fallback raw, unformatted value.
I believe we could use the same approach in core.

Can we bring https://www.drupal.org/project/telephone_formatter and https://www.drupal.org/project/telephone_validation which provide clean solutions to this into core, as part of core support for the telephone field rather than separate modules?

would agree that maybe bringing in those two modules would be good for this module.

Know this is a super old ticket and just volunteered to help keep an eye on the telephone module so going

So brought this up in slack a month ago in the #contribute channel with dpi and borisson_

Per dpi

validation should be left to contrib as local formats differ by country, subregion, even cultural preference.

I will agree on that so don't think telephone_validation could belong in core.

The libphonenumber dep is the right tool for the job. but it is so massive, and updated too often, I don’t think it belongs in core

It probably would be better to keep separate so updates can happen more often.

imo the best core should do is spit out E164, plus symbol and a string of unseparated digits. and ensure contrib can hook in properly at every opportunity

So think we can open a followup for that last quote but the rest seems to be a won't fix status.

Putting into PNMI for more thoughts.

If still a valid bug please reopen addressing my comment in #36