Opened 14 years ago

Closed 12 years ago

Last modified 10 years ago

#313 closed defect (wontfix)

PhoneNumberField should accept international format numbers

Reported by: ronan@… Owned by: Adrian Holovaty
Component: Internationalization Version: 1.0
Severity: minor Keywords: phonenumberfield
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no




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.

Change History (13)

comment:1 Changed 14 years ago by Adrian Holovaty

milestone: Version 1.0

comment:2 Changed 14 years ago by 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

comment:3 Changed 14 years ago by 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.

comment:4 Changed 14 years ago by 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!

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by 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.) ;-)

comment:7 Changed 14 years ago by Adrian Holovaty

Resolution: wontfix
Status: newclosed

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.)

comment:8 Changed 12 years ago by anonymous

Component: MetasystemInternationalization
Summary: PhoneNumberField should accept international format numbers78127016460

comment:9 Changed 12 years ago by Gary Wilson <gary.wilson@…>

Summary: 78127016460PhoneNumberField should accept international format numbers

comment:10 in reply to:  8 Changed 12 years ago by anony mous

Resolution: wontfix
Status: closedreopened

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.

comment:11 Changed 12 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: reopenedclosed

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.

comment:12 Changed 11 years ago by 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.

comment:13 Changed 10 years ago by 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.

Note: See TracTickets for help on using tickets.
Back to Top