We have moved to a new Sailfish OS Forum. Please start new discussions there.

Contacts: Allow special characters (space, dash, etc) and text in phone numbers for readability [duplicate]

asked 2014-02-07 04:58:45 +0300

00prometheus gravatar image

updated 2014-07-12 03:00:49 +0300

simo gravatar image

I have a number of contacts that have survived from my old Sony-Ericsson p800. One feature of the contacts app in that phone was the ability to write whatever you liked in the phone number. So instead of numbers like (number is fake):


you could write something like:

+46 (734) 72-92-123 (Parents home)

Much easier to read and understand! The phone app would simply ignore all characters, except +, 0-9, *, # and p. Any 'p' that occurred after the number has no effect, so that doesn't matter anyway. The ability to write free-form text in the number helps a lot to remember what is what for people with many numbers. It isn't uncommon to have more than one personal mobile, or several home numbers!

There used to be a Nokia phone, where the labels themselves could be altered (i.e. the work/home/mobile labels). Unfortunately, that information was lost when those contacts were imported to other phones, since the labels were non-standard, so I don't recommend that solution. However, simply having some free-form text in addition to the phone number has survived through all my phones since the Sony-Ericsson p800 (which some would argue is the first real smartphone!)

[Edit, Clarification]: The contacts app already allows importing contacts that have full free-form text in the number fields (just like all other contact apps I have used), and those contacts can be used to dial without problems. This is about allowing users to enter new numbers with text, and edit the ones that are already there, i.e.: To have some way to enable full keyboard when editing a phone number.

edit retag flag offensive reopen delete

The question has been closed for the following reason "duplicate question" by Tanghus
close date 2014-02-08 20:55:54.181407


Yes, that's definitely needed (at least spaces). No matter how to do it, it works fine on other phones and should with the Jolla, too. Thanks!

Deonith ( 2014-02-07 13:26:13 +0300 )edit

Absolutely a duplicate of https://together.jolla.com/question/19062/let-me-type-dashes-and-spaces-when-editing-the-phone-number-in-people/ Please cast your votes on that instead

Tanghus ( 2014-02-08 20:55:16 +0300 )edit

Not quite the same. https://together.jolla.com/question/19062/let-me-type-dashes-and-spaces-when-editing-the-phone-number-in-people/ asks for visible separators only, while this here asks additionally for textual comments inside the number field.

Stefanix ( 2014-02-09 04:08:23 +0300 )edit

For that you could use e.g. Apples (non-standard) AB-Label. Adding text in a phone number is ludicrous.

Tanghus ( 2014-02-09 04:29:31 +0300 )edit

I acknowledge that it is useful to be able to distinguish different phone numbers of a contact beyond predefined labels. I tried to paste "1234ABC" into a phone number field of a Lumia (WP8). It was possible and only 1234 was dialled. Seems to work. Still, I think that's not the purpose of this field and I am not sure if this will lead to some problems with some apps or backup storage.

Stefanix ( 2014-02-09 08:43:35 +0300 )edit

3 Answers

Sort by » oldest newest most voted

answered 2014-02-07 09:05:58 +0300

Stefanix gravatar image

updated 2014-02-07 09:09:08 +0300

Follow standards and avoid compatibility problems

The number format should comply to standards defining the storage and exchange of tel records. vCard 4.0 actually allows free form text strings: http://tools.ietf.org/search/rfc6350#section-6.4.1 But this is a concession for v3.0 backwards compatibility. It SHOULD follow the Tel uri scheme defined in http://tools.ietf.org/html/rfc3966#section-5.1 Visual separators are allowed, but no text comments as part of the tel uri. I think dashes are quite useful to structure the number and are present in some phone books, I never saw parentheses. My opinion is that dashes should be supported, but for the sake of compatibility nothing else (of course "+" for international numbers as well).

edit flag offensive delete publish link more


I certainly agree that we should follow standards, however the question is primarily about what the contacts app does internally, not about what gets exported to vCards. It is possible to strip all comments when exporting if you like. However there is an obvious de facto standard about allowing free-form text in exported contact phone numbers, and it is also an extremely useful feature, so I would also like to see it in the Jolla.

00prometheus ( 2014-02-07 15:11:00 +0300 )edit

My contacts should be portable. We can do a lot internally. But ideally I would like to see the same number format if I export my contacts and import them again. The number fields should also be usable as dial strings and digestible for other apps without much effort.

Stefanix ( 2014-02-07 15:26:49 +0300 )edit

When sending the dial-string to an application, it can simply be stripped first of everything but numbers (and other dialing-characters).

Importing dial-strings with text already works fine.

As you say contacts should ideally be the same also after exporting. Perhaps let the user choose if extra information in the dial-strings should be stripped or not when exporting. As I mentioned, all phone books I have used since the p800 have been able to handle my p800 dial-strings with text, so it is probably not a big issue.

00prometheus ( 2014-02-07 16:17:51 +0300 )edit

answered 2014-02-07 09:19:25 +0300

norguhtar gravatar image

updated 2014-02-07 09:46:49 +0300

It's not need. I think better create output number formatter. You put phone in this format +467347292123 going to settings and change output number format to

+xx (xxx) xx xx xxx

or just put separator for example - apply it. And get number in contract

+46 (734) 72 92 123

edit flag offensive delete publish link more


I think this could be a good alternative. Especially it makes existing numbers without separators more readable. But a meaningful implementation is a bit more complex. Country codes and national destination codes are of different lengths. To maintain a list of country codes is not that difficult. But then there can be one to five digit NDCs. Ideally they would be separated into a group. Not impossible, but quite a job. Only the US numbering pan is super simple (+1-xxx-yyy-zzzz).

Stefanix ( 2014-02-07 09:43:28 +0300 )edit

I think this this is a bad idea.

Not all countries have the same number of digits, nor format their numbers in the same way.

For example, french numbers are formatted:

+33 x xx xx xx xx

And most people write the numbers replacing the international code for France by a 0 (that’s what you dial when calling a french number from France), so there is no way to guess it is a french number.

I think the suggestion of original poster is more flexible, and better.

vbregier ( 2014-02-07 12:31:41 +0300 )edit

Auto formating is probably possible, but it would require quite a bit of research to do the formating right for every country code and operator within that country. Also, sometimes people format their numbers in a special way to emphasize special patterns in the number (like 8 3333 567), that would be lost with auto formating.

But I agree with norguhtar, for numbers that the user hasn't formated themselves, it would be nice with some automatic formating.

00prometheus ( 2014-02-07 15:00:04 +0300 )edit

answered 2014-02-07 12:44:15 +0300

norguhtar gravatar image

I think better idea use for output format two lists. First predefined and second configurable. If you need you can edit second. Of course second list got big priority than first.

Other solution we can save two fields first user input (it show user in contacts) and second saved number after normalisation.

edit flag offensive delete publish link more


The possibility to use spaces would be enough for me.

MichaelSD ( 2014-06-14 16:10:00 +0300 )edit

Question tools

1 follower


Asked: 2014-02-07 04:58:45 +0300

Seen: 3,433 times

Last updated: Feb 07 '14