Is there any thought being given to fix the number lists such that numbers are returned in their correct format even if input in the wrong format?


That is, if the database contains a number like  0207   2343456  to show it on the website like   020  7234  3456  instead?


Taking "British Gas" as an example, and just the 01/02/03 column, there are three numbers in the wrong format in the 'main database' list and at least a further 30 in the wrong format in the 'unverified' list.

In many cases, there is multiple repetition, with e.g. 023 8005 1003 potentially being listed again as 0238 0051003 and 0238 005 1003 and 0238 0051 003 and 02380 051003 and 02380 051 003 and 02380051003. In this case, only 023 8005 1003 is the correct format.




The UK numbering system is quite complex. Here's a quick summary:


Local numbers can be 6 or 7 or 8 digits long.

The code can be 4 or 3 or 2 digits long, after the initial zero.


The area code and number is 11 digits in total, including initial zero.

There are very few exceptions.




Depending on the area code, the numbers are formatted in a very specific way, but it is one that is fairly easy to remember:


Birmingham (0121), Edinburgh (0131), Glasgow (0141), Liverpool (0151), Manchester (0161), Tyne and Wear/County Durham (0191):

Numbers with area code like (01x1) are written:   (01x1)  xxx  xxxx


Leeds (0113), Sheffield (0114), Nottingham (0115), Leicester (0116), Bristol (0117), Reading (0118):

Numbers with area code like (011x) are written:   (011x)  xxx  xxxx


London (020), Southampton and Portsmouth (023), Coventry (024), Northern Ireland (028), Cardiff (029):

Numbers with area code like (02x)  are written:   (02x)  xxxx  xxxx


Rest of the country (01xxx):

Numbers with area code like (01xxx) [but not including (01x1) or (011x) codes] are written:   (01xxx)  xxxxxx


There are a small number of exceptions where the number part has only 5 digits. These are usually written:   (01xxx)  xxxxx



The brackets around the area code are *optional*.



To summarise:

If the number starts 02x the number part is 8 digits long (grouped as  xxxx xxxx).

If the number starts 01x1 or 011x the number part is 7 digits long (grouped as  xxx xxxx).

Most other numbers are written 01xxx  xxxxxx (6-digit number), with a very few as 01xxx  xxxxx (5-digit number in very rural location).




It would require only a small number of 'regular expressions' to parse and fix the data so that it can be displayed in the Ofcom-approved format.

The programming for this is fairly simple. It will need a few value compares, and several regular expressions.

As you say, there's two things to consider here - the format the data is stored in, and the format that it is displayed in.
I'm somewhat surprised that it isn't normalised at the point it is stored in the database.



Off the top of my head I would:

- copy the number to a temporary variable in memory
- remove all the spaces and brackets and hyphens
- check that it is exactly 11 digits long.
- if it is not exactly 11 digits long then print it 'as is' [See Note 1]
- if it is exactly 11 digits long then run function(tidyup)
- this function would format the number correctly as per details above
- finally, print the number out

[1] Print 'as is' - as it is likely that it has extra punctuation, or maybe it is in international format, or might even be multiple numbers such as 0121 456 2345/6/7/8 or like 0121 5678 2340...2350 or some such.  I could live with a small number of items like this if the vast majority of other 'errors' were automatically cleaned up. In fact, in these cases, they would 'stick out more' in your listings making them higher priority for manual attention; you'd no longer need to work on most entries, as they would have automatically been 'tidied' by the operation above.



For the local number part, the 3-4 split for 7-digit numbers, and the 4-4 split for 8-digit numbers, is recommended by Ofcom for readability.  
I, for one, cannot accurately key in a number written like  01212521425  without error.

catj wrote on Jun 6^th, 2009 at 1:52pm:

I know BT Phonebook website lists them in this format, although the printed directories do not.

If all the numbers were stored in the database without any spaces, the search engine could add them when it outputs its results. The add form would need to remove all spaces.

As I've said, responsibility lies with Daniel to implement these changes, and I don't think it's something he's likely to do.

It wouldn't be a disaster if the stuff in the "other information" column was just left 'as-is'.

It's the readability of the other columns that's more important.

I guess it all depends on what you do with a user's search query when received:
- search for what they typed exactly as they typed it,
- take all their spaces out and search for that,
- re-space it in the correct format for what they typed;

against what is in the database:
- numbers stored exactly as submitted,
- numbers stored as 10 or 11 digits with no spaces at all,
- numbers stored in the correct format for that area code.

There's several ways to achieve it, some more work than others.

At first glance, that looks fantastic! I'll certainly keep an eye open for any errors. I'm sure they will be minor, if indeed there are any errors at all.

Thanks for taking the time out to make this great improvement to usability.  You also proved the single naysayer wrong.


I can live with the "other information" column using whatever format was typed by the user. The normal 'number' columns were the main problem.


Is it OK to submit test listings for company "TESTENTRY", or somesuch, or do you already have another made-up reserved word used for testing?

On a number search for company 'BT', the words in the 'numbers' columns have oddsp acing in them, and/or the words are joine dtogether.

Words, and anything else non-numeric, need to be left 'as is' for display; only the all-digit entries, and only those that are exactly ten or eleven digits long, need to be formatted.

I guess that it is attempting to format them using the last formatting rule in your IF...ELSE list (and that one is probably '01xxx xxxxxx').

The clue is that the gap is after the fifth letter, every time.    



The formatting does not 'touch' numbers in the +441214789200 international format. That is not a problem.

There are too many issues with trying to fix those (you'd need to know the formatting rules for every country), and very very few are in that format anyway.