PhoneNumberField should accept international format numbers

[ronan@…]

The

PhoneNumberField

type should really validate according to international phone number rules -- right now tha validation seems to be American (XXX-XXX-XXXX) I am not sure if there is any standard for this apart from the initial "+" to denote the country code.

[rdk]

My suggestion is to provide the possibility in localization of masking: eg.

• meta.PhoneNumberField(mask = None) ... gives no mask handling

• meta.PhoneNumberField(mask = en_US) ... gives USA mask handling

• meta.PhoneNumberField(mask = cs_CZ) ... gives Czech mask handling

[hugo]

Actually this is a bit more complicated: what about a system where there are users from all over the world? One might have the de format, the other the cs format, another one the en_US format. So I think this is more a case of "is PhoneField actually usefull at all"?

Maybe it should just be renamed to USPhoneField and all others should just stick to CharField with a MatchesRegularExpression validator in the validator_list to accomplish what they want, because I don't think that Django should gain knowledge about how phone numbers might look all over the world ;-)

Ok, international phone number handling should be accepted as an option. Or there should be an "International Phone Number" field - because those are used quite often and you can ask for international numbers from national nusers, too - just provide them the correct prefix as an default and give the right help_text so they know what to do.

[Valter]

I just wonder why phone number fields should be validated at all. Can you think of any real case where the stored phone number is used by a machine directly, without human intervention?

If the aim is to catch typos, well there are no checksums in phone numbers anyway, so there's really no point in extensive phone number format l10n, methinks.

So, web developers of the world, unite and use text fields for phone numbers!

[Adrian Holovaty]

"Can you think of any real case where the stored phone number is used by a machine directly, without human intervention?" -- Yeah, in the past I've written a template filter that converts a phone number from "XXX-XXX-XXXX" format to "(XXX) XXX-XXXX" format. Different people (and organizations) have different styles for displaying phone numbers, and, if phone numbers are stored consistently, then one can customize display depending on context.

[Tom Tobin <korpios@…>]

Another real-world case: autodialers. (Okay, so maybe it's a case we all loathe, in the instance of telemarketers and their ilk, but we should still keep it in mind.) ;-)

[Adrian Holovaty]

I'm closing this as a wontfix because it's out of the scope of Django to keep track of the various international phone formats. (See Hugo's comment.)

[anony mous]

Can you think of any real case where the stored phone number is used by a machine directly, without human intervention

Sure, e.g. sending SMS to phones, producing callto: URIs, ...

It sure it not Djangos scope to deal with various number formats. But that's exactly the reason to not support the US style but rather the international format which boils down to \+\d+ namely a leading "plus" sign with trailing numbers only. Like you enter them into your cellphone. And supporting that international style is what Hugo mentioned as well. Hence reopening the ticket and proposing to change it the way Hugo said:

Moving PhoneField to USPhoneField and introducing a PhoneField which works the above mentioned way.

[Malcolm Tredinnick]

Making this change would be quite disruptive at this point. We've now got localflavors for localised validation, plus it's very easy to just write your own validator and attach it to a CharField if you want that in your model.

Closing again, but it's really a moot point at this time. Requirements vary. Django's made one choice, but it's not restrictive, since it's so easy to use an alternative.

[David Cramer]

So I'm a bit late to the party. The whole notion that most core stuff in Django is US based is nice and all, but all of our projects tend to be international. They're international in the sense that it's not just a German site or a US site, so a localflavor doesn't quite cut it for us. I believe the defaults, should be international, that being, it should store it in an international format, and possibly include a USPhoneNumberField or something similar.

I'm going to write my own InternationalPhoneNumberField (as always), but I strongly disagree with the resolution.

[Ilya Semenov]

What a nice decision. Why would Django go Unicode then? They should have stick with ASCII strings as that's "enough" for the U.S.