i18n: make the renderer localizable (UI strings + date formats)

[oliveregger]

Problem

@aehrc/smart-forms-renderer currently hardcodes its user-facing UI text in English and renders dates in a fixed DD/MM/YYYY format. There is no supported way for a consuming app to localize the renderer's own output.

Examples of text/behavior that cannot currently be localized:

• Boolean item options are always Yes / No (no way to render Ja / Nein, Oui / Non, Sì / No).
• Date fields always display/parse as DD/MM/YYYY (e.g. Switzerland needs DD.MM.YYYY).
• Date validation error messages are English-only.

Motivation / use case

We are evaluating Smart Forms for use in Switzerland, which has four official languages (German, French, Italian, Romansh). Forms must present the renderer's UI and date formatting in the user's language/region — e.g. a Swiss‑German form should show Ja/Nein and 31.12.2024, not Yes/No and 31/12/2024.

This is distinct from translating the questionnaire content (item.text, answer option displays), which FHIR already standardizes via Questionnaire.language + the translation extension. The gap here is the renderer-owned "chrome" (labels, messages, date formatting) that lives in the component code, plus locale-aware date handling.

Desired outcome

A way to configure the renderer's language/region so that:

• renderer-owned UI strings resolve to the active locale (with sensible English defaults),
• dates format, parse, and validate according to the locale (with an override),
• it stays opt-in and backward-compatible (English / DD/MM/YYYY unchanged by default),
• consumers can supply their own translations without the library imposing an i18n framework.

Scope

• In scope (this request): renderer chrome — boolean labels, date format/validation, validation messages.
• Follow-up (separate): FHIR content translation via Questionnaire.language + _text translation extensions.

Proposal

A draft RFC PR exploring one approach (config-injected string catalog + Intl-derived date formats) is open for discussion: #1995. Seeking the team's view on whether this is a direction to pursue.

[clinnygee]

Hey Oliver,

This seems like a pretty good idea. We will discuss this on Monday and get back to you after that.

[oliveregger]

Thanks, if you need any additional info let me know. I continued working on it on the proposed approach and I am currently up to 65 stinigs/messages which need to be localzezd, not too many:

main...ahdis:smart-forms:feat/i18n-renderer-chrome-strings

this can certainly also adapted to another i18n approach

[clinnygee]

Hi @oliveregger ,

We discussed this and we're happy with the overall direction — the config-injected catalog approach (no i18n framework, English defaults + optional overrides) is exactly the kind of opt-in, backward-compatible design we would want, and the locale-aware date handling is a nice addition.

One thing we'd like to change before this can land: we don't want to host the actual translation catalogs (de-CH / fr-CH / it-CH) in the repo. Shipping them here implies we'd be maintaining and vouching for translations we can't natively review, and we'd rather not take on that responsibility. Your architecture actually already supports the alternative we want, since consumers can inject a Partial via rendererConfigOptions.rendererStrings. So the ask is:

• Keep all the infrastructure: the RendererStrings type, the English defaultRendererStrings, resolveRendererStrings/interpolate, the rendererStrings injection point, and the locale-aware date subsystem.
• Drop the bundled catalogs and the bundledRendererStrings registry. Consumers supply their own translation file in their deployment and pass it in via rendererStrings.
• locale stays, but purely for date formatting / calendar localization rather than selecting a bundled string catalog.
• Update the Swiss Storybook stories to demonstrate the injection path with an inline catalog — that doubles as the documented pattern for consumers.

This way the consuming app can supply the required translations.

The same thoughts go for the imports of dayjs/locale/* for the calendar popup, we would also like those to be provided by the consuming app.

If that works for you, this is a direction we'd be glad to move toward merging.

If this would not work for your implementation, we are open to other ideas and getting your thoughts on this and other issues that you might have.

Thanks for the thoughtful RFC.

[oliveregger]

Hi @clinnygee, thanks a lot for your feedback! That sounds like a very good approach to separate the translation responsibilities. I will update the PR can come back to you.