-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comments
|
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. |
|
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 |
|
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! |
|
Not a use case we have, so all good with us. |
|
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 |
|
Thanks! |
|
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. |
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.
The text was updated successfully, but these errors were encountered: