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.
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.
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.
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.
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.
Try for a global synchronized release if you can get teams to commit to a lockdown date that allows adequate time for translation and LQA to be completed. If that’s not possible, the soft launch approach is a viable Plan B.