Expose fields and formats inside the library to allow internationalization

[afeld]

Is your feature request related to a problem? Please describe.

As a forms provider, I would like the ability to offer my form in multiple languages (without building it twice).

Describe the solution you'd like

Documentation (and perhaps feature additions?) around multiple language support.

Describe alternatives you've considered

Since the form configuration is done in a JS file, perhaps the titles, uiSchema values, etc. can be specified dynamically with the help of an i18n helper library. For example:

const formConfig = {
  title: I18n.t("form.title"),
  // ...
};

Maybe this approach would cover most of it?

Additional context

Other keywords to help people find this issue: localize, localization

cc rjsf-team/react-jsonschema-form#739

[dmethvin-gov]

I have wondered the same about i18n and l10n issues. This rabbit hole goes pretty deep though. For example, the DateWidget currently includes the English words for Month, Day, and Year. Of course you could also make the case that the expected order of those fields may be different in some locales. For complex cases it might make more sense to have different widgets perhaps?

[jcmeloni-usds]

I am especially and always interested in issues of i18n and any l10n that happens because a system is ready for it (as a personal and long-standing interest), and we definitely made an explicit choice to ignore i18n while working through the decoupling of what is now this library from the vets.gov specific library where it originated.

However, i18n and thus ability to localize is definitely something I'd like us to prioritize once we get the library to a stable and more externally useful place. I've generally been watching things to ensure that we don't paint ourselves further into a non-localizable hole during this initial development, and I'm still pretty bullish on taking a good swipe at an i18n refactor in a couple months.

tl;dr: yes, @afeld :)

[jcmeloni-usds]

Just an update here -- as we determine precisely what 2.0.0-alpha might look like (starting Oct 1, aka "phase 2") this is something that will be pretty close to top of mind.

[dmethvin-gov]

I've re-titled this (again!) since it will take changes inside the library to make i18n work correctly.

Here's what I've found so far that needs work on i18n and possibly l10n, we can add to this list as more are found:

• CurrencyWidget - Assumes US Dollars
• DateWidget - English words and US month/day/year field format order.
• helpers.js - English words for route names like introduction and review-and-submit.
• validation.js - English words for error messages, but most these are okay because they are only the defaults and can be changed via the uiSchema. A few like validateCurrency are not.
• js/utilities/validations - English error messages
• js/utilities/date - English month names
• js/utilities/data - English error messages galore
• SubmitButtons - English text on buttons
• js/definitions - English error messages, although most could be overridden with some difficulty when the uiSchema is merged
• FormPage - English button names

[annekainicUSDS]

This is not a high priority in the short-term, but if someone wants to implement this due to a need for their project, we would gladly accept a PR for this work!

[easherma]

@annekainicUSDS we are looking into this for https://github.com/cityofaustin/us-forms-system / https://github.com/cityofaustin/officer-complaint-form