Decide how we want to handle lang strings in components

[haworku]

There are some new components that could include lang strings- see "Return to top" in Footer #78 and SearchInput #104 . Since sites using the library can be in another language, we are creating components that won't be flexible to internationalization.

One solution could be that we don't include any hardcode any strings in our components (or only as a default value that can be overridden by a prop). Other thoughts or ideas?

[sojeri]

I like the default value overridden by a prop.

If we want to support internationalized content, I wonder if we should update our storybook to showcase this w/ long strings and RTL behaviors.

[suzubara]

this is a super good point. I also like the default value overridden by a prop. I want to say there's probably not a ton of these instances but I do like the idea of adding examples of this to Storybook.

[tinyels]

I like the default prop idea. I'd also like us to think about what sort of recommendations we want to make with respect to localization. @scarequotes and I have had a couple of conversations about how setting up projects for localization would make it easier for content strategists to manage the language in projects. That is, they could provide initial language and even submit changes without having to pull an engineer in.

[haworku]

Hey everyone circling back here! I'd like to propose closing this issue since it sounds like we have agreement about using props (with English default values) to handle any necessary language strings.

@sojeri raised something we could capture as a separate issue (updating storybook to showcase localization support - RTL, examples of long strings, etc). I wonder also if work on that issue could also involve in skimming our components generally for other places where simple choices would support localization? Does this feel like premature optimization or useful to folks? For example, I noticed yesterday that #144 should probably be more flexible (so that the consumer can select the order of MM/DD/YYYY , DD/MM/YYYY, or YY/MM/DD for inputs).

@tinyels do you have any existing documentation of what you all have been talking about in terms of recommendations about how to approach localization? I wonder if this should be a section in our Engineering docs 🤔 . I'd be interested to work on something like this with a bit of guidance.