Opened 19 years ago

Closed 17 years ago

Last modified 15 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

Description

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.

Change History (13)

comment:1 by Adrian Holovaty, 19 years ago

milestone: Version 1.0

comment:2 by rdk, 19 years ago

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 by hugo, 19 years ago

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 by Valter, 19 years ago

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 by Adrian Holovaty, 19 years ago

"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 by Tom Tobin <korpios@…>, 19 years ago

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 by Adrian Holovaty, 19 years ago

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 by anonymous, 17 years ago

Component: MetasystemInternationalization
Summary: PhoneNumberField should accept international format numbers78127016460

comment:9 by Gary Wilson <gary.wilson@…>, 17 years ago

Summary: 78127016460PhoneNumberField should accept international format numbers

in reply to:  8 comment:10 by anony mous, 17 years ago

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 by Malcolm Tredinnick, 17 years ago

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 by David Cramer, 16 years ago

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 by Ilya Semenov, 15 years ago

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