Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Good old Kosovo #66

Closed
rvandam opened this issue Feb 23, 2017 · 7 comments
Closed

Good old Kosovo #66

rvandam opened this issue Feb 23, 2017 · 7 comments

Comments

@rvandam
Copy link

rvandam commented Feb 23, 2017

We just got a bug report from a Kosovan (?) customer being unable to add a 383 number to their account because it wasn't passing validation (which is mostly based on NP->is_valid). According to https://en.wikipedia.org/wiki/Kosovo, Kosovo was officially assigned +383 on 15 December 2016.

I was going to just make a quick pull request to add that but then I wasn't sure what to do about the country code. I've seen at least some of your notes/comments on the topic in the code and on other issues so I thought maybe it would be best to discuss what would make for an acceptable PR in this case before I step on too many landmines.

It looks like XK is currently the defacto (albeit temporary) standard whereas one of our developers added KV to our list back in 2012 (not your problem just noting that everyone resolves a vacuum in their own way). I could just leave KOS and add 383 as a new prefix or I could swap KOS for XK (which won't be very backwards compatible) or I could just back away slowly and avoid eye contact.

@DrHyde
Copy link
Owner

DrHyde commented Feb 28, 2017

Thanks! See also https://github.com/googlei18n/libphonenumber/issues/1486

For most countries, Number::Phone just uses libphonenumber data, but I'll do what I can before they update. Note that in that ticket they're asking for working +383 numbers they can use to verify that it's operational.

@DrHyde
Copy link
Owner

DrHyde commented Feb 28, 2017

If XK is the de facto standard then N::P should support that, but support it alongside KOS at least temporarily for back-compat. In the absence of any data from libphonenumber, I'm not sure what the best thing to do is - maybe return is_valid() == 1 for any +383\d.* until we know better?

@DrHyde
Copy link
Owner

DrHyde commented Mar 2, 2017

Re backward compatibility, I believe that while the library will report 'KOS' for various numbers, off the top of my head I can't think of anywhere that you can pass 'KOS' as an argument to a method and get anything useful back, so changing it to XK is perhaps not such a breaking change after all.

I've asked people on the mailing list to comment here. And @rvandam, if you're not on the list please join!

@ghenry
Copy link

ghenry commented Mar 3, 2017

Not a use case we have, so all good with us.

@DrHyde
Copy link
Owner

DrHyde commented Mar 14, 2017

The switch from KOS -> XK will be in release 3.4000, and until libphonenumber gets some data for Kosovo, all +383 numbers will return is_valid() == 1.

See 1aaf2e0

@DrHyde DrHyde closed this as completed Mar 14, 2017
@rvandam
Copy link
Author

rvandam commented Mar 14, 2017

Thanks!

@DrHyde
Copy link
Owner

DrHyde commented Mar 22, 2018

libphonenumber now has Kosovo data, so starting from the next release after 3.4003 it'll become a bit more "bondage and discipline" about Kosovo numbers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants