[docs] Document localization and internationalization - How do we improve Spanish support?

[mgifford]

Does this documentation relate to a specific USWDS feature?
Content should need to be available in English & Spanish

Is your documentation related to a problem or inconsistency? Please describe.
There is nothing that I can find for supporting bilingual content

Describe the documentation you'd like

I assume that we'd be extending it with https://www.npmjs.com/package/react-localization but haven't tested it.

Also see:
https://blog.decipher.dev/internationalization-in-plain-reactjs

[haworku]

I agree this is something we need to standardize on and there is no existing documentation in the repository on it. I have also added a new label for i18n to our github issues so we start marking related issues as they come up.

[haworku]

Reviving this issue after seeing #2399.

I think it would be good to have more of a pattern for how we add lang to the application. For example instead of adding lang props as standalone props

type FileInputProps = {
  id: string
  name: string
  dragText?: string
  chooseText?: string
 }

We have a specific prop on all components that is the same for lang string content.

type FileInputProps = {
 id: string
 name: string
 lang?: {dragText?: string, chooseText?: string}
}

That makes it easier for consumers to know where to pass in their i18n localized strings. It also follows the pattern on react-uswds of surfacing props and compose-able React components and allow applications to customize for their use case.

With this approach, the library is responsible for keeping an authoritative localization dictionary for i18n for its components. Rather the library would surface the props so the application can pass in the content they need and override defaults. This is a bit different than suggested in the original post though, so looking for more feedback and ideas on this approach.

[werdnanoslen]

type FileInputProps = {
id: string
 name: string
 lang?: {dragText?: string, chooseText?: string}
}

That makes it easier for consumers to know where to pass in their i18n localized strings. It also follows the pattern on react-uswds of surfacing props and compose-able React components and allow applications to customize for their use case.

I'd be in favor of that. We'd also have to pass in the lang identifier (e.g. "lang=es, lang=en-GB")

[haworku]

@werdnanoslen Oh right I forgot about lang being a reserved html attribute also. I think that is a case then for separating this into a more distinctly named prop since folks might think lang means the lang locale.

Maybe we call it i18n or localeText (got the last one from looking at what MaterialUI does). I'm trying to make a prop that would represent the lang dictionary to use for that component, the keys are the specific keys of text chunks we have in a component. And then if nothing is set for that key, we continue defaulting to english for that. If folks are using an i18n library they would just pass their lang strings into that (and those variables would already be localized based on whatever i18n config they are using in the app).