Challenges of I18n — Part 2

The second part of a two-piece write-up on the internationalisation of large-scale applications in hyper-growing engineering companies.

Quick introduction

This is the second part of a two-piece write-up, if you missed the first part feel free to take a minute and give it a read here, it will help provide context on the topics approached below. You can also read the next chapter which contains a summary of how we left things off at the end of the first article.

Picking up where we left off

In the first article, we went over our challenges and decisions to implement an initial version of the internationalisation mechanism for all the customer-facing and some internal tooling apps in a large-scale hyper-scaling company. By the end of it, this was the translation process that we had integrated into our deployment pipelines:

In the approach above, when a feature added new strings that required translations, the original strings (in English) would be sent automatically to the Translation Management System, and the deployment process would be blocked until translations had been completed. When that happened, the translated strings would be sent back to code repositories and merged with the initial feature branch, which would then be ready for deployment.

In this second part, we’ll delve deeper into each of the iterations this process went through, outlining the impact of each change on the quality, speed and costs of the entire translation chain.

An agile mindset

As in all agile projects, our main initial focus was ensuring a reliable and stable translation process that was flexible enough to allow for future improvements. This was key to the next steps where the main focus was improving the overall speed and quality of the translations, as well as the developer experience when interacting with the process.

Internal reviewers in the translation process

One issue that we had initially was that some translations were made with no context, and naturally, the result of these was not the most desirable. A simple example of this is the word “Home”, which might appear in the context of a delivery, in which case we’re talking about a physical place, or it can appear as a link to a section of the website, in which case it probably means the homepage, and should be translated accordingly.

In order to mitigate the issues caused by the lack of context provided to the translation agency, we have decided to introduce internal reviewers in the translation process (one person per language), this person would be someone who natively spoke the language in question and was familiar with the proposition. This helped us ensure that the translated content was accurate and consistent with the original source text, which can be especially important when translating technical or legal documents/pages, where even minor errors can have significant consequences.

Internal reviewers also helped identify and resolve cultural or idiomatic issues that may not be immediately obvious to the translator, ensuring the translated content was appropriate and easily understood by the target audience all this while providing feedback to the translator on their work, which over time helped improve the quality of translations and reduced the need for post-translation adjustments to strings.

At this stage, our translation process looked like this:

Ensuring alignment between engineers and stakeholders

In such a large-scale project as the one we’re working with, small things can have a large impact if not communicated properly and on time. In the initial stages of the process, we noticed that some teams felt lost and didn’t know exactly what to expect from the translation mechanism, which ended up resulting in them doing things in a non-standardized way (think of people sending spreadsheets with strings directly to the translation agency to ensure priority on their translations).

This kind of desync ends up slowing the entire process down and jeopardizes some basic foundations upon which it relies. So to ensure alignment between the tech teams and everyone involved in the internationalisation effort, we applied the following mechanisms:

• Creation of I18n steering committee
  To facilitate discussions and decisions around Internationalisation strategy, we decided to create a committee of people responsible for different areas of the process, this allowed us to quickly find solutions for various problems and agree on strategies to follow, which ended up being a key part of the process. This committee included engineers, content designers, translation reviewers, as well as other coordinators that were monitoring the process.
• Regular meetings with each engineering team
  To tackle issues regarding the lack of clarity on the engineering side of the process, we decided to hold a meeting with each of the tech teams that were using this system to demo how the integration with the TMS should work, and how to deal with some edge cases. This ensured not only alignment in the process but also surfaced some great suggestions from the engineering teams for potential improvements to the system.
• Creation of an I18n tech support channel
  One of the results of the item above was the creation of a channel where engineering teams could request help regarding the integration of their code repositories with our TMS. This was useful to centralise this kind of request and also to share knowledge between the teams so that they could see each other’s doubts and questions answered.

Leveraging AI for machine translations

As the expansion of the business moved forward, we kept facing bottlenecks with the throughput provided by the translation agency, meaning that developments were sometimes stalled for days before they got translations finalised and were able to move on with their respective deployments. In order to tackle this issue, we decided to use artificial intelligence to perform a first pass on translations. At the moment, there are multiple possible providers for this kind of service and some of them will even keep the same context throughout different translation jobs. This means that you could keep a consistent message and tone of voice across the website. Of course, using AI for website translation also has some limitations, as AI may not always understand the context or cultural nuances of a particular language, leading to translation errors.

In our case were able to move forward with this approach since we already had internal reviewers in place to make sure all translations met the quality standards required to be shown to our customers. Some popular AI translation tools are Google Cloud Translation, DeepL and Microsoft Translator.

This shift in the process drastically decreased the time features took from design to production while also reducing costs in the translation process by over 80%.

Deploying pre-translated text to test environments

One other potential avenue for improvements would be to allow deployments into test/QA environments with machine translations so that engineers could validate the changes earlier while reviewers verified the translations in the TMS and fixed any minor issues that might surface.

With this process, the translation/deployment workflow would look like this:

The process above would now only be blocked on the step to deploy to production, everything else could be done in parallel without any delays introduced in the CI/CD process.

Translating at design time

Another alternative we have investigated was to perform translations at design time. This approach would bring some benefits like ensuring that translated content fits within the website's design, before sending those designs to the development phase. This would make adjusting the content to fit each section a much smoother process and decrease the time spent adjusting the website structure after translations are finalised.

This approach can be even further streamlined by integrating the TMS with the design tools. One example of this is the integration available between Figma and Smartling, where designers can request translations inside Figma, and the strings are then sent to the TMS (Smartling) and can be translated using the workflows above (with AI or Human translations + an internal review stage).

This approach might work very well for some scenarios, so give it a good thought to understand if it fits your requirements and is better than any of the above we’ve already gone through.

Final Remarks

In conclusion, internationalising an e-commerce platform requires careful consideration of multiple factors, including language and currency support, localisation of content and images and compliance with local regulations and laws. By adopting a structured and systematic approach, it is possible to create a platform that is accessible and usable by a global audience, and that provides a seamless and enjoyable experience for users in different regions and countries.

There are many different approaches to internationalising an e-commerce platform, and the best approach will depend on the specific needs and requirements of your project. Whether you choose to use pre-translated content, machine translation, or a combination of both, it is important to regularly review and test your internationalisation implementation to ensure that it continues to meet the needs of your users and customers and don’t be afraid to experiment and try new things.

We hope the information presented in this article will help you in your internationalisation efforts, and that you will be able to create a successful and thriving e-commerce platform that serves a global audience.