Right now, we don't hard-code any English strings in Codex, instead we make our users pass in strings through required props, e.g. the `closeButtonLabel` prop in the Dialog component. This keeps Codex internationalizable, but it puts the burden of internationalization on the user.
We should consider instead `inject()`ing these strings into the components that need them. Users would be expected to `provide()` internationalized strings in the appropriate language, and if they don't we'd fall back on hard-coded English strings in Codex. We could take inspiration from [[https://vuetifyjs.com/en/features/internationalization/#vue-i18n|how Vuetify integrates with vue-i18n]], and have the user provide an i18n function (that takes a key + params and returns an i18n-ed string) instead of an object/map; that way we'd provide a lot of flexibility to plug in any i18n system (vue-i18n, MW i18n and a simple map of strings are all easy to integrate this way).
This change would make using Codex in MediaWiki easier and more consistent, because we wouldn't have to rely on e.g. every use of Dialog using the same i18n message for its `closeButtonLabel`.
This change would allow us to replace the following props with i18n messages:
- ChipInput: `removeButtonLabel`
- ChipInput: (potentially) a screen reader description explaining how to edit/delete a chip using the keyboard, if we end up adding one as part of T344849
- Dialog: `closeButtonLabel` (Note: we might need a new prop to allow the close button to be shown/hidden)
- Field/Label: `optionalFlag` (maybe? we may want to keep allowing arbitrary text here)
- Message: `dismissButtonLabel` (Note: we would need a new prop to allow the dismiss button to be shown/hidden)
- SearchInput: `buttonLabel` (maybe?)
- TypeaheadSearch: `searchResultsLabel`
- TypeaheadSearch: `buttonLabel` (maybe?)