Code

Opened 6 years ago

Closed 21 months ago

#8798 closed New feature (invalid)

Add DEPhoneNumberField to German localflavor module

Reported by: jezdez Owned by: jezdez
Component: contrib.localflavor Version: master
Severity: Normal Keywords: locale, localflavor, german, phone, number, localflavorsplit
Cc: sebastian Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: yes

Description

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

Attachments (3)

ticket8798-r8849.diff (5.0 KB) - added by jezdez 6 years ago.
Added DEPhoneNumberField to German localflavor
r17015-dephonenumberfield.diff (6.0 KB) - added by sebastian 3 years ago.
8798-r17372-dephonenumberfield.diff (6.0 KB) - added by sebastian 2 years ago.

Download all attachments as: .zip

Change History (15)

Changed 6 years ago by jezdez

Added DEPhoneNumberField to German localflavor

comment:1 Changed 6 years ago by jezdez

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 6 years ago by julianb

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.

comment:3 Changed 6 years ago by jezdez

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.

comment:4 follow-up: Changed 6 years ago by mtredinnick

  • milestone post-1.0 deleted

@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".

comment:5 in reply to: ↑ 4 Changed 6 years ago by jezdez

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

comment:6 Changed 6 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to Accepted

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.

comment:7 Changed 3 years ago by julien

  • Patch needs improvement set
  • Severity set to Normal
  • Type set to Uncategorized

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

comment:8 Changed 3 years ago by julien

  • Type changed from Uncategorized to New feature

Changed 3 years ago by sebastian

comment:9 Changed 3 years ago by sebastian

  • Cc sebastian added
  • Easy pickings set
  • Patch needs improvement unset
  • UI/UX set

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.

comment:11 Changed 3 years ago by aaugustin

  • Status changed from new to reopened

Revert spam.

Changed 2 years ago by sebastian

comment:12 Changed 2 years ago by sebastian

  • Easy pickings unset
  • Keywords locale, localflavor, german, phone number added

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!

comment:13 Changed 21 months ago by aaugustin

  • Keywords phone, number, localflavorsplit added; phone number removed
  • Resolution set to invalid
  • Status changed from reopened to closed

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!

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.