As the US Web Design continues to grow, there should be some standardized method of handling localization for interactive components that contain different states that should not be placed within the few.

For example, let's say hypothetically, there was a component that had button that returned the string "Success!" or "Failure" in an empty div above it randomly when clicked (yes, this hypothetical component is absurd and should never actually be built). The two strings would typically be declared in the JavaScript file within the USWDS source code.

Using a Google Translate browser extension, this would not be an issue because the plugin can handle translations on active regions. However, this would be an issue if your site is serving content using language files (details).

What that looks like would be something like:

# locales/en.yml

hero:
  hello: "Hello"

and

# locales/es.yml

hero:
  hello: "Hola"

with a view beings something like:

<div class="hero"><h1>{{ hero.hello }}</h1></div>

If a text string is declared as JS variable, this approach would exclude that string from localization. Thinking in specifically if the project is using the already-compiled uswds.js file.

One potential solution would be to create a utility that accepts overrides in the form of data attributes. For simplicity, we can still declare the strings using english in the JS, but let's say if an override is present, in the form of a data attribute, we can override those declarations.

Going back to the absurd example, this would be the default:

<button class="usa-feedback-button" type="button">Click me</button>

But if we want to support localization, we code this something like:

<button 
     class="usa-feedback-button" 
     type="button" 
     data-string-success="{{ item.success_message }}"
     data-string-failure="{{ item.failure_message }}"
 >{{ item.button_text }}</button>

Any component that supports this would have to have a dedicated section in the guidance that describes every state associated with that component.

I don't know if this is best solution. Definitely open to others, but figured it's worth starting this discussion since government sites must support localization.