feat: allow custom languages in IntlProvider

[Benehiko]

Adds custom language support to the IntlProvider. This allows users of ory/elements to specify and provide their own custom translations without needing to add it to the ory/elements repository.

Related Issue or Design Document

Checklist

• I have read the contributing guidelines and signed the CLA.
• I have referenced an issue containing the design document if my change introduces a new feature.
• I have read the security policy.
• I confirm that this pull request does not address a security vulnerability.
  If this pull request addresses a security vulnerability,
  I confirm that I got approval (please contact security@ory.sh) from the maintainers to push the changes.
• I have added tests that prove my fix is effective or that my feature works.
• I have added the necessary documentation within the code base (if appropriate).

Further comments

[zepatrik]

This is already possible & documented:

elements/README.md

Lines 359 to 377 in 4bdbac1

	Custom translations can be provided using the `IntlProvider` from `react-intl`.
	For reference, it is best to start with the auto-generated English defaults, as
	they include all keys. More information on the Kratos messages can be found
	[in the docs](https://www.ory.sh/docs/kratos/concepts/ui-user-interface#ui-message-codes).
	```tsx
	import { IntlProvider } from "react-intl"
	const Main = () => {
	return (
	<IntlProvider locale={customMessageLocale} messages={customMessages}>
	<Router>
	<Route path="/" component={Dashboard} />
	{/* ... */}
	</Router>
	</IntlProvider>
	)
	}
	```

We could improve the docs to show how the default translations can be extended instead:

import { IntlProvider } from "react-intl"
import { locales } from "@ory/elements"

const customMessages = {
  ...locales,
  de: {
    ...locales.de,
    "login.title": "Login",
  },
}

const Main = () => {
  return (
    <IntlProvider locale={customMessageLocale} messages={customMessages}>
      <Router>
        <Route path="/" component={Dashboard} />
        {/* ... */}
      </Router>
    </IntlProvider>
  )
}

[Benehiko]

This is already possible & documented:

elements/README.md

Lines 359 to 377 in 4bdbac1

	Custom translations can be provided using the `IntlProvider` from `react-intl`.
	For reference, it is best to start with the auto-generated English defaults, as
	they include all keys. More information on the Kratos messages can be found
	[in the docs](https://www.ory.sh/docs/kratos/concepts/ui-user-interface#ui-message-codes).
	```tsx
	import { IntlProvider } from "react-intl"
	const Main = () => {
	return (
	<IntlProvider locale={customMessageLocale} messages={customMessages}>
	<Router>
	<Route path="/" component={Dashboard} />
	{/* ... */}
	</Router>
	</IntlProvider>
	)
	}
	```

We could improve the docs to show how the default translations can be extended instead:

import { IntlProvider } from "react-intl"
import { locales } from "@ory/elements"

const customMessages = {
  ...locales,
  de: {
    ...locales.de,
    "login.title": "Login",
  },
}

const Main = () => {
  return (
    <IntlProvider locale={customMessageLocale} messages={customMessages}>
      <Router>
        <Route path="/" component={Dashboard} />
        {/* ... */}
      </Router>
    </IntlProvider>
  )
}

I agree that we do support it, but it requires the user implementing the library to directly use react-intl.

In an optimal path scenario I can see more users wanting to only use a copy paste example with defaults and the option to override some labels, such as the login ID -> Email for example.

The path to reach this use case in the current method isn't as obvious and a bit confusing, especially if you have no idea which keys do what. What if we introduce breaking changes later on inside the translations? or special formatting like we do here https://github.com/ory/elements/blob/main/src/react-components/provider.tsx#L50-L52

I'm not against the current way and I think supporting it makes sense to give users a choice and the ability to customize the translation layer themselves. But a happy path must exist and i don't think the current implementation is that happy path.

[Benehiko]

I have updated the README to be more clear on this and moved it to the top under getting started.

[zepatrik]

Nice, this looks quite a bit more useful now 👍