Google's phone number handling library | Hacker News Reader

Google's phone number handling library

code.google.com

284 pointswslh42 comments

Ha, good to see this here - so incredibly useful, and already ported to lots of useful languages. Handling phone numbers gets messy really quickly: formatting/validation for national/international numbers, in different forms (land-line/mobile/premium etc), in hundreds of different countries... These guys have done a great job, and are also super responsive/helpful when you raise issues.

A word of warning: if you ever set out to handle international numbers in a web frontend - you may think "it can't be that hard - maybe take me a couple of hours" (like me), then do yourself a favour and save yourself a week of unexpected work and use the jQuery plugin that I ended up creating (I don't understand why this didn't already exist) which uses libphonenumber for all the magic: https://github.com/Bluefieldscom/intl-tel-input. Hope it saves you some time.

Looks awesome; will consider using this in the future.

One note: it would be nice if you explicitly stated, in the LICENSE file or the readme, that this is under the MIT license. It'd make it easier to use this at companies (like mine) where open source packages can only be used if their license is on a legal-department-approved whitelist.

What other licenses are usually on that list?

Done.

I did phone numbers validation in the front end, and I yes the expected couple hours ended up being multiple days of works and I ended up using google's validator!

thanks for the jquery plugin, I'll definitely keep it in mind!

That looks amazing.

Exactly what I was looking for! Thanks!

Please make this a node package at some point.

I have created a node package a couple of months ago which I regularly keep up-to-date with the latest upstream changes. It exports everything that the javascript version of libphonenumber offers. You can check it at http://seegno.github.io/google-libphonenumber/.

Not entirely sure how this made front page, but it is a super handy lib.

I don't understand why Android includes this lib in their source but makes it internal so you have to provide your own copy if you want to use it in your app: https://android.googlesource.com/platform/external/libphonen...

>> Not entirely sure how this made front page, but it is a super handy lib.

Sad that nowadays a statement like that isn't even considered ironic :). A cross-platform library handling an ugly necessity of development has to fight for its life in a sea of "growth hacking 101" links and the like.

That's true, I totally agree with you at its irony in hindsight. I guess I'm a bit blinded at having worked on Android apps for a while and using this lib way too often.

It's an extremely specific library and anyone who needs this sort of thing will easily find it in their search.

I would speculate that the reason why is so that Google doesn't have to maintain several versions of the library within the Android platform.

If Google is the only consumer, then Google only has to test internally that they didn't break something with an update. If tons of apps are consumers then they need to either test with many more apps, or worse just simulate buggy old behaviour for apps to keep things consistent (see Windows/Win32/etc).

If apps house their own copy of the library, then that version is static for that app's context, which likely means it won't break randomly in the future. That's good for the app developer (better back and forward compatibility), better for Google (less testing, less maintaining compatibility), and less headaches for consumers (as apps won't break as often when updating Android).

This reminds me of one of my favourite quotes: "If something in software doesn't make sense, then assume it is there for compatibility reasons." Which I think is a Raymond Chen quote that I've mangled.

I posted it after one of our engineers discovered that this is a hard problem!

We were trying to use Twilio and Authy on an application but they handle phone numbers in a different way. Say you accept a phone number from Argentina, to call mobile phones from outside the country you need to add a 9. Twilio accepts that 9 and correctly sends SMS or calls to that number but Authy only accepts the local number format without the 9 and have a big IF to add the 9 internally. So, if for some reason the application must use a phone number in Twilio AND Authy you will need to accept two phone numbers from the user (that are the same in different formats), which is... annoying.

The reason it's internal is because system code takes priority over third party libraries given the same package name. If there were any changes to the library, you could never use the newest version because it would be dominated by the system version. This is what happened to the Apache HttpClient and why there is a fully repackaged version[1] for people who want to use a newer client than the one in the Android System.

[1] https://code.google.com/p/httpclientandroidlib/

Yeah but it's already namespaced differently so package name shouldn't conflict. But now that I think about it more, consistent versioning for the 3rd party dev across multiple OS versions is pretty important.

Internal version probably has online geocoding

If you care about i18n and the physical world, there's also https://github.com/googlei18n/libaddressinput (and googlei18n in general)

And my PHP reimplementation: https://github.com/commerceguys/addressing

I guess I shouldn't but One thing that surprises me is the lack of developer friendly libraries like this coming out of major corporations that should know better.

Why, for example, is Stripe leading the charge on decent credit card front ends when Visa could spend a few million and produce the one and only Unicode, works everywhere, looks up addresses credit card entry form.

Why is an advertising company doing this when any of the major telcos have this internal knowledge lying around?

The blindness does seem almost wilful at times.

I think the concept of giving something away that someone did on the clock seems utterly stupid to them (on the surface it does sound dumb). Even though a solid library that's really useful can take on a life of its own and require less work in the future - just getting a port to a different language for free could make it well worth while if you ever needed it. Then there's licensing and lawyering around releasing something. I understand it, but also wish this would happen more often.

Part of the problem is, designing a friendly library requires taking into account all of the use cases of other people.

Often when you're developing an app, even one completely in open source, you aren't designing all parts of it for maximum reusability. There are tons of private APIs in most apps, including most open source apps.

It's usually after the application which drove the development of the utility code in the first place is finished and stabilized, that people go back and figure out how to refactor it to make it generally more useful.

A few million? Under one million... with significant polish.

I put the JavaScript version inside Postgresql (plv8). Was validating 50000 phone numbers per second

I've been using the python port lately, its great.

https://github.com/daviddrysdale/python-phonenumbers

I've been using this for quite a while -- it's excellent -- without a doubt the best library around for dealing with phone numbers in E.164 format (the international standard).

As someone who does a lot of telephony work, <333

Exactly. It comes in super handy when you have a free(ish) form text field where the users enter their number which you want to later use (say for 2FA).

Yep! This is what I use it for (among other things).

I use the PHP version from time to time.

https://github.com/giggsey/libphonenumber-for-php

This Python version is great, too.

https://github.com/daviddrysdale/python-phonenumbers

I use this Ruby version:

https://github.com/daddyz/phonelib

I see they added carrier lookup by phone number since I last looked at it.

I've used this to great effect to help handle partially obfuscated phone numbers and validate whether they could be valid or not. There are far too many edge cases to try to handle on your own if it's not core to the problem you're trying to solve.

I ported this to Github last year, due to my frustration with Google Code :p https://github.com/sqren/libphonenumber

Is there such a thing as an address library? I imagine something with a standard format, and a table schema you can just put into any app and have a functioning contacts list. Preferably a ruby gem maybe?

Having worked on that a bit (I wrote the schema for planning applications in Scotland) ... that stuff is a mess. Take a read of this for starters:

http://www.mjt.me.uk/posts/falsehoods-programmers-believe-ab...

The requirements for the work I did meant that we had to support the UK's NLPG standard for addresses which didn't even work for the house I live in so I knew I was off to a bad start :)

That is a very good list. I would also add to this list that unlike what people think, numbers are not necessary following each other (they can be completely random), the even/odd rule might also not be respected and the building number can also contain letters.

I've been using this Javascript library: https://vtex.github.io/front.phone/

Also try the iOS port. https://github.com/iziz/libPhoneNumber-iOS

Really nice.

Just notice that the homepage from googlecode is much more "words" per square than from github.

super helpful library

Reply on news.ycombinator.com