Improve Phone Number Entry with Google's libphonenumber

[talllguy]

I've been entering phone numbers for local restaurants during the pandemic and find it annoying to manually reformat them every time I copy/paste. I asked if anyone had a tool to auto-format and @iandees mentioned the google/libphonenumber tool in the OSM US Slack.

Can we incorporate a bit of this code into iD so it automatically formats a number entered into the box? Try this demo of libphonenumber

[bhousel]

see #3495

[1ec5]

It isn’t clear to me if the opposition in #3495 takes into account that this formatting would only occur when a mapper manually enters a new phone number in the field, not automatically when loading or viewing a phone number. (This wouldn’t be a validator issue.)

If there really is regional variation in the standard that OSM adheres to, the libphonenumber output could be merely a suggestion that pops up, since the phone number field doesn’t display taginfo suggestions. It could even be enabled on a per-region basis. (iD didn’t support as much regional variation back when #3495 was hashed out.)

I like that this library can format phone numbers correctly according to both the specified country and language. iD already knows the relevant country, and it might know the language well enough to handle the localizable “ext.” piece for extensions. (But even if not, it would just be a suggestion, so falling back to the user’s locale could suffice.)

[bhousel]

It isn’t clear to me if the opposition in #3495 takes into account that this formatting would only occur when a mapper manually enters a new phone number in the field,

I was reading it as - we don’t have consensus that formatting is the right thing to do in the first place.

[brierjon]

@bhousel Is there a list of which regions follow a particular formatting and which areas oppose creating a phone format validation? From a data handling standpoint it would greatly improve the user experience on the front and back end to have assistive formatting and consistent format for the data store. If ID can support regional variation is possible it would be a way to allow the community to opt-in regions and build consensus.

Both #3495 and consistent entry format is something the OSM Michigan meetup has discussed and applied E164 format state wide, but requires ongoing edits as ID is the main tool for non E164 format numbers being entered now.