Open sawyerh opened 11 months ago
@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?
@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.
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.
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.
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.
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
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.
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/