You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Those methods can extract keys, and place it in either:
one big file
one file pre each JS files
Code splitting
CRA supports code splitting out of the box 👍, I would also like to split i18n the same way as JS splitted:
Loadable.Map({loader: {Bar: ()=>import(/* webpackChunkName: Bar */'./Bar'),i18n: ()=>fetch(`./i18n/${lang}/bar.json`).then(res=>res.json()),},render(loaded,props){letBar=loaded.Bar.default;leti18n=loaded.i18n;return<Bar{...props}i18n={i18n}/>;},});
Bar can contain other components (with static imports and i18n keys), for example Foo. So Bar.xxxx.chunk.js can require i18n keys for Foo and for Bar or it can happen that Foo, will be splitted in common.xxxx.chunk.js.
It would be nice to have Bar.xxxx.chunk.json and common.xxxx.chunk.json with i18n keys so appropriate translation files can be generated.
Obviously CRA should not lock-in users with some exact i18n library, but rather we can look into providing low level APIs so other libraries can reuse it. This idea still miss some details, for example, how i18n would work in development environment and maybe other.
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
Is this a bug report?
No, rather a feature request.
i18n
There are ways to extract keys for internationalisation, like:
Those methods can extract keys, and place it in either:
Code splitting
CRA supports code splitting out of the box 👍, I would also like to split i18n the same way as JS splitted:
Bar
can contain other components (with static imports and i18n keys), for exampleFoo
. SoBar.xxxx.chunk.js
can require i18n keys forFoo
and forBar
or it can happen thatFoo
, will be splitted incommon.xxxx.chunk.js
.It would be nice to have
Bar.xxxx.chunk.json
andcommon.xxxx.chunk.json
with i18n keys so appropriate translation files can be generated.Obviously CRA should not lock-in users with some exact i18n library, but rather we can look into providing low level APIs so other libraries can reuse it. This idea still miss some details, for example, how i18n would work in development environment and maybe other.
Related tickets:
The text was updated successfully, but these errors were encountered: