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
I've had previous success with i18n webpack plugin - perhaps this could be integrated into the webpack configuration?
Given that it increases build time significantly (as it makes use of webpack's multi-compiler feature i.e. module.exports = [configA, configB]; instead of module.exports = config;), it would most likely have to be an opt in feature. We could look for an i18n/ directory that users could drop a bunch of json files into the like so:
src/
i18n/
├─ en-gb.json
├─ de-de.json
├─ ...
The idea that CRA would produce an output bundle per locale in conjunction with i18n webpack plugin.
Thoughts? Happy to attempt a PR if you have no objections.
I'd love to see a good solution to i18n support in webpack based builds. We initially started with something similar to your example based on multi-compiler configs. It is not only significantly slower, but uses a lot of memory. If you want to support more than a couple of locales and if your build pipeline is slightly more complex (e.g. not only transpiling with Babel, but maybe with TypeScript, Babel and maybe another loader) our build scripts run for more than 10 minutes and eventually crashed with an out of memory error. It technically works, but not on a practical level. And it looks like the HTML Webpack Plugin also slows down a lot, if you use multiple instances of it.
I tried to solve this with several hacks. One example is here and another on is here. To work nicely some bugs in webpack would need to be fixed like this one (however I'm still not sure if this is a bug) or we would need new features like this one.
Subscribing this thread because I really hope to find a nice solution for this.
Same here, looking for a the cleanest way to add i18n support into Create React App app without ejecting, maybe there should be some kind of localization section in README?
Reacted by André Cruz, Anshul Khandelwal, Kirill Ezhemenskii, Stephan, alfe, Dawid van der Hoven, Roman Borodatov, stunaz, Shai, Cedric Vangout and 17 more
I was looking for a library primarily for translation of text. Formatting of dates, times and numbers, and time zones is also nice but I guess a separate date library can handle that.
I checked out react-intl and react-i18next to integrate into my CRA project without ejecting. But none of them seem to be straightforward solutions.
We have @enact/i18n which uses iLib under the hood. It's a very comprehensive set of tools for i18n. We have a webpack plugin that handles some of the packaging issues when dealing with i18n. All that is available on npm with an Apache 2.0 license. We'd definitely be interested in seeing if there are ways we could work with the community to make this an option for CRA.
For our own apps, we have a cli tool inspired by CRA and preact-cli that is pre-configured with the plugin.
If it helps, here is the cleanest pattern that I could come up with to add i18n without ejecting:
Use react-intl with react-intl.macro, and then have react-intl-translations-manager to manage the transalation files.
ttag library allows you to implement localization without eject. You have an option to precompile translations right into the bundle or to apply them at a runtime:
This is an important issue, I propose we add an additional page to the create-react-app documentation. Something like this:
To help provide guidance on how best to include Internationalization and Localization support within the create-react-app context.
We could compile many of the recommendations from this thread in a clear and easy to consume way - to make the process of including i18n easier for folks. I think this would be very useful for the community and am happy to help write it up. 🌏 🌍 🌎
Reacted by Jeff Sheets, laila-vinson, Abhijeet Singh, Erhan Yaşar, ahmed osama and Richard Willis
@ahmedosama5200 , i18next + i18next-parser. For my own small search in mid Jan 2020 this was the only solution supporting TypeScript on both sides (provide i18n and extraction from source code) without dark magic, hacks or similar.
Extra requirements in my search was ICU support (i18next-icu) and separate untranslated bundles from translation files (i18next-xhr-backend).
Reacted by Gabor Dolla, ahmed osama and Alexander Kachkaev
Activity
donaldpipowitch commentedon Nov 24, 2016
I'd love to see a good solution to i18n support in webpack based builds. We initially started with something similar to your example based on
multi-compilerconfigs. It is not only significantly slower, but uses a lot of memory. If you want to support more than a couple of locales and if your build pipeline is slightly more complex (e.g. not only transpiling with Babel, but maybe with TypeScript, Babel and maybe another loader) our build scripts run for more than 10 minutes and eventually crashed with an out of memory error. It technically works, but not on a practical level. And it looks like the HTML Webpack Plugin also slows down a lot, if you use multiple instances of it.I tried to solve this with several hacks. One example is here and another on is here. To work nicely some bugs in webpack would need to be fixed like this one (however I'm still not sure if this is a bug) or we would need new features like this one.
Subscribing this thread because I really hope to find a nice solution for this.
tomjal commentedon Nov 27, 2016
Same here, looking for a the cleanest way to add i18n support into Create React App app without ejecting, maybe there should be some kind of localization section in README?
littlee commentedon May 9, 2017
+1 Loooooooooooooking forward to it
gaearon commentedon May 9, 2017
I agree this is something we’ll need to address.
mifi commentedon May 15, 2017
See also #1227
Ayc0 commentedon Sep 23, 2017
what could be the specs of our support for i18n ?
torabian commentedon Sep 25, 2017
Is there any dicussion about using i18n vs yahoo internationalization package?
vinhlh commentedon Feb 13, 2018
Just in case, #3675 is merged already, using i18n via a babel macro might be feasible 💃
https://github.com/vinhlh/tagged-translations#via-babel-plugin-macros
arvinsim commentedon May 18, 2018
Any updates on this?
I was looking for a library primarily for translation of text. Formatting of dates, times and numbers, and time zones is also nice but I guess a separate date library can handle that.
I checked out
react-intlandreact-i18nextto integrate into my CRA project without ejecting. But none of them seem to be straightforward solutions.stunaz commentedon May 19, 2018
Why? I use react-i18next with cra without ejecting and have NOT encountered any issues
lifeiscontent commentedon May 21, 2018
yeah, react-i18next is great!
lifeiscontent commentedon May 21, 2018
there's also https://www.npmjs.com/package/tagged-translations
webOS101 commentedon Jul 18, 2018
We have @enact/i18n which uses iLib under the hood. It's a very comprehensive set of tools for i18n. We have a webpack plugin that handles some of the packaging issues when dealing with i18n. All that is available on npm with an Apache 2.0 license. We'd definitely be interested in seeing if there are ways we could work with the community to make this an option for CRA.
For our own apps, we have a cli tool inspired by CRA and preact-cli that is pre-configured with the plugin.
evdama commentedon Oct 4, 2018
we've switched from react-18next to https://github.com/lingui/js-lingui
bundle size is now less than 15% to what it was with react-18next
speed increased about two orders of magnitude compared to before because translations are compiled down to pure js functions
uqee commentedon Oct 11, 2018
@markusgattol did you eject to use their webpack plugins?
anthony0030 commentedon Apr 11, 2019
Is this issue dead?
jeffsheets commentedon Apr 11, 2019
If it helps, here is the cleanest pattern that I could come up with to add i18n without ejecting:
Use
react-intlwithreact-intl.macro, and then havereact-intl-translations-managerto manage the transalation files.Here's a gist: https://gist.github.com/jeffsheets/b465a174eaccd7bd81c075964c0a9c5d
And blog post with more details: https://objectpartners.com/2019/04/03/translate-create-react-app-with-react-intl/
AlexMost commentedon May 1, 2019
ttag library allows you to implement localization without eject. You have an option to precompile translations right into the bundle or to apply them at a runtime:
Official doc - https://ttag.js.org/docs/create-react-app.html
medium article - https://hackernoon.com/simple-i18n-for-create-react-app-with-ttag-4c2892343201
naeohmi commentedon Feb 20, 2020
This is an important issue, I propose we add an additional page to the
create-react-appdocumentation. Something like this:To help provide guidance on how best to include Internationalization and Localization support within the
create-react-appcontext.We could compile many of the recommendations from this thread in a clear and easy to consume way - to make the process of including i18n easier for folks. I think this would be very useful for the community and am happy to help write it up. 🌏 🌍 🌎
ahmedosama5200 commentedon Sep 13, 2020
Any recommendations on what library to use for internationalization ?
Vovan-VE commentedon Sep 16, 2020
@ahmedosama5200 ,
i18next+i18next-parser. For my own small search in mid Jan 2020 this was the only solution supporting TypeScript on both sides (provide i18n and extraction from source code) without dark magic, hacks or similar.Extra requirements in my search was ICU support (
i18next-icu) and separate untranslated bundles from translation files (i18next-xhr-backend).ahmedosama5200 commentedon Sep 20, 2020
What about react-int and linquijs ?