[i18n] phone numbers are displayed using US numbering scheme

[solsticedhiver]

Using GSConnect (V15 I guess), I synchronised my contacts from my phone.

Then when I do a search for a contact before sending a message (SMS), all the phone numbers are displayed using what seems to be US numbering scheme like 123-123-1234

I guess you could use the locale of the system where GSConnect is installed to displayed phone number according to the country locale custom ?

I don't know if it's defined anywhere, meaning if the phone number scheme format is part on any locale scheme. But you can create one ?

For the record, here it is something like 01.23.45.67.89 or the internaltionnal form is +33123456789

[andyholmes]

When contacts are synced from the phone, we are send contacts in VCard format and just parse the information we are given. Since GSConnect doesn't do any localized formatting of phone numbers, I would guess that it is either Android doing it, or maybe it's just that the VCard 2.1 format (which is a bit old) only had support for North American phone numbers.

Unfortunately, phone numbers are a very complex topic with many variations, so it's unlikely we can fix this on our end. I've filed an upstream bug report so we can track it, but it will probably be a low-priority:

https://bugs.kde.org/show_bug.cgi?id=401208

[solsticedhiver]

I understand

It was a moto G 5 with android 7.1.something upgraded to 8.1 recently.

[sredman]

@andyholmes Do you dump the vcard files to disk or do you just parse them on the fly? Upstream, we cache to disk. My experience is that the vcards come from Android in the same format as I have them written in the Contacts. For example, I have some Croatian phone numbers (12 digits) which are saved to disk as "+385xxxyyyzzz"

[sredman]

Actually, this seems to be (Android) version-dependent. I have this .vcf files from my old phone (v8.0.1) which are as above, the .vcf for the same contact from my new phone (v9.0) where it has inserted spaces (+385 xx xyy yzzz)

[ferdnyc]

or maybe it's just that the VCard 2.1 format (which is a bit old) only had support for North American phone numbers.

That's definitely not the case — even way back in 1996 the original VCard 2.1 spec (Word doc) defined the TEL field as a free-form text string...

specified in a canonical form in order to specify an unambiguous representation of the globally unique telephony endpoint. This property is based on the X.520 Telephone Number attribute.

They went on to further defer to Apple and Microsoft's Telephony suites for the canonical digital representations of these strings. Microsoft TAPI in particular was based on ITU E.123 with the addition of parentheses for optional components (like the area code, back when most of the US was still doing 7-digit dialing).

But E.123 allows all sorts of locally-accepted formats, subject to a few guidelines:

In the international telephone number notation, the leading plus (+) serves as an international prefix symbol, and is immediately followed by the country code. The user or the telephone system should replace the + symbol with international dialing prefix used in the caller's location.

Parentheses are used in national notation to indicate digits that are sometimes not dialed, such as area code in variable-length dialing numbering plans. Parentheses are not allowed in the international notation, according to the standard, as international callers use fixed number dialing.

For digit grouping, E.123 specifically recommends that:

• only spaces be used to visually separate groups of numbers "unless an agreed upon explicit symbol (e.g. hyphen) is necessary for procedural purposes" in national notation;
• only spaces should be used to visually separate groups of numbers in international notation;
• spaces should separate country code, area code and local number.

No recommendation is made for grouping rules for digits in the local number, instead some examples of commonly used groupings are shown.

The problem is more that the field was/is too flexible, it gives implementers a lot of room to decide for themselves how to format number strings. Which is why they're still changing their formatting on a whim, even though you'd think by Android 8.0 they would've locked down how to format a freakin' telephone number by now.

(Why, yes, my first job out of college was at an America OnLine subsidiary, working on "project BigDial" — the worldwide network of 350,000 modem ports that allowed anyone in the late 1990s to dial in to AOL as a local call, and camp out for hours or days at a time with no toll charges... ... ... why do you ask? 🤔 )

[andyholmes]

Going to close this one up as I believe it's an issue with Android's VCard export.

In any case, there's nothing we do to correct the information we're provided; we can only use it as it's given to us.