Faker.Phone API about faker HOT 7 OPEN

I thinking about API for phones, here is my thoughts:

• number/0 as general entry for mobile/landline numbers;
• cell_number/0 & mobile_number/0;
• landline_number/0;
• area_code/0
• exchange_code/0
• subscriber_number/0
• extension/0

I think that seems sensible.

I prefer to use Faker.format/1 there it is possible, because ideas of faker is to provide wide range of real world data (see Russian example below), so phone numbers is not just sequence of number and rules, but also style of formatting.

The problem is that in order for UK phone numbers to be truely valid, they actually follow quite a specific pattern (See here for more info - parts of the number denote different areas of the UK, prefixes define different types of phone number, they can have different lengths depending on the type of number, etc etc).

Because of this, Faker.format/1 has limited use. What we can use it for, is filling in the blanks after we choose a number format "template", such as in your example.

It might be worth noting, I've begun maintaining a project called elibphonenumber, which is an Erlang NIF wrapper of libphonenumber - a phone number parsing, validation & formatting library written by Google.

We could potentially use elibphonenumber to:

• Produce different formatted outputs (national phone number style, international style, e164, RFC3966, etc).
• Parse example phone numbers, then return the numbers chunked into their parts
• Retrieve the expected cost to call the number
• Probably lots more

If we go down the elibphonenumber route, we can do this across many locales automatically.

Thoughts?

from faker.

I would love to see a phone number module!

Hmm I just saw this after I posted: https://github.com/igas/faker/blob/master/lib/faker/phone/en_us.ex

Perhaps the README file just needed to be updated.

from faker.

Hey @igas @johnhamelink,

I spent some time reading/investigating about telephone numbers and came across E.164 which basically states that a phone number consists of mainly three parts:

• Country Code (equivalent to area code I guess)
• National Destination Code (equivalent to exchange code I guess)
• Subscriber Number
  Subscriber Number and National Destination Code make up what's called the Significant number.

According to what I described above, I was thinking if it would be a good approach to have a separation of concerns here: the generation of the phone number in one side (without any specific format, just the sequence of digits) and have an extra set of rules to actually format the phone number according to the locale, because as @johnhamelink mentioned in the previous comment, in the UK phones are valid only if they follow a specific pattern, which might also be the case for all other countries.

I'm by no means a telephone number expert 😁 just was dropping my suggestion here; let me know what you think!

from faker.

well, we want to make it right, and I think first we need to do before it, decide how we'll manage langs and locales. Like en_UK & en_US. it should on one hand work with all ens but also pick US/UK when available. Sadly I don't have enough time to do that 😞

from faker.

Having the E.164 format would be awesome. Anytime you use a calling service (i.e. Twilio) you need to use this format. It's a pretty common use case.

from faker.

@igas do you have any interest in E.164 numbers? I'd be happy to submit a PR when I get a chance.

from faker.

Hi @anthonator I'm not very familiar with this standard, but I would be happy to look at it, we can always prefix it if we decide not to make it default one. PR is welcome.

from faker.