seit kurzer Zeit gibt es den PhoneNumberValidator; ich habe das DE-Paket hinzugefügt.
Nun habe ich (für Deutschland) Bedenken hinsichtlich der Kennzeichnung von Telefon-Nebenstellen / Durchwahl-Nummern: Wir haben sehr häufig einen Bindestrich “Dash” als Trenner zwischen Stammnummer und Durchwahl; der Vaildator schlägt vor, den Bindestrich zu löschen, [siehe z.B. hier]( OSM Telefonnummern-Validierung Berich - Niederbayern ).
Im Wiki zum key phone finde ich dazu nichts, zum key contact:phone ist der Bindestrich explizit vorgegeben.
Warum dieser Unterschied?
Gibt es einen Unterschied zwischen Deutschland und anderen Ländern? Siehe hier: I see nothing in the English wiki or the German wiki about using a dash for extensions (or about extensions at all). There was a discussion about extensions a year back, which seemed to reach a conclusion that DIN format of a dash was not well supported in any other country and that either ext. or simply x was better, or even a comma. All of these (not the dash) work with the libphonenumber library that I use to parse numbers (see here). Dashes get ignored. Given that phone values are parsed by data consumers likely to use global libraries such as this, it doesn't seem good to have a format that does not work for them.
Wollen wir für Deutschland eine Kennzeichnung der Durchwahl? Wenn ja
mit Bindestrich -
mit einem anderen Zeichen, wenn ja, mit welchem?
Wollen wir (nur) das Durchwahl-Kennzeichen erhalten oder wollen wir ein fehlendes Durchwahl-Kennzeichen bevorzugt ergänzen: Quelle versus OSM?
Aus meiner Sicht sollten wir uns hier an die international akzeptierte Empfehlung E.123 der Internationalen Fernmeldeunion halten und nur Spaces zum visuellen Gruppieren nutzen.
Apropos, ich sehe gerade, dass eine signifikante Anzahl von “Fehlern” vom Type “Duplicate number” sind, wo also sowohl phone als auch contact:phone verwendet wurde. Das ist doch eigentlich kein Fehler, oder?
Weiterhin wird vorgeschlagen aus
phone
800 900 800
das zu machen:
+39 800 900 800
ich glaube aber, dass das nicht richtig wäre, weil es eine Kostenlosnummer ist, die nur im Inland und vermutlich auch nur ohne Länderpräfix funktioniert (da bin ich mir aber nicht sicher), ggf. auch nur aus bestimmten Netzen (also z.B. vielleicht nicht mit VoIP selbst wenn es eine italienische VoIP-Nummer ist).
Ansonsten bin ich begeistert, dass sie es geschafft haben, die Vorwahlnull zu behalten, weil das auch so sein muss in Italien, manche ISPs hatten mir da in der Vergangenheit schon die führende Null von italienischen Nummern automatisch entfernt weil sie dachten dass müsste so, und dann war die Nummer kaputt.
oder meistens gar nichts, das sind service Nummern die mutmaßlich in einem call center irgendwo rauskommen, nicht so selten auch im Ausland, aber in aller Regel keine individuellen Nummern für einen einzelnen POI.
Schade, dass es kein Interesse an dem Thema gibt. Um so größer ist mein Dank an @klik, dass zumindest Du zu meiner Frage geantwortet hast!
Für mich bedeutet der aktuelle Prozess der zur Löschung der Nebenstellen-Kennzeichnung durch PhoneNumberValidator einen erheblichen Informationsverlust; in diesem Zustand werde ich das Tool nicht weiter verwenden.
Erstmal danke das du die Deutschland dort eingebunden hast.
Aus meiner sicht ist aus der Diskusion hier auch relativ klar das die Beste option eine Eintragung ohne Zeichen neben [1..9] und + ist.
Ich habe mir das als Projekt vermerkt und werde mal ein bisschen daran arbeiten, oder mal schauen wie Optimierbar die Anpassungen in JOSM wären.
OSM ist auch unter den Aktiven Mappern (mmn.) eine 80-20 angelegenheit. Wenn du es der Horde an Mappern einfacher machst ermöglichst du weitreichende Verbesserungen; Danke.
Edit: Ich sehe ein das ein möglicher bindestrich zum notieren von Durchwahlen nötig ist
Es gibt hier allerdings auch noch die rfc3966 der IETF speziell 5.1.1 Separators in Phone Numbers und ggf. noch als Ergänzung bzgl. lokal und international 5.1.5 Local Numbers.
Die RFC widerspricht in 5.1.1 explizit der E.123 bzgl. der Verwendung von Leerzeichen.
Am Ende kommt es wieder auf die Frage an, machen wir das ganze für “Auswerter” (Fokus: nutzbar machen der Information, also eher RFC3966) oder für “Anzeige/Druck” (Fokus: lesbar machen der Information, also eher E.123). Von mir völlig wertfrei.
Im Wiki zu key phone steht die Referenz zu beiden unter “Anwendung” und lässt beide Schreibweisen zu. Beim key contact:phone ist explizit nur die E.123 herangezogen, enthält im Beispiel
”Telefon-Nr mit Durchwahl +49 721 123 456-78” aber entgegen der E.123-Empfehlung einen Bindestrich…
Warum das, sowohl im Wiki als auch in den Standards, wieder so unterschiedlich gehandhabt wird, Refrenzen und Beispiele nicht zusammenpassen etc., keine Ahnung, aber nicht hilfreich.
Mir was das zwar schon bekannt, aber ich hatte auch bereits die Abkürzung zum Fokus auf Lesbarkeit gemacht und deshalb die E.123 erwähnt.
Ja, genau das ist die zentrale Frage.
Wobei das enttfernen nicht zugelassener Zeichen für den Automaten einfacher ist als das hinzufügen
Und ja, wir sollten in unserem Wiki konsistent beschreiben welche Form wir warum nutzen wollen. Letztlich bin ich aber mit mit beiden Varianten fein, sie sollten ja international funktionieren.
Bei Unternehmen mit Telefonanlage werden die Durchwahlnummern nicht durch ein Leerzeichen abgetrennt.
Und als Beispiel:
Schreibweise
Typ
+49 801 12 34 56–0
Firma mit Telefonanlage (Zentrale)
Ich verwende deswegen durchweg - für Durchwahlen, weil es einen Mehrwert gegenüber einem simplen Space hat. Denn: Wenn niemand unter der Durchwahl erreichbar ist, kann ich immer noch die Zentrale unter der Durchwahl 0 erreichen. Ohne den Trenner für Durchwahlen, weiß ich nicht, dass das überhaupt möglich ist. Ich bin mir auch sicher, dass so ziemlich jede Software mit - umgehen kann, und sei es, dass alles, was nicht 0-9 oder + ist, ignoriert wird
Also: Ja, ich will den Bindestrich für Durchwahlen!
Wenn man mal in den Standard schaut steht da folgendes:
7.5 In-dialling
In the national and international number no symbol should be used to show that a subscriber number is an in-dialling number of a PBX. Where it is desired to indicate the existence of in-dialling within a PBX and to indicate the in-dialling access code the following format is recommended:
(0607) 123 …
(0607) 1 23 4…
The number of dots (periods) is equal to the number of digits in the extension number of the PBX.
The spacing between numbers and dots should conform to national standards.
On letterheads, subscribers could insert their own in-dialling numbers in the dotted spaces.
Presentation of the main listed number should conform to 2.3 above.
Zu Deutsch:
7.5 Nebenstellen
In nationalen und internationalen Rufnummern sollte kein Symbol verwendet werden, um anzuzeigen, dass es sich bei einer Teilnehmernummer um eine Durchwahl einer Nebenstellenanlage handelt. Wenn das Vorhandensein von Nebenstellen innerhalb einer Nebenstellenanlage und die Nebenstellennummer angegeben werden sollen, wird das folgende Format empfohlen:
(0607) 123 …
(0607) 1 23 4…
Die Anzahl der Punkte entspricht der Anzahl der Ziffern in der Nebenstellennummer der Nebenstellenanlage.
Der Abstand zwischen Zahlen und Punkten sollte den nationalen Normen entsprechen.
Auf Briefköpfen können Teilnehmer ihre eigenen Einwahlnummern in die gepunkteten Felder eintragen.
Die Darstellung der Hauptnummer sollte der oben genannten Nummer 2.3 entsprechen.
Das Problem ist ja genau an der Stelle wieder, dass (wenn ich nicht völlig falsch lese) die Abtrennung mit dem Bindestrich nach E.123 nicht zulässig ist. Siehe hier https://www.itu.int/rec/T-REC-E.123-200102-I/en im Dokument unter 7.5 In-Dialling.
In the national and international number no symbol should be used to show that a subscriber number is an in-dialling number of a PBX. Where it is desired to indicate the existence of in-dialling within a PBX and to indicate the in-dialling access code the following format is recommended:
(0607) 123 …
(0607) 1 23 4…
The number of dots (periods) is equal to the number of digits in the extension number of the PBX.
The spacing between numbers and dots should conform to national standards.
On letterheads, subscribers could insert their own in-dialling numbers in the dotted spaces.
Presentation of the main listed number should conform to 1.3 above.
Der Bindestrich kommt wieder aus der DIN5008 und da sind wir wieder bei der Deutschen Industrie Norm.
Da ist aus meiner Sicht sogar das Beispiel aus Wikipedia zur E.123 falsch.
Um ein bisschen zum Tool zurückzukommen um das es MichaelFS geht. Aus meiner Sicht sollten alle nicht rein national erreichbaren Nummern international eingetragen werden, kann das Tool anmeckern. Ansonsten gibt es dermaßen viele Standards und darauf basierende Formatierungen, dass das Tool nur den Konsens aus all diesen Standards anwenden sollte und wenn zu einigen oder den meisten Punkten (wie Leerzeichen) keiner besteht, gar keine Meinung dazu haben sollte. Es handelt sich schließlich um einen Validator und im Endeffekt sind dann alle diese Formen valide (je nach hinzugezogenem Standard).
As the author of the tool, I thought I would say that I am following this and I would like to see a solution that enables this to be a useful tool. It would be possible to consider a hyphen followed by one or two digits as an extension and not suggest changes to such numbers.
Or it would be possible to replace this with “ext.” which is suggested by English Wikipedia
The non-dialable PBX (private branch exchange) extension number should be separated by words “extension” or “ext.” in the national language after the phone number.
(formatting by me)
In Germany this is completely unknown, thanks to DIN 5008 – Wikipedia recommending the dash as separator. Because of that I don’t think that it’s making sense to replace the dash with ext. or something of this type.
Not replacing any hyphens would be very easy to implement.
This is a little trickier due to cases like this:+49-8463-9030. It seems like this is not an extension, so both of these hyphens should be spaces. Or even this+49 9123 - 97 67 0, is that the same as +49 9123 97670?
What I could do is this:
if number is German
and there is a hyphen
and everything before the last hyphen would be a 'valid' number
do not suggest a change to that hyphen
By valid, I mean with respect to libphonenumbers, which I am using to validate the phone numbers, see here to test it out and see what is considered valid.
Yes, in the first case the first hyphen would be separate the country code from the “number in the country” and the second one would separate the division part of the local part, in the second example only the division part of the local part.
Both cases without extension.
I’m not a specialist but I think that the division part in Germany will be between two and four digits, i.e. 30 or (030) for Berlin, 681 or (0681) for the city of Saarbrücken and 6857 or (06857) for the village of Namborn - divisions often not the same as the admin_border …
Thank you for the replies. For Germany this is really an issue as the majority of numbers critized by PhoneNumberValidator are numbers with extension, ref. f.e. here
Not to critize the last hyphen “Bindestrich” would be a perfect option but I would like to improve the rule provided from @confusedbuffalo, NOT
BUT:
if number is German
and there is a hyphen followed by one to four digits [00..9]
do not suggest a change to that hyphen, e.g. keep it
do suggest changes to the rest of the number as it is done actually
I went with a combination of the two approaches, due to elements like n309474928 with +49-8463-9030 as mentioned before.
This has brought down the number of ‘invalid’ numbers from ~52700 to ~35500 and from looking at the suggestions, I think the remaining suggestions are reasonable. But please take a look and let me know if you see any more issues:
I have just seen that I did not consider that there could be spaces around the hyphen for an extension, but I have fixed that and it will be live in tomorrow’s run.
Looks very good, but we have overlooked some edge cases:
+49 6841 16-26008 is not wrong and shouldn’t be changed-
Therefor instead of
it should be
if number is German
and there is a hyphen followed by one to five digits [00..9]
do not suggest a change to that hyphen, e.g. keep it
do suggest changes to the rest of the number as it is done actually
Telephon numbers with a leading 0800 can only be called from Germany - as @dieterdreist suggested - not from a foreign country. Because of that numbers like
