Format of Phone numbers

[ecraven]

Is there a way to just enter phone numbers with separators in my own preferred format? There is just no way it would be possible for ebdb to actually know how to format phone numbers correctly (for example phone extension length is arbitrary), I'd much prefer if it just took whatever I entered (+1-23-45678-90) and showed that back to me. I don't think it is even possible to solve this problem in general, just like postcodes I think it is probably the best choice to just treat phone numbers as strings, not actually numbers (except maybe for the country code prefix).

[girzel]

You're right, there's no way to guess what the proper format should be, which is why there's the ebdb-i18n library! That asks you to enter the country before the number itself, which gives EBDB a fighting chance to display the number correctly.

The phone fields do store country code and area code prefixes as numbers, and the rest of the number as a string. It looks like, if you don't have ebdb-i18n loaded, it will break up seven-digit strings as XXX-XXXX, and eight digit strings as XXXX-XXXX, and call it good.

I suppose I could just do no formatting at all. What are you seeing now, and how would you rather it behaved?

[girzel]

Also, the routine for entering a new phone number discards anything that isn't a digit while it parses. So that would have to get changed as well (OTOH, that would make the code simpler).

[ecraven]

Hello ;)

You're right, there's no way to guess what the proper format should be, which is why there's the ebdb-i18n library! That asks you to enter the country before the number itself, which gives EBDB a fighting chance to display the number correctly.

Yea, I understand that, but this will not work in general, as there just is no correct way to generally format a phone number (even of one country).

For example, say a fictional company in germany has area code 123, number 45678, and an employee has extension 90. I want that to be shown as +49-123-45678-90. But another company might have +49-345-375-3452. Depending on the area code, numbers are a different length, and extensions are an arbitrary length anyway.

There just is no way of knowing how to display these "correctly".

The phone fields do store country code and area code prefixes as numbers, and the rest of the number as a string. It looks like, if you don't have ebdb-i18n loaded, it will break up seven-digit strings as XXX-XXXX, and eight digit strings as XXXX-XXXX, and call it good.

I am not in the US, this is definitely completely incorrect for most of the world's locations.

I suppose I could just do no formatting at all. What are you seeing now, and how would you rather it behaved?

My suggestion is to allow the following behaviour (or maybe make it the default / the only one, that is of course your call!):

• read phone numbers as strings, maybe filtering out everything but a few delimiters (defcustom allowed-delimiters " +-/()", or something similar).

• just display these numbers as-is, don't format them in any way.

It might be useful to have the automatic formatting for any string that does not contain any of the allowed-delimiters (except for the leading +), so users can decide, if they enter with delimiters, they'll get back what they entered, if they just enter +12345678, they'll get the automatic behaviour.

Thanks for discussing this! Greetings, Peter

[girzel]

On 05/11/20 12:27 PM, ecraven wrote:

Hello ;)

You're right, there's no way to guess what the proper format should be, which is why there's the ebdb-i18n library! That asks you to enter the country before the number itself, which gives EBDB a fighting chance to display the number correctly.

Yea, I understand that, but this will not work in general, as there just is no correct way to generally format a phone number (even of one country).

I think, for many countries, there is.

For example, say a fictional company in germany has area code 123, number 45678, and an employee has extension 90. I want that to be shown as +49-123-45678-90. But another company might have +49-345-375-3452. Depending on the area code, numbers are a different length, and extensions are an arbitrary length anyway.

There just is no way of knowing how to display these "correctly".

I guess this is what I was hoping for EBDB's internationalization libraries: that the base code would just do something dumb, and then the country-specific code in the relevant i18n package could go really deep into the long grass, if it wanted. People who weren't interested could just not load the various libraries. But if we wanted to get really, really obsessive over the correct way to handle display for a certain country, we could.

The phone fields do store country code and area code prefixes as numbers, and the rest of the number as a string. It looks like, if you don't have ebdb-i18n loaded, it will break up seven-digit strings as XXX-XXXX, and eight digit strings as XXXX-XXXX, and call it good.

I am not in the US, this is definitely completely incorrect for most of the world's locations.

No, I know it's incorrect, I think that was code that I wrote as a stopgap before I even made the i18n library.

I suppose I could just do no formatting at all. What are you seeing now, and how would you rather it behaved?

My suggestion is to allow the following behaviour (or maybe make it the default / the only one, that is of course your call!):

• read phone numbers as strings, maybe filtering out everything but a few delimiters (defcustom allowed-delimiters " +-/()", or something similar).

• just display these numbers as-is, don't format them in any way.

It might be useful to have the automatic formatting for any string that does not contain any of the allowed-delimiters (except for the leading +), so users can decide, if they enter with delimiters, they'll get back what they entered, if they just enter +12345678, they'll get the automatic behaviour.

That's not a bad idea -- if there's anything other than a digit in there, just don't try to do anything clever.

Thanks for discussing this!

My pleasure. It's good to have user feedback, otherwise I'm just sitting here making things up.