Shorten localization turnaround time using connectors at design level

In a previous post, I talked about how connectors with design tools (for example, Figma) can be a great ally for the localization team and create truly global experiences for customers. These connectors can help teams reduce the turnaround time of the translation process. Let’s dig a bit into that!

I will start by explaining a bit about how the current process is usually implemented and how we could integrate this.

Current common process for a new product:

• Designers and copywriters get together and decide how the experience should be (other stakeholders can be involved, for example, Product Managers, the Accessibility team, or the Localization team).
• After the design is completed and approved, the development team will start working on it, usually in a different repo (for example GitHub) than the one for the localization pipeline, so the localization team doesn’t receive content or files that are not finalized.
• When the code is almost final and ready to be merged into the main/develop GitHub branch, the localization team will detect this and start working on it. They will need to add context information and instructions (especially for content that might not be 100% clear and can lead to mistranslations) before sending the content for translation.

As you can see, with the current process, the localization team cannot start working on the new content until the development team has something merged into the branch the localization team is monitoring, OR some type of manual step needs to be taken (like, for example, gathering all the strings in one JSON file or spreadsheet and working with that in the Translation Management System [TMS]).

This is usually one of the main reasons why teams want to introduce machine translation into the UI product workflows. Not just because of the costs, but because of speed (for example, they want to release the product 5 days after the code is completed and tested).

Proposed process for a new product:

The process I am proposing is to move the localization process upstream and, thanks to the connectors, start the localization process at the same time as the developers start working on the code. In this way, the localization team has more time before the product is scheduled to be released. Then, when the developers are done with their part and merge the code into the relevant repo, the TMS will recognize that content as already translated, and it can be delivered back with a quick turnaround time (from immediate to 3 business days) and with ensured quality.

Obviously, this proposal also has some challenges:

• The content has to be final when the designs are completed: We have to ensure that the content appearing in the designs is mostly the same as the one the developers will include in their code. This ensures that the TMS gets 100% matches, and the content can be quickly reviewed and published.
• The keys won’t be the same¹: From my previous experience using the Figma connector with Smartling, it seems that the keys associated with the content to be translated are generated considering the place and component being used in the design tool, which creates very long keys that are not too descriptive. As I mentioned before, this is not a huge issue since that content will be a 100% match in the TMS and should be fast and cheap to retranslate. However, there are tools like Figma where you can create variables associated with a particular piece of text. I believe that if any connector would allow the variable name to be used as the key instead of the key that is automatically generated by the system, that would speed up the process even more. The main reason is that if the content generated by the development team matches with the variable and content in the TM, it could be considered as an ICE match by the TMS, which would allow immediate translation without the need for further review as soon as the content is detected.
• It’s not possible to generate proper pluralization: This is one area that I see as hard to address. However, I don’t consider it a blocker since this scenario does not appear too often. The partial solution that I see is to ask the designers to create scenarios for singular and plural cases. After those are translated, then when the content is merged by the developers implementing proper pluralization, it should be easy and fast for the translators to update the different translations using the matching from the previous time.
• What if we need a placeholder in the strings? The connectors, like the one from Smartling, allow setting certain types of placeholders (for example, {{username}}), so the placeholders can be generated as they will appear in the actual resource file.

The last three points might make you wonder (especially if you are a developer), what is the best way to generate a resource file? What’s the best format? If you are thinking that, you are in luck. Soon, we will talk about that in an upcoming post. Please come back and check it out!

Thank you very much for the time spent reading this. I hope you enjoyed it and you learnt something. If you have any questions or suggestions, please contact us here or through LinkedIn. 

I look forward to hearing back from you!

1. A similar approach involves using an integration like Frontitude, which is working on having integrations with different TMSs or you can use their webhooks. However, to get the context, you must work directly from their integration, not from your TMS. If you use their webhooks or integrations with your TMS, I’m not sure if it’s possible to provide that context automatically. ↩︎