React i18n: A Study with Data-backed Benefits of Transifex Native

In this post, we will try to cover all the aspects of React i18n, comparing two frameworks, Transifex Native and React-i18next. We will steer away from describing the difference in coding methods and focus on the workflows that each framework enables.

Let’s have a hypothetical single-page React app to aid us in this journey. We want to localize our application to 5 languages. Our application is currently holding approximately 150 unique strings.

The rest of the article has a section for each discrete workflow step related to localization that is very common when you localize a web application. 

Installation

Installing any of the two frameworks means installing a set of packages to your application. After that, you will need to set up some configurations in your code.

For Transifex Native React, you will need to create a Native project in Transifex and get the required credentials for exchanging content for localization. This will be the base for all your global content.

Internationalization

With React-i18next, you will need to add the string mapping function on all your codebase, that is, the T function. After that, you will need to store the list of strings you are mapping. You can do this either on the config file that React-18next offers or in an external JSON file. To do that, you will need to keep two files open. Then, copy-paste the content from your T function in your code to the list of strings. When you complete the process, you will have your code internationalized with React-i18next. You will also have an additional file containing all your app content in the source language.

With Transifex Native, you will need to add the string mapping function on all your codebase, the T function.

Analysis on Internationalization 

Creating a localization file, you need an average of 5 seconds to copy-paste each string to a new location. Therefore, for an application with 150 strings, you will need an additional 12 minutes to complete your localization. Adding the extra 2-5 minutes to cross-check for typos increases the internationalization phase time to about 17 minutes. Additionally, the extra JSON file for the source language adds to your code an extra file of approximately 5Kb.

Sending Content for Localization

With React-i18next, you will need to send the JSON file containing your string in the source language to a service, Transifex or another TMS, or a vendor to localize your content. You can do that manually or build automation that will automatically upload the latest JSON file to your service.

With Transifex Native, you can send content for localization to Transifex using a command-line interface that will automatically detect content from your code and push it to Transifex.

Analysis on Sending Content for Localization

For the React-i18next case, you have two considerations. 1) The time needed to build and debug an automation script. 2) The additional time needed to manually upload your JSON file to the service of choice. In the case of the automation script, you will need to account for building and debugging that script. If that process is not straightforward, you might want to skip it and upload it manually. Manual uploads are more time-consuming. This is because you have to get the latest file from your repo, enter your TMS, and upload the file. API upload is faster as long as you do not break the work of other developers.

On average, a file upload takes 2-5 minutes if done manually, considering any prior communications needed to perform the upload. If done automatically, it takes about 1-2 hours to build and debug the script. It could take additional time for updating the script to perform any manual workflow modifications.

QA Testing Localized Versions of your Application

With React-i18next, you will need to get the latest localized JSON file from the service you use for localization and add it to your code. By running your code and switching to the language of choice, you can proceed and check for any errors. If you find errors, you will communicate with your localization team and wait for a fix to restart the process.

With Transifex Native, you can simply run the application and switch to the language of choice. A secure external service called Content Delivery Service stores all translations. The translations are updated hourly, with new translations coming from the Transifex TMS. So, the latest translations are available to your local environment every hour. With an extra pull command through your CLI, you can be sure that your local application has the latest translations. If you find errors, communicate with your localization team and wait for a ping to pull the fix from your CLI. 

Analysis on QA Testing Localized Versions

The time it takes to download a JSON file from another application – either by visiting the application or through the API – tends to accumulate the more you QA-test your application. The safest way to counter that time is by adding a separate QA test when you complete your development work. With Transifex Native, new translations are available hourly directly in your local environment, so you can QA-test while developing. Since translation updates are available hourly, you can work in parallel with the localization team and save some time.

Working in Parallel with Other Developers: Branching

With React-i18next, you update your version of the JSON file with any new strings you introduce on your branch. Since other developers do the same thing for their strings, you will end up with different versions of the JSON file on each repository. To proceed with localization work, you will:

• Either need to merge on a specific branch and then send content for localization (e.g., when you merge something on the ‘devel’ branch, you get the created JSON file and upload it to the TMS)
• Or, create a script that each developer runs on their branch to find the new content in the JSON file and push only that content to your TMS.
• Finally, developers can push their JSON file version holding the strings if your TMS supports localization branching.

In all cases, the localization team will start working on new content as it is added to your TMS.

With Transifex Native, each developer can push content using the CLI command from their branch. They can also add an extra tag containing information about the branch they are working on. If two developers send the exact content with a different branch tag, both tags will be available in Transifex TMS.

