There are several schools of thought about how to manage feature releases across multiple languages. Each has benefits and drawbacks from a project management and customer experience standpoint. Which one will work for you depends on how you manage project timelines and how much thrash you have in the lead up to a major feature release.
Synchronized Global Releases
The gold standard is to launch a new release, along with supporting assets and marcomm activities, in all supported languages at the same time. At Notion, we went with this approach so that our international customers had access to new features at the same time as US customers. This signals to non-English users that they are first class citizens on the platform, and also amplifies overseas marketing efforts.
The downside of this approach is that it requires a lot of coordination between teams, as well as discipline in having a firm lockdown date that allows time for translation and linguistic QA teams to do their work. At Notion there was a lot of thrash as in app and marketing content would be fine tuned and edited up to the day before a release went out.
We worked around this by asking teams to submit draft content well ahead of the release date, knowing that they would make lots of incremental changes. Since the bulk of the translation work was done weeks before, we had plenty of bandwidth to work on incremental updates and their translations.
Soft Launches
Many startups take the concept of agile project management to the extreme, which can make globally synchronized releases hard to manage. An alternative to this is to quietly enable the feature in your supported languages, but hold off on marketing activities in those languages until everything is fully translated and reviewed (typically a few days or a week after the master release).
In app content is usually fully translated long before the release goes out, while marketing and support content often lands late. This approach allows you to make the feature available to customers, while holding off on announcing it until all of the supporting content is dealt with. Since most non-English customers will not be aware of the feature rollout, most of them will find out when the announcement goes out. Early adopters and power users may find out about it through other channels and will be able to use it. This class of user is typically not blocked by missing or not fully reviewed translations.
While this is not quite as good as a global synchronized release, it is “good enough” and is an effective way to deal with thrash and late landing content, which is often an issue at startups.
You can do this by gating language accessibility for a feature with a feature flag or system variable that is updated as languages are checked off as ready.
Language Based Releases
On the other end of the spectrum, new features are gated or blocked until all of the supporting assets have been fully translated and reviewed. This approach may be required if your product is subject to a lot of regulations, or contains material that poses a liability risk if incorrectly translated. Medical devices and pharmaceuticals are a good example of this.
This is not a good approach for SaaS offerings and consumer apps because it signals to non-English users that they are second class citizens. If the service is used by many people within a subscription, this also creates breakage where the feature is available for some users but not others within a team. For example, in Latin America it is common for managers to be proficient in English due to business school experience, while regular workers may not be.
Mitigation Strategies
The fundamental issue you are dealing with is that there is usually a lot of thrash and late landing content changes. There are a few things you can do to compensate for this.
Content Freezes
At some point, ideally a week before the feature ships, you can freeze all content changes. This will give translators and reviewers time to finish their work (as well as QA and other functions). By the time the feature ships, everything will be done or done enough. The only drawback with this approach is it requires discipline. At some companies I worked for, the CEO or product lead would be making changes right up to the day before we shipped.
Fast Follows
If your company isn’t willing to freeze content ahead of a release, you can at least fast follow with translation updates, and probably other minor fixes. If you are using instrumentation and analytics to prioritize work on high visibility prompts and content, the remain issues will affect lower visibility content that is less likely to be noticed. If you are pushing daily releases via CI/CD, you get this for free. Most companies that do this accept some lag in translations since they will be updated quickly.
AI Pretranslation
I am a big fan of fix forward translation, where an AI or machine translation is used as a placeholder until a human translator has time to review, and if needed, edit it. Most AI translations are good enough for temporary risk, and even a so-so AI translation will look better to users than a regression to English.
Front Loading Work
Another thing you can do is to front load work so that translators and reviewers have ample lead time and get the bulk of the content out of the way early in the project. What does this look like in practice?
Content authors can post draft content in the CMS well ahead of the release. Translators can finish the draft, and then when edits come in, they can focus only on what changed.
Designers can use integrations with tools like Figma to translate designs and mocks. These texts will be stored in translation memory so when those messages show up in app strings, the translations will already be ready to use.
Developers can add app strings to the message catalog before they are used in the UI. These messages are often specced out before development work starts, so that’s an easy way to get them into the translation pipeline.
Pro tip : don’t worry too much about re-translation costs. Most edits are pretty minor, so the cost of translating a short prompt after it is edited are minimal, especially compared to the cost of the product and engineering efforts going on around it.
Conclusions
With a combination of front loading, fast follow releases, and AI pretranslation, you can usually get to a state of “done enough” in terms of localization that you can ship a feature in all languages simultaneously.
The one major caveat here is that if you ship infrequently, you won’t be able to fast follow with translation updates. That said, companies that operate that way generally don’t let an arbitrary deadline force a release.
Related Reading
Building For Runtime Localization – this article describes a runtime localization infrastructure that delivers translations “over the air.” This decouples localization from release deployment, and also enables dynamic content that is not defined in message catalogs to be translated.
Analytics : Ranking Strings By Visibility – this article describes how to use instrumentation to prioritize translations and editing for the content that is most visible, so that high visibility / high impact content gets worked on first.
Integrating Your CI/CD Pipeline With Your Translation Pipeline – this article describes how to integrate your development and release pipeline with a translation management system to implement continuous localization.
Combining Human And Machine/AI Translation – this is an example of where AI translation can help fill gaps in translation coverage until human translators have time to review and edit translations.
Upstreaming : Treating Localization As A Forethought Instead Of An Afterthought – managing feature releases across languages is a concrete example of where upstreaming translation work enables you to ship across languages at scale.
Choosing Language Service Providers (LSPs) – one of the key criteria in choosing language service providers is what SLAs they offer. A good LSP will use AI to accelerate delivery in the context of a fix forward workflow that delivers ok translations immediately, followed by reviewed and edited translations within 2-3 days.