i18n: consistently fall back to default locale

[max-baz]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

In some cases (e.g. in registration) you manually define "defaultMessage", in order to have a user-friendly English fallback.

elements/packages/elements-react/src/theme/default/components/card/footer.tsx

Lines 102 to 105 in 7a6254a

	{intl.formatMessage({
	id: "login.registration-button",
	defaultMessage: "Sign up",
	})}

In other cases (e.g. in settings) the UI falls back to "id" of the translation, making the UI really not something you want to show to your visitors.

Furthermore, those defaultMessages are sometimes inconsistent with the English locale (e.g. "Don't have an account?" has a fallback "No account?") and they don't respect custom translations provided for the English locale.

Describe your ideal solution

In IntlContext, after you merged custom translations:

elements/packages/elements-react/src/context/intl-context.tsx

Lines 164 to 169 in 7a6254a

	export const IntlProvider = ({
	children,
	locale,
	customTranslations,
	}: PropsWithChildren<IntlContextProps>) => {
	const messages = mergeTranslations(customTranslations ?? {})

Run another helper that would loop over all locales and add all missing translations with values from the en locale. Then remove all mentions of defaultMessage from the codebase.

Perhaps make it optional to disable this in development mode, if you want to keep the in order to catch missing localization.

Ease of development however should not be prioritized over nice user experience, and right now using ory/elements on an internationalized website makes a very bad user experience, where users are presented with some internal localization IDs.

Workarounds or alternatives

1. Translate ory/elements into all locales 🙌

2. Instead of passing the current website locale to ory/elements components, maintain a mapping in own code of what locales ory/elements currently supports, and pass "en" instead when it's known that ory/elements doesn't fully support the given locale.

Version

1.0.0-rc.2

Additional Context

No response