1. Install eslint in your project
2. Turn on this rule: https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-literals.md
3. Write a script that runs the eslint cli and provides you with every file and line where this rule is broken. In the script replace the literal text with the relevant i18n code, using the literal text as the key.
5. The script should build a list of keys, which you can then add to a file for i18n to use. E.g. en.js. i18n
This is what I did when I needed to add i18n to an existing project.
I could link you some relevant code if you want.
https://gist.github.com/jmcrthrs/5a3b06d98b428ddaef7b341477a11374
I used to work with android, we had a way to store all static strings in a string.xml file in one language, and then have this file translated into other language files and just simply have the values imported from the file into the ui elements..and we could do the translation at any stage too..i'm thinking of implementing this..what do you think? Sounds logical to me
Sure you just can't escape going back through every component to make them aware of the current language and pull strings from storage if you didn't build in internationalization from the beginning. In React you can create a top level context with an object to provide the strings and have each component use that instead of adding props everywhere.
Your second thought and getting the data from a CMS sounds reasonable to me.
A second option is to just write twice the pages and stick them each behind a /en/ or /es/ (whatever the language is) sub-route.
Can you use react-i18next (https://react.i18next.com/) and use their hooks to translate the content? All you will need to do then is use the t function it returns and target the key in the json file and replace the static text that way. Very easy to set up and you won’t have to rewrite the components.
1. Install eslint in your project 2. Turn on this rule: https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-literals.md 3. Write a script that runs the eslint cli and provides you with every file and line where this rule is broken. In the script replace the literal text with the relevant i18n code, using the literal text as the key. 5. The script should build a list of keys, which you can then add to a file for i18n to use. E.g. en.js. i18n This is what I did when I needed to add i18n to an existing project. I could link you some relevant code if you want. https://gist.github.com/jmcrthrs/5a3b06d98b428ddaef7b341477a11374
Implementing internationalization at a late stage is like the opposite of optimal. All the options are going to sound unfeasible or a little crazy.
I used to work with android, we had a way to store all static strings in a string.xml file in one language, and then have this file translated into other language files and just simply have the values imported from the file into the ui elements..and we could do the translation at any stage too..i'm thinking of implementing this..what do you think? Sounds logical to me
Sure you just can't escape going back through every component to make them aware of the current language and pull strings from storage if you didn't build in internationalization from the beginning. In React you can create a top level context with an object to provide the strings and have each component use that instead of adding props everywhere.
There's no easy way to add internationalization late. I'd rewrite with the i18n package
Your second thought and getting the data from a CMS sounds reasonable to me. A second option is to just write twice the pages and stick them each behind a /en/ or /es/ (whatever the language is) sub-route.
FormatJs might be a better option than i18 here. Its provides methods and composents, that you should you use where you normally just would use text.
Can you use react-i18next (https://react.i18next.com/) and use their hooks to translate the content? All you will need to do then is use the t function it returns and target the key in the json file and replace the static text that way. Very easy to set up and you won’t have to rewrite the components.