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

[tn819]

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]

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:

i18n-postal-address/lib/postal-address.ts

Lines 171 to 178 in b4d3c52

	public setAddress1(newValue: string): this {
	this.setProperty('address1', newValue)
	if (this.propagateToRelatedProperties) {
	this.setProperty('dong', newValue)
	}
	return this
	}

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

[tn819]

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]

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.

[tn819]

@joaocarmo - I see that but in theory there are different terms for many of these items in other lanuages, that are just brought over into english. I believe the korean terms map to english terms:

Additionally, some of the terms have been discarded in a revamp but the old style persists so maybe two are needed: https://expatguidekorea.com/article/understanding-south-korean-addresses.html

My guess is that many address forms won't collect all of this and will instead just put everything on address/address1 by default, in which case we need to have a fallback if the specific underlying fields aren't collected.

In lib-mappings there's an interesting re-mapping:

const libpostalMap: ParserMap<PostalLabels> = {
  address1: [
    'house',
    'house_number',
    'unit',
    'level',
    'staircase',
    'entrance',
    'road',
  ],
  address2: ['near', 'suburb', 'city_district', 'state_district', 'island'],
  addressNum: ['po_box'],
  city: ['city'],
  companyName: [],
  country: [
    {
      attribute: 'country',
      transform: capitalizeWhenTwo,
    },
    'world_region',
  ],
  countryAlpha2: [],
  do: ['country_region'],
  dong: [],
  firstLastName: [],
  firstName: [],
  gu: [],
  honorific: [],
  jobTitle: [],
  lastName: [],
  postalCode: ['postcode'],
  prefecture: ['state_district'],
  province: [],
  region: ['country_region'],
  republic: [],
  secondLastName: [],
  secondName: [],
  si: ['city'],
  state: [
    {
      attribute: 'state',
      transform: capitalizeWhenTwo,
    },
  ],
  title: [],
}

Maybe it would make sense to do remappings from some of the attributes that are korean specific here? Why is only si remapped?

[tn819]

An additional thought, there may be many forms where the Address/Address1 takes the place of the specific capture of the underlying data (such as for Korea/Japan). I wonder if we could introduce a fallback that uses those in place of the language specific values (si/do/dong) if those aren't defined.