Opened 10 years ago

Closed 7 years ago

Last modified 5 years ago

#313 closed defect (wontfix)

PhoneNumberField should accept international format numbers

Reported by: ronan@… Owned by: adrian
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: UI/UX:

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 Changed 10 years ago by adrian

  • milestone Version 1.0 deleted

comment:2 Changed 10 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 10 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 9 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 9 years ago by adrian

"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 9 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 9 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

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 follow-up: Changed 8 years ago by anonymous

  • Component changed from Metasystem to Internationalization
  • Summary changed from PhoneNumberField should accept international format numbers to 78127016460

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

  • Summary changed from 78127016460 to PhoneNumberField should accept international format numbers

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

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 7 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 7 years ago by dcramer

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 5 years ago by 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