Analysis on Working in Parallel with Other Developers

Coordination of the right JSON version is important if your development team uses React-i18next over their branches without a TMS branching feature. Overwriting a source strings file and missing some strings of another branch means losing the work done on that string. Translation Memory will kick in once you restore the string. However, you will miss any metadata stored on that string as comments, translation history, and issues. Finally, the cost of resolving any overwrite issues is on the scale of hours. This is because you will need to communicate across developers and compare different versions of the JSON files used.

The safest route is to start localization from a common branch to which everyone merges. Still, this workflow has the drawback of offering less time to the localization team to do their work, as developers and the localization team cannot work in parallel. Additional delays will be introduced for QA testing, as this work is also done once localization is complete (check the section above on QA testing).

Managing Changes on the Source Content: Copywriting Fixes

With React-i8next, you will need to update the JSON file holding all the source content. That will work in the best case if you are using keys in your code. React-i18next looks at the JSON file to identify which string to display in your app. Therefore, the new value will override the text written in your code files. If you are using the source text directly on your codebase, you will need to apply the new content on both the source and the JSON file. When new changes are complete, you will need to update your live application with a new deployment.

With Transifex Native, Transifex TMS handles all copywriting changes. So, the developer does not need to make any changes in the code or redeployments.

Analysis on Managing Changes on the Source Content

Managing copywriting changes on a code level without Transifex Native requires at least a second QA pass from the team responsible for the application messages (Design, Product, or Marketing). Applying a copywriting fix then has 3 steps:

1. Identify the issue, which usually comes from the team responsible for messaging and tone. This is the starting point of the process and doesn’t take any time
2. Communicating the fix to the development team to apply the change. This is usually the most time-consuming step, as copywriting fixes are hardly prioritized over bugs or feature development. Based on experience, this step might take 1 minute to 1 month, depending on team availability.
3. Releasing the fix to the live application from the development team. Usually, this step is instant and comes right after step 2. Occasionally, there are more delays introduced having to do with deployment schedules.

Clean up Unused Strings from your Localization Process

Application development is tightly related to changes. New features are introduced, existing ones change. These changes reflect in the text used in the application, with new strings added and some strings removed or altered.

With time, this can become a big issue for evolving applications. If your team does not manage strings that they find in your TMS for localization, you will spend resources on unused content, also called “zombie content.”

With React-i18next, you can address that in two ways:

1. If developers delete a string in the codebase while developing a new feature, they will visit the respecting JSON file and remove the string, preventing a “zombie content” entry.
2. Periodically, a developer checks if all JSON file string entries are used in the codebase. If a string is not used, the developer proceeds to delete it from the JSON file.

With Transifex Native, you add new strings to your TMS via a push CLI command. This means that the default behavior is creating “zombie content.” Any strings that were previously pushed to your TMS are persistent. This behavior is really useful when developers work on branches, yet very problematic when identifying “zombie content.”

To remove all “zombie content,” you can do the following:

1. Communicate with all your developers that you are proceeding with a “Zombie content” clean-up, and they should avoid using the push command
2. Head to your production branch, holding the codebase that reflects the most updated state of your application, and use the push command with the force parameter. This command will update your localization content to include only strings found on the current version of the codebase, removing any unused content.
3. Once done, inform your development team to resume pushing content for localization from their branches.

Analysis on Clean-up of Unused Content

Manually identifying unused “zombie content” in an app using localization files is a tedious and time-consuming task. You need at least 10-15 seconds to search across the codebase to check each string. If the string is actually “zombie content,” you need to identify and delete it from all JSON files using it – for source and all translation languages. A rough estimate for cleaning up a single “zombie string” across 5 translation files and one source file is a minute. For example, an application with 200 strings and an unused string rate of 10 % – approximately 20 strings – means 50 minutes just to search if each string exists in the codebase and an additional 15 minutes to delete “zombie strings” from the JSON file.

React i18n with Transifex Native: Closing Notes

All the sections above cover a big portion of localization scenarios you will encounter with real i18n. These scenarios span from initial, one-off tasks for installation and configuration all the way down to daily usage and maintenance. Scenarios are not sequential. Under normal circumstances, you will need to mix and match between them or even repeat some many times.

Each scenario contributes, by a small or bigger factor, to your daily workload. With the information provided, you have a high-level sense of where effort is needed for each framework. You also know which points could secure more time to work on what you and your team deem important for your application.

Further reading: 

• React Localization With Transifex Native: All you Need to Know
• From react-i18next to Transifex Native: Migration Guide