Add DEPhoneNumberField to German localflavor module

[Jannis Leidel]

This ticket tries to add a DEPhoneNumberField class to the German localflavor module.

There are several valid standards in Germany: DIN 5008, E.123 and an informal format which have national and international notations.

More information: ​http://de.wikipedia.org/wiki/Rufnummer#Schreibweisen

[Jannis Leidel]

Added DEPhoneNumberField to German localflavor

[Julian Bez]

I think it's bad usability to have something like

>>> f.clean('+49 (030) 1234567') 
Traceback (most recent call last): 
... 
ValidationError: [u'Enter the phone number in a supported format: DIN 5008, E.123, Microsoft/TAPI.'] 

After all, you can easily bring the number in the right format. There is no need get the user to conform to specific formats.

[Jannis Leidel]

I don't agree. This phone field validates the input against certain formats, just like every other phone field in localflavor. The example you choose is clearly in violation of the usual business standards in Germany and Austria and therefore invalid. Since there are specific standards we should use them.

[Malcolm Tredinnick]

@jezdez: come on. That error message is not at all appropriate or useful. If your grandmother was using the web and saw that whilst trying to enter her phone number to purchase flowers would she really have a clue what you were talking about? Also keep in mind that that error message is not just going to be shown to Germans, even if you happen to be taught in school what the DIN 5008 format is, so it rapidly becomes even less informative. Error messages are viewed by website users -- even I would have to go and look up wikipedia to find out what the right format if I saw that error on a website.

What you're calling the "informal" standard has to be supported, so just give a couple of examples of things like that in error (e.g. "555123456", "555-123-456", etc) People are very good at following patterns when they know what to expect and allowing "no pattern at all" (the informal case) makes it even easier so there should not be much requirement for an error message beyond something like "please enter a phone number. Remember all German phone numbers are prime numbers with between 21 and 37 digits".

[Jannis Leidel]

Replying to mtredinnick:

Hrm, I see your point of overthinking validation of user input. And yes, if that user would be my grandma, she would wonder what the hell is meant by DIN5008. I could change the error message to a more polite message, if you want.

But the other question is if validation is supposed to handle not only the "official" standards but any other potential phone numbers as well -- so why having such fields in the first place? I don't mean to start a standard flame war though, I just thought the more accurate the better when I wrote DEPhoneNumberField.

The "informal" standard I was mentioning is widely used in Germany and Austria and is the only notation that does not come from strict German norm (yeah, there are such things).

So for example: +49 30 12345-67 is correct following DIN5008 while +49 (0)30 12345-67 is incorrect, although everybody uses it. I just made that crazy regular expression tolerant to that deviation.

But again, I won't stand in the way if you want to get rid of that monster, I'm not a fan of nitpicking :)

[Malcolm Tredinnick]

Keep in mind what the idea behind these sorts of fields are: if you are expecting a German phone number and it must be a German phone number, then it should be possible to validate that. Which often means just checking the number of digits (that varies from country to country). It would also be reasonable to check for a leading, optional, "+49", possibly followed by a "0" (again optional, if +49 was there), if you want to go that far. If you throw out all punctuation and spaces and then did that, you could normalise the number to something that started with a 0, didn't have +49 at the front and was hyphenated however you like. More than that would be a little optimistic, but at that point all of the formats you currently accept will still be acceptable (as you note, people commonly write ", +49 (0)...", which doesn't meet any official standards except the most important one of all: people use that in normal everyday life). So don't throw out the baby along with the bathwater here. Certainly allow all these nicely specified formats. But also allow people who just want to write down the phone number in a commonly used way.

The idea is to "be liberal in what you accept" and then normalise it to a standard form for later processing. The UK postcode field is a pretty good example of this (read the changelogs for that file in subversion sometime).

Also, I'm now holding you to the higher standard of "must be usable by your grandma.". Future patches on this ticket may require a signed note from her saying that she approves.

[Julien Phalip]

Patch needs improvement as per the dicussion above. Tests also need to be rewritten using unittest.

[Sebastian Goll]

I just added another alternative patch for the DEPhoneNumberField implementation. It is a complete rewrite of the original (3 years ago), trying to keep in mind all the aspects outlined in comment:6. Thus, the accepted range of inputs is rather broad, while aiming for sensible normalization.

Please let me know if this patch requires further work.

[Aymeric Augustin]

Revert spam.

[Sebastian Goll]

Here is an updated version of the patch. Nothing really changed, but it now applies to trunk as of r17372. If somebody could review this, so that it could make its way into Django 1.4, or alternatively raise some concerns as to why it should not, it'd be much appreciated. Thanks!

[Aymeric Augustin]

django.contrib.localflavor is now deprecated — see ​https://docs.djangoproject.com/en/dev/ref/contrib/localflavor/

A repository was created for each localflavor at ​https://github.com/django/django-localflavor-? (Replace with the country code.)

If you're still interested in this ticket, could you create a pull request on that repository?

Sorry for not resolving this issue earlier, and thanks for your input!