Closed DangerDawson closed 8 years ago
Thanks for the bug report, @DangerDawson. I just filed an issue to get the data corrected, but who knows if anyone will respond (doesn't look like Google has a great track record of fixing issues like this). This library, twitter-cldr-rb, actually has a mechanism built into it that we could potentially use to override the South Korean postal code format until Google's i18napi data is corrected. Do you have any free time to submit a pull request?
Fixed in v3.6.0. Thanks!
Of course…
I will do this later on Today
On 20 Oct 2016, at 17:46, Cameron Dutro notifications@github.com wrote:
Thanks for the bug report, @DangerDawson https://github.com/DangerDawson. I just filed an issue https://github.com/googlei18n/libaddressinput/issues/111 to get the data corrected, but who knows if anyone will respond. This library, twitter-cldr-rb, actually has a mechanism built into it that we could potentially use to override the South Korean postal code format until Google's i18napi data is corrected. Do you have any free time to submit a pull request?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/twitter/twitter-cldr-rb/issues/195#issuecomment-255161984, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEWjDvK1_pl2GDNYyQJqK3Ui2JfrKNBks5q15sCgaJpZM4KcSjf.
@DangerDawson This should already be fixed and available in version 3.6.0. No need to do any extra work... unless something else isn't working?
From August the 1st 2015 South Korea's postcode went from being 6 digits to 5
Which causes issues for anyone using the library to validate addresses for delivery, as the api that this library uses still supports the old postcode as well as the new one:
"\\d{3}(?:\\d{2}|-\\d{3})"
where it should be
"\\d{5}"
Hence it seems as though, the following needs updating:
http://i18napis.appspot.com/address/data/KR
Then this gem needs resyncing