Implement the "Select a language" design pattern

[sawyerh]

What's the task?

The template already supports internationalization (i.e. adding /es-US to the URL toggles to Spanish) but the template doesn't currently include an interface element for toggling the active language. There is some USWDS design pattern guidance we can follow for this: https://designsystem.digital.gov/patterns/select-a-language/

[jcq]

@sawyerh With this sort of thing, have we generally been preferring the react-uswds components (assuming they exist), or have we been creating our own?

[sawyerh]

@jcq We've been using the React USWDS components when possible, to reduce the amount of custom React components the template (and projects) then need to maintain themselves.

[jcq]

OK, after spending some time working on this, I have a variety of questions, both about the react-uswds implementation and the USWDS pattern in general.

Toggling between two languages

The react-uswds implementation takes a displayLang prop, which (if I understand correctly) should refer to the currently set language code. This is used to set which LanguageDefinition to use for the current label and on_click handler. However, by their implementation, it displays the current language label, rather than the alternate language to which to toggle. (So if the site locale is en-US, it displays "English" instead of "Español" (when es-US is the alternate language.)

This is different than how it works on usa.gov (and how I would assume it would work). I could get around this while still using the react-uswds package by showing an example where the en-US label is "Español" and the one for es-US is "English", but that also seems a bit odd.

Three or more languages

When it comes to the selection of language from three or more options, I have a question about the pattern from USWDS. They have the button text show the word "Language" in the currently set language. This means that if someone accidentally switches language (or perhaps clicks on a link somewhere with an alt locale set, or just does not recognize the word "Language" in the default locale) to something they don't understand, they might not have any idea which control can get them to the language they will understand.

Unfortunately here we are limited by an adherence to USWDS patterns, but also by the fact that I don't know what would actually be better. This is where having an icon/graphic of some sort would likely be very helpful. I've read their guidance that eschews using flags (due to valid reasons), but we might want to consider this user experience.

At a more technical level...

The react-uswds implementation allows either a string or a () => void for the on_click property for each language. Obviously if one provides a function, those are just called. However, if one provides a string, that is fed in as an href to an <a> tag. In NextJS we would prefer a <Link> tag, but there is no way to specify an alternative component.

Would we still prefer to keep using react-uswds for this or would it be worth creating our own implementation that supports alternate link components? (I can also just open an issue with react-uswds requesting that functionality.)

cc @sawyerh @lorenyu

[sawyerh]

The react-uswds implementation takes a displayLang prop, which (if I understand correctly) should refer to the currently set language code

I think the USA.gov approach is the correct approach, so displayLang would represent "display this language as the button text"

we are limited by an adherence to USWDS patterns, but also by the fact that I don't know what would actually be better. This is where having an icon/graphic of some sort would likely be very helpful. I've read their guidance that eschews using flags (due to valid reasons), but we might want to consider this user experience

This is a good point. I lean towards sticking with USWDS out-of-box patterns, and leaving it to project teams to determine whether they want to deviate or not, since we don't know what a better approach is right now and won't be able to user test it.

Would we still prefer to keep using react-uswds for this or would it be worth creating our own implementation that supports alternate link components?

This doesn't feel like a dealbreaker. I think your draft PR using the Next.js router is a good compromise and I think would be needed for a dropdown (2+ languages) since that's not rendered as a link/button? I don't think a normal HTML anchor is that bad in this instance since this is mostly a one-time preference selection, and client-side navigation is more of an enhancement.