Currently the user input is sanitized to only plain text numbers.
For a better lisibility of the phone number, in most countries spacing is used. In Frnace there's one space every 2 characters. Formated phone number is like : +33 (0)1 00 00 00 00 ; (+33) 01 00 00 00 00 would be good too,
whereas phone number output is as follows : +33-0100000000
Is there a way grouping characters - i mean spaces " ", "(", ")" - could be added back before the phone number is displayed ?
To avoid the burden of a country based formatting, something like format phone number with a space every 2 characters or every 3 characters option ?
Or is there a Formatter (for Field API manage display and views) that does this ?
In the meantime I'll have a look at the D7 version of custom formatters http://drupal.org/project/custom_formatters to see if I can manage to create a formatter myself.
P.S. US formating (nnn) nnn-nnnn is well explained there: http://www.devx.com/getHelpOn/10MinuteSolution/20414
Comment | File | Size | Author |
---|---|---|---|
#12 | cck_phone_formatters-1133536-12.patch | 16.71 KB | dboulet |
#9 | phone_number_custom_formatter.txt | 715 bytes | Jerome F |
#7 | cck_phone_formatter.zip | 1.22 KB | NaX |
#6 | cck_phone_custom_formatter.png | 16.24 KB | NealB-1 |
Comments
Comment #1
ckngThis feature will be too site specific as everybody's requirement are different.
But it can be easily achieved by using jQuery, http://digitalbush.com/projects/masked-input-plugin/
There is a Drupal module for it also, http://drupal.org/project/masked_input
You should be able to customize based on your own need without much problem.
Comment #2
causalloop CreditAttribution: causalloop commentedI agree with jerome, I think this should be included. I mean +1-1234567890 is much harder to read than +1-123-456-7890. I don't really care whether it looks like 123-456-7890 or 123.456.7890 or (123) 456-7890, as long as there's some separation. I don't know jquery and the drupal module doesn't have a port for D7...
Comment #3
geerlingguy CreditAttribution: geerlingguy commentedI agree, too. It would be great if we could format phone numbers per-country. The quest for Pure Data™ is always a worthy one, but when it is done while sacrificing usability, I think usability should win...
It would be awesome if we could allow the user to put in anything that's a valid number, and have it displayed the way the user likes (or standardized, like xxx-xxx-xxxx or (xxx) xxx-xxxx, etc.).
Comment #4
Jerome F CreditAttribution: Jerome F commentedI posted a feature request about that in masked input module issue queue:
http://drupal.org/node/1226706
Comment #5
NealB-1 CreditAttribution: NealB-1 commentedIf I understand correctly, Jerome is talking about formatting/theming the output (whereas masked_input deals with input). There is support for country-specific output formatting, but it is currently broken in 7.x. I have a patch I've been working on to improve theming support, including the country-specific formats. I'm not quite ready to post it.
Comment #6
NealB-1 CreditAttribution: NealB-1 commentedHere's an example of how the custom formatter should look.
edit: This doesn't do a very good job with multi-value fields, but you get the picture.
Comment #7
NaX CreditAttribution: NaX commentedI have written a small CCK formatter module to handle this problem for me. It only handles 7 and 10 digit numbers.
EG: (xxx) xxx-xxxx or xxx-xxxx
I am sorry for the long theme function names I only noticed after most of the code was done what I did.
To use it once the module has been installed go to the "Display fields" for your content type and select one of the new formatter options for you phone fields.
I hope it helps, it works for me.
FYI, this is for 6.x tested on cck_phone-6.x-1.0
Comment #8
ckngSorry, didn't see it is referring to output.
@Kurmangazy, do you mind export your custom formatter as an example? Will include that into documentation.
For output, there are 2 ways
1) Override the theme functions in your template.php
theme_cck_phone_formatter_global_phone_number($element)
theme_cck_phone_formatter_local_phone_number($element)
theme_phone_number_extension($element = '')
2) Custom formatter, as suggested by Kurmangazy
As for input, wanting to help port masked_input for D7, started some time ago but couldn't find the time to complete it yet.
Comment #9
Jerome F CreditAttribution: Jerome F commentedPlease find attached an export of the custom formatter Kurmangazy designed and which I reproduced.
It needs some enhancement though, as it doesn't seem to be completed.
Comment #10
dboulet CreditAttribution: dboulet commentedWhy don't we just fix the per-country formatters which are included in the module?
Comment #11
NealB-1 CreditAttribution: NealB-1 commentedI decided to create my own phone number formatters module that will be compatible with this one. I have gotten away from working on it for a while. I hope to pick back up on it soon.
Comment #12
dboulet CreditAttribution: dboulet commentedHere’s a quick fix so that we can at least make use of the country-specific formatters.
Comment #13
ckngAm marking this as closed as there is nothing need fixing.
To customize the phone number display, 2 options
1) Override the theme functions in your template.php
theme_cck_phone_formatter_global_phone_number($element)
theme_cck_phone_formatter_local_phone_number($element)
theme_phone_number_extension($element = '')
-OR-
2) Custom formatters
Comment #14
dboulet CreditAttribution: dboulet commentedckng, please reconsider. Are you really going to force everyone to write a custom theme function of formatter every single time that they install the module? There are standard ways to format phone numbers, no reason to re-invent the wheel every time that the module is used.
Per-country default formatters at least provide sane defaults, and are especially helpful for people using stock themes or who can’t write PHP code.
Comment #15
ckngRef: http://en.wikipedia.org/wiki/Local_conventions_for_writing_telephone_num...
IMHO, there is no one-size-fit-all way to write a phone number. That's the reason behind the support for country level validator and formatter in the first place. The best way forward is to enrich country include file so it caters for each local convention.
A phone number separated by hyphen does not make sense to some countries, vice versa, the same goes for whitespace, dot, slash, bracket. Not to mention the number grouping makes a huge different.
Comment #16
dboulet CreditAttribution: dboulet commentedThat’s exactly what I was trying to accomplish with my patch in #12.
Comment #17
geerlingguy CreditAttribution: geerlingguy commentedThe patch in #12 does look like a pretty good start, conceptually. We could add in more formatters as include files as time progresses... If we had at least the US, UK, and a few other countries where Drupal is more popular, that would be a good example of 'serving the 80%', and we might also inspire other countries to be able to add their own formatters. A win in my book...
Comment #18
ckngThe problem of country specific local/global formatter not called has been fixed per 57401f2 in #1115066: Country formatter not called.
Comment #19
dboulet CreditAttribution: dboulet commentedSo looks like the patch will have to be re-rolled then?
Comment #20
ckngNo, what your patch trying to solve is already fixed in the dev. =)
Comment #21
dboulet CreditAttribution: dboulet commentedYes but there was a lot more in the patch than what was applied in the commit mentioned in #18. We should re-roll it minus the changes that have already been applied.
Comment #22
ckngPardon me but I could not see any different in patch #12 compare to the current dev, after going through it for the forth times, except
- in passing the variables and variable names, which the dev version is more flexible for future expansion
- replacing whitespace with hyphen in US formatter, which not plan to change as it may interfere with existing sites
Comment #23
NealB-1 CreditAttribution: NealB-1 commentedI have a sandbox project here that implements a solution to the country-specific formatter problem. The concept is this:
Phone number formats are specified in a simplified regex-like format, e.g.:
(...) ...-....
Dots match any digit. Characters like dash (-) are copied through unchanged.
Digits have to match themselves. So this only matches 1-800 numbers:
1-800-...-....
You can also use digit ranges and sets as a shorthand. You specify these with square brackets, as in regular expressions, so
1-[89]00-...-....
matches 1-800 and 1-900 numbers.
All of this already works in the sandbox project. There is a basic admin form where you can configure your own patterns. And there is a textfield widget that matches the patterns and fills in the extra characters magically while you type. I think it is pretty much ready for production use, if it has all the features you need.
If you like the concept, please leave some feedback in the issue queue. There is still work that needs to be done. For one thing, I want to change the wildcard character to % instead of period, since periods could potentially be desirable in a phone number format. I am busy with work and I don't expect to have a lot of time to spend on it. I would be open to integrating it into ckng's Phone Number module, especially if ckng would take over some of the development (hint).
It looks like snapshots are not working on drupal.org (at least they don't work for me), so here's a snapshot tarball.
Comment #24
ckngThanks NealB, your solution is more towards what I've in mind for #1085008: A Country Code for Toll Free Numbers, support for a custom phone number, but perhaps using preg_match regex format directly.
Will check out your code when I've the free time, and see what I can grab =)
Comment #25
NealB-1 CreditAttribution: NealB-1 commentedCool. Let me know what I can do to help.
Comment #26
g1smd CreditAttribution: g1smd commentedI'm the UK metadata editor for the Google libphonenumber project over at:
http://code.google.com/p/libphonenumber/
The xml metadata file there has number length, validation and formatting information as well as an example number for each number type in each country.
Perhaps you could use this data here?
Comment #27
ckngThanks @g1smd, definitely something useful. Too bad there is no PHP version?
Well, we can consider contributing one for PHP
Comment #28
g1smd CreditAttribution: g1smd commentedThere is an unofficial PHP port. :-)
I am maintaining an unofficial list of ports here:
http://aa-asterisk.org.uk/index.php/Libphonenumber#libphonenumber
Comment #29
ckngLet's move the libphonenumber discussion to #1675778: Port to use libphonenumber
Comment #30
g1smd CreditAttribution: g1smd commentedYes. Good idea. I'll follow the other thread.
@OP
> Formatted phone number is like : +33 (0)1 00 00 00 00
The (0) format is dangerous and should never be used. The number is not valid to dial like that.
The only valid display formats are:
+33100000000 - E.164 - should be used for storage.
+33 1 00 00 00 00 - International format for display.
01 00 00 00 00 or (01) 00 00 00 00 - National format for display.
These articles have more detail:
http://www.aa-asterisk.org.uk/index.php/%280%29
http://revk.www.me.uk/2009/09/it-is-not-44-0207-123-4567.html
Comment #31
Todd Young CreditAttribution: Todd Young commentedIs this thread dead? I very much appreciate the module, but think it's a grave disservice to not complete it with formatting.
Sorry to wake the beast here, but I just don't see it useful to install the "first half" of the phone number solution.