Localization Workflows Leveraging Transifex Native: 3 Uses Cases

Teams and companies using Transifex Native to take their content global are leveraging various types of localization workflows. The type of workflows used of course depends on a range of factors — from the inherent infrastructure that each company has to the way specific teams internationalize their code, and of course, the target languages and markets.

In this post, we break down some of the most popular use cases of how developers and localization teams can build their workflows using Transifex Native. (And a quick note before we dive in! Make sure that you have internationalized your code in a manner that is common across workflows. To help you out, we’ve created resources for internationalizing this code — from Django to gettext and more, our documentation homebase has you covered.)  

1. Working with a git service

 The rule of thumb for teams using a git service is to have a single devel branch to pull source strings from. Once a branch is merged over the devel branch, we recommend using an automation tool like Jenkins to push source content to Transifex.

New source content will be appended on Transifex FILELESS resource and will be available to translators and localization community. Translations are made available once they are added to a string. To have a QA check on delivered outcome of translations, make sure to test run your application on a beta server before releasing devel branch! (To get rid of obsolete strings with this method, use a purge option; and if your devel branch is your source of truth, then this will not be an issue.)

2. Multiple developers working in parallel on different branches

 Global teams means global collaboration, which results in this popular use case of Native workflows. With Transifex Native, developers can now push the content they are working on in parallel without losing any context. In short, Transifex Native enables you to create a case for one developer and then all developers can follow a similar flow. Here’s a run-down of how this works, when two developers are working in parallel: 

1. Developer A: One developer is working on her code parts, localizing content following Transifex Native rules and ICU syntax. (Note: Currently Transifex Native SDK does not support branch as metadata information, to have this data available in Transifex application please add as tag).  Once content is considered stable for localization she can push content to Transifex using the command line interface.
2. Developer B: The other developer running the application on localhost can get the current version of translation, simply by being connected to the internet. (Note: Due to the way translations are currently served, there is a slight chance that some translations will be out of sync. To force a sync, you can simply use the available command).
3. OPTIONAL: If you have a specific flow that you want all newly introduced strings to be localized before merging a branch, you can use a combination of tags and API calls to check localization status for branch content by following four simple steps:
   1. Assign a tag to branch strings in code, e.g. a tag named “feature1”
   2. Use the resource string API v3 endpoint to get all source strings with the specific tag, in above example: resource_string?filter[tag][all]=feature1.
   3. Use the resource translations API v3 endpoint to get all translations per locale for strings with specific tag, e.g for French (fr) resource_translations?filter[tag][all]=feature1.
   4. You will then need to check if there are no empty results of step c, meaning that translations are completed.

3. CI/CD development with progressively enhanced localization 

One major benefit of Transifex Native is the ability for localization to be progressively enhanced without the need for code re-deployment. This means that you can go live fast with a low quality of translations in your target languages and have your translation team progressively enhance the translation quality on the go!  Here’s some of the key advantages of this feature:

1. Set up an automation script for your developers on their workstations to automatically push new content to Transifex with each commit. Developers also set up a workflow in Transifex to trigger Translation Memory (for autofill tasks) and Machine Translation (for fill-up checks). By enabling both fill ups, you can now easily make sure than your content will always have a translation available.
2. Make translations instantly available to your application, even before code is deployed. This means that the developer can preview localized versions of her code while developing and fixing any issues or communicate these issues with the team localizing in Transifex.
3. Release code without being hindered by localization status. With Transifex Native, your localization team can start improving translations and errors found on the application. New translations will be available in your application as they are updated in Transifex, meaning no need for additional code release.

DISCLAIMER: Transifex Native makes sure that your application runs smoothly at all times. If despite all checks a translation introduces an error, for example by removing a variable, Transifex Native will fallback to the source content, you can read more here on error handling.

---

With Transifex Native, you can now manage all your global content in one central place and save time on deployment. To learn how you Transifex Native can help you make localization a seamless part of the development lifecycle, visit www.transifex.com/native.