Behind the Screens: The Art of App Publishing
We’re here, we made it – welcome to the final instalment of our three-part series on app localization. In this piece, we’ll be talking translation pipelines and translation management systems (TMS), before we take the plunge and hit “publish” on our global app. Disclaimer: unfortunately, it’s not quite that simple.
If you’re wondering what on earth you’ve entered into, we’d suggest tracking back and having a read over parts one and two first.
The Translation Pipeline
The process of automating the flow of translatable strings from software developers to linguists, and back, is often called a “translation pipeline.”
As developers write their code, they save it into a code repository (sometimes called a “repo” for short). As new strings are saved to the repository by the developers, automated processes pull updated strings files into a translation management system (TMS). This is usually the point where client-side localization teams, language service providers (LSPs), and individual linguists get involved, because the new strings will create a new job in the TMS that needs to be translated. LSPs will pick up the translation jobs and distribute them among their linguists for translation and review. Once the linguists publish their work in the TMS, the translations of the strings are saved back into each language’s resource files, and then those files are automatically pulled back into the code repository to be included with the rest of the app. This process repeats as new strings are added and translated, reducing the manual work for everyone involved in the localization process.
Cutting a Build
If you’ve ever worked as a linguist on an app localization project, you may have encountered a scenario where you updated a translation in the TMS, but the old translation is still appearing in the app. The reason this might occur is because the translation that you updated has not yet been included in the latest release of the app – just because something is coded into an app it doesn’t always mean it’s available to the public to download.
Software developers need to periodically put their code together into a complete package called a “build.” You may hear people call this process of creating a new packaged-up version of the app “cutting a build.” To be made available to the public, the build needs to be released to the App Store (iOS) and Play Store (Android). When a new build is submitted to these app stores, they each run quality checks on the files to make sure they meet certain requirements and don’t contain any malicious code. Once an app passes the checks, it is made available as an update in the store, where users can then download the latest version.
Inside the Sprint Cycle
There can be a number of steps involved in creating the new build, so to understand why translation updates are not live to the public immediately, it helps to understand how engineering teams tend to work. Engineering teams often structure their workload into short cycles called “sprints”. They are constantly iterating every sprint, adding new features over time as they receive feedback from their users and stakeholders. The cycle of releasing new builds to the app stores usually corresponds to the end of a sprint cycle. Leading up to the release, there is often a period of “code freeze” where none of the content that will be included in the newest build can be changed, to allow time for testing. Companies working on a continuous localization model will usually set their translation deadlines based on this cycle of code freezes and scheduled releases, to make sure that the latest and greatest translations are included in each release.
And there you have it – we’ve reached the end of our journey on app localization. We hope you’ve gained some tips for preparing your content for an app environment, a few new techy terms, and all in all a little more knowledge of what goes on behind the screens.
Have you got an app you’d like to take around the world? Get in touch with us to hear how we can help.