Building a Platform to Translate DoorDash into Multiple Languages

Creating multiple language versions of the DoorDash app not only lets us offer our delivery logistics platform in more countries, it also removes language as a barrier to communications. A Spanish speaker may place an order on the app to a French-speaking restaurant and have an English-speaking Dasher — our name delivery driver — close the order. The DoorDash app shows each individual their language of choice, helping to facilitate a problem-free delivery. In addition to our U.S. operations, DoorDash currently operates in Canada, Australia, Japan, and Germany, requiring the app to be able to display several different languages. The translation platform we have built has been critical to the success of these international operations, as it sped up our time to launch in non-English-speaking regions by facilitating quick and accurate translations of product text.

Making the DoorDash app multilingual has not been a trivial task. Along with customizable language settings in the app itself, each new language we add requires building a platform on the backend to translate every word shown to our consumers, merchants, and Dashers. Considering the vast amount of text in our product, it's a challenge to ensure everything is accurately translated. Our recent global expansion into new markets has given us an opportunity to build a scalable and developer-friendly translation platform. Among its myriad benefits:

• An easy way to translate millions of strings
• Simplified integration allowing developers to streamline translation of strings to multiple languages 
• Support for a myriad of client types and file formats, giving developers visibility into issues reported by translators 
• Tools to allow developers to translate strings easily as DoorDash deploys entirely new languages 
• Guardrails and reporting to ensure quality control  for all new translations

Internationalization (i18n) and localization (l10n)

Internationalization — referred to as i18n because there are 18 letters between the i and the n — is the process of developing software that supports local languages and cultures. Localization — or l10n — adapts software for use in specific regions. Both processes go beyond simple translation from one language to another; developing software that takes into account social and cultural norms also plays a critical role, as does sensitivity to differences in the same language between different regions. For example, Spanish spoken in Mexico is quite different from Spanish spoken in Chile.   

Good internationalization and localization, including high-quality translations, ensures a consistent brand voice across the platform, among other key benefits. 

Challenges of building a translation platform

DoorDash platform developers create strings based on U.S. English. As the platform expands into new markets, all strings across every product must be translated in bulk to the regional language or dialect. The strings either can be in static files across multiple formats such as Android, iOS, or JSON, or they can be dynamic strings that can be added/modified without needing a code deploy. Developers need an easy way to add/modify strings and get translations for supported languages. Simultaneously, product managers need a way to audit the translated results to ensure a high-quality product. 

Outlining the translation flow

Any text displayed to a user in the DoorDash app is stored as one or more static or dynamic strings in our systems. Understanding both types of strings is an important part of showing each user text that they can understand.

Static strings are key-values organized into a set of files, one for each target locale. The actual code then uses keys to look up the text to be presented instead of using the text embedded in the string. Locale settings on the user’s device and their DoorDash account determine which file should be used to present the final text. These files — including Android strings and iOS strings —  are modified using change requests, which need to be merged and deployed in order to take effect. We will discuss how our system handles static strings, later in the post.

Dynamic strings can be translated without the kind of code deployment required by static strings. The dynamic strings service stores translations in a database; strings can be sent over for translation using a dynamic strings UI or via an API call. The dynamic strings service also has a dynamic strings client used to continually ask the service for new translations. Services that already have a UI to create new strings use APIs provided by the dynamic strings service, while services that don’t have a UI use the dynamic strings UI. In either scenario, the service does not need a code deploy when requesting a translation. Just like static strings, the locale settings on the user’s device and DoorDash account determine which translated string is displayed.

Translation platform architecture

In Figure 1 below, the entire i18n platform at DoorDash which includes the Static Translations Service and the Dynamic Strings Service. The  i18n Platform Clients interact with i18n Platform libraries which include libraries for “Names”, “Currency” and “Date” the use cases for these libraries is explained in detail in an earlier blogpost Overcoming Localization Challenges for International Expansions. In order to manage dynamic strings, the i18n Platform Clients interact with the Dynamic Strings Client which in turn interacts with the APIs of the Dynamic Strings Service (DSS). Static Strings are authored in source control and translations for them are managed by Static Translations (STS) through PRs. Both STS and DSS interact with the APIs of the Partner Translations Management System (PTMS) and abstract out the i18n Platform Clients from interacting with them directly. PTMS has glossary, style guides and context capture that our language experts and product managers can define to maintain consistency in DoorDash’s tone, voice, and style.

The static translation service, or STS, is a backend service that is integrated with client Github repositories to provide developers with string translations as commits in their pull requests, or PRs, simply by commenting “translate apply” on the PR. The service also provides the translation job status and reports any issues raised by translators. STS interfaces with the APIs of a translation management system we partner with to abstract the process of obtaining translations.. Developer repositories integrate with STS by installing a Github app configured to call STS whenever there is any activity in the repository. Such activities include new commits or comments used by STS to manage translations on PRs.

Examples of STS implementations 

We developed STS when we first launched DoorDash in French and subsequently used it to translate the DoorDash platform into Spanish. For our Japan launch, we added guardrails and checks on repositories to prevent PR merges containing new or updated strings without translations, as well as modifications of translated string files. These guardrails were put into place to ensure high-quality translations, discourage machine translations, and maintain consistency in DoorDash’s tone, voice, and style. We also expanded the “translate apply” command to let developers use a single command to request bulk translations for a given locale, streamlining support for new languages and enabling developers to request missing translations more easily. We also built a reporting tool to monitor the repositories continuously and ensure there were no strings without corresponding translations.

How we use dynamic strings 

Not all strings are powered by static files, creating a need for services and systems to get translations for strings without a code deployment, including some of the dynamic strings shown on the homepage of the DoorDash app. We identified this need when we built and launched STS, prompting the creation of the dynamic strings service (DSS) . Like STS, DSS  interfaces with the translation vendor’s APIs, abstracting the process of obtaining translations.

The translation platform’s future  

At this writing, we have translated more than one million strings across four languages (English, French, Japanese, and German) using these new tools while also building a centralized translation platform for use across all DoorDash services. Onboarding a new language once required hours of developer effort, including manually sending string files for translation and then putting the translated files back into repositories. Today a new language can be triggered via a single command in one minute.

There is work underway to unify the STS and DSS codebases and databases to make them easier to maintain. We also plan to add some of the STS features such as guardrails, reporting, and bulk translations to the DSS. Currently, STS clients must wait for translations to be committed to the PR before they can be merged. We are working on allowing clients to merge their PR without translations, then allowing the STS to create a separate PR with translations; extensive reporting will ensure there are no strings with missing translations. As an extension of this, we are exploring moving all the static strings files to a new strings repo and using Git submodules on the client repos to reference those strings. This way, STS can merge the strings directly to the strings repo without needing any developer intervention. 

Many companies build products for users who speak different languages. Most of them start with a manual process to translate strings in their products, which can be slow and error-prone. As products and features expand into new languages, we advise investing in a scalable and robust translation platform such as the one DoorDash has created.