rjwats

react-intl is the way to go I think, 14k min-zipped with tree shaking support. When I remove moment this will be balanced out (moment is big and doesn't tree-shake properly)....

I18n something the framework should be opinionated about really... just not found the time yet. On Wed, Jul 22, 2020 at 10:03 AM Proddy wrote: > thanks. I'll add this...

The framework should probably be opinionated about i18n really, so developers can extend their apps with i18n support without needing to roll their own. LinguiJS looks like a reasonable choice...

Internationalization support is very much a worthwhile feature to add. Fortunately the number of strings to internationalize (assuming you ignore the "demo" project) is pretty small too so the bundle...

LinguiJS is an interesting library. I've not got much to compare it to which is probably the reason I found the workflow to be a little awkward - that's probably...

Ah, they provide a HoC to inject the i18n instance into react components. I missed this last night: https://lingui.js.org/ref/react.html#withi18n Still, some of our language strings are produced in const scope,...

My plan is to explore an alternative library tonight to give the evaluation due-diligence. This looks workable, but need to think about extensiblity for downstream projects still.

Another quick experiment today, this time with react-intl. Yes, the bundle size is higher, about 25k - so not small at all. I can get this down to a net...

Sounds like a plan. The internationalization frameworks can be chunky so a lightweight alternative would be great. Javascripts Intl package has a lot of what you need for minimal i18n...

I've had a look at this i18n library and I think it will be good for the project. It can be added to webpack with CRA rewired and we can...