Open tn819 opened 3 weeks ago
You can propagate related properties to help with this issue using the setPropagation
method. This is set to true
by default. Ideally, we should format the address per its original framing. This ensures that we are targeting the correct output format. Of course, we can infer it and try to map it using more common fields such as address1 <-> dong
.
Here's an example of the source code:
If you have any improvement suggestion, feel free to open a pull request.
Ok, let me think on that. I think it is a bit tricky to have the underlying term be localized, especially when although it may be consistent it does map to a common term like province/region etc.
I guess I view the target dev audience as being someone who's international and not doing something market specific.
There is also a missing zip code still. I can make a contribution for this.
Many of the original formats in this library came from Microsoft's Appendix V International Address Formats, as specified in the README file. If you browse down to the section for Korea, you'll notice they use different terms for the format. This is why it's implemented this way.
Expected Behavior
inclusion of street/house address information is properly inferred. Zip code is included next to country or on its own line.
Seojun Kim
33, 6th Floor, 114, Seolleungro-190gil, Gangnam-gu, Seoul
06010 South Korea
Actual Behavior
Zip code and street information are completely skipped for korean specific fields (they could maybe be set twice?). We should be more forgiving as generalized forms will not capture do (province)/si (city) /dong (area within a district) /gu(district within a big city). Additionally, it feels like this might be most likely to be included via the
address
/address
/address2
props and if those are present they could be included.Current implementation:
Your Environment
Source on Korean address: https://www.90daykorean.com/korean-address/ Some random Korean addresses: https://www.bestrandoms.com/random-address-in-ko?quantity=6