[BUG]: Customer retrieved address state value does not match client side <option> value.

[Sladeck]

What happened?

What Happened

When retrieving a Customer data from the V1 endpoint and using the ReactJS Stripe npm package (@stripe/react-stripe-js @stripe/stripe-js), the string state in the address dict does not match any values inside the select HTML element.

If the Customer's address is in Tokyo, the value of state is equal to 東京都 (Tokyo in Japanese) but the expected value is Tokyo, therefore passing the customer's data directly into the option result in an empty select.

To Reproduce

• Fetch a customer through the V1 API endpoint (Django/Python in my case):

  
  import stripe
  stripe.api_key = "sk_test_51Lfw0gHat61Je61xWjIjc5cq1i9KcV8lne5PMVimX5KtXDtotRJCUpaX12OQJNSrruafGnfPkYceJX2f3z24zpFl00sgWJGgkm"

stripe.Customer.retrieve("cus_NffrFeUfNV2Hib")

- Retrieve the data on your front-end, here is what it looks like for someone's address in Japan, Tokyo (omitting non-essential dicts for this problem):
```file.js
const customer = {
    "object": "customer",
    "address": {
          "city": "Shinjuku-ku",
          "country": "JP",
          "line1": "Address Line 1",
          "line2": "Address Line 2",
          "postal_code": "101-8656",
          "state": "東京都"
      }
}

• Injecting customer dict into the options of the AddressElement:

  
  const options = {
  defaultValues: {
    address: customer.address
  }
  }

// .... return function -> <AddressElement options={options} />

The Customer `state` value is `東京都`, however the generated list of states (or prefectures in that case) inside the `AddressElement` is waiting for values in English, so `Tokyo`:
```file.html
// ...... Inside the AddressElement component after rendering ->
<option value="Tokyo">東京都 — Tokyo</option>

I could not find any informations regarding any parameter to change the language when retrieving customer data, it seems like the AddressElement component adapts to the browser's locale settings to automatically localize placeholder text, thereby influencing elements like country/state/city dropdowns.

In such cases, those dropdowns input are empty.

---

Expected behavior:

One of the <option> value inside the <select> of the AddressElement component should match state: state_value.

Suggestions:

• By retrieving the preferred language of the Customer, the front-end could load the correct translation by checking the preferred language.
• Using a different value for the states that is consistent over every languages.

Environment

No response

Reproduction

No response

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fruchtose-stripe]

Thanks for the bug report @Sladeck. I have passed along this issue for investigation.

[jima-stripe]

Hi @Sladeck -- I'm an engineer who works on the Address Element. Thanks for sharing this.

It seems like the root cause is that the value attribute on the <option> element language isn't what you're expecting. I dug into our code and found we have some logic around what we use for the value attribute.

Here's the logic:

• If Google Autocomplete is enabled, and is rendering the options with their latin name OR
• If the countries selected language does not match the language on the window.navigator object (languages[], language, userLanguage),

Then we use the latinName if we have it. In all other cases, we the local language. This logic ensures we're best aligned with how Google autocomplete functions.

If this continues to be an issue, can you take a look at the two bullets I mentioned above, and let us know if you still have concerns. As of now, we haven't had any other reports, so I'm going to close this as "by design".