joaocarmo / i18n-postal-address

A JavaScript library to produce international postal addresses formatted by region
https://joaocarmo.com/i18n-postal-address-playground
MIT License
29 stars 11 forks source link

Korean address missing inclusion of address and postal code, using too specific fields #226

Open tn819 opened 3 weeks ago

tn819 commented 3 weeks ago

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:

  // South Korea,
  KR: {
    default: {
      array: [
        ['country'],
        ['do', 'si', 'dong', 'gu', 'addressNum'],
        ['companyName'],
        ['lastName', 'firstName', 'honorific'],
      ],
    },
  }

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

joaocarmo commented 2 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:

https://github.com/joaocarmo/i18n-postal-address/blob/b4d3c528ed6a5e4d9728f9c03a6dd7cdb4b2ccf0/lib/postal-address.ts#L171-L178

If you have any improvement suggestion, feel free to open a pull request.

tn819 commented 2 weeks ago

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.

joaocarmo commented 1 week ago

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.