Open cKellyDesign opened 4 years ago
@cKellyDesign do you have thoughts on:
- What are the most useful things to extract from Reveal?
a) using Google i18n JSON format for storing translations b) using placeholders to populate dynamically translated strings
- What are some pitfalls to avoid?
a) testability - it was hard to test that all strings were being translated correctly
- What would you do in the 2nd iteration to make it better than what we have in Reveal at the moment?
a) save translated strings to a redux store so they can be updated (by toggling the language without reloading and without redeploying)
save translated strings to a redux store so they can be updated (by toggling the language without reloading and without redeploying)
@cKellyDesign do you think that it is possible and desirable to save just the selected language instead of all the strings?
@moshthepitt yes and mega-yes! This would probably require a slightly different usage from Reveal's translate utility. If we are updating a single prop in the store, then instead of translating them all once at compile-time (like Reveal), I think the component displaying the strings would need to be responsible for translating the strings depending that prop.
Found this which looks pretty sweet https://github.com/Automattic/wp-calypso/tree/master/packages/i18n-calypso
Is this a new feature or an enhancement? 📦 New Package
Is your feature request related to a problem? Please describe. Nope, just for standardization, reusability, the kicks, and eventual need in new projects
Describe the solution you'd like As a developer I would like to have a standard method of supporting internationalization that I can install, configure, and execute in React apps.
Additional context An initial implementation of i18n was developed for Reveal with its' own successes and pitfalls, this package should be a second iteration.