Scaling Translation Operations Across 72 Languages

Embark is a language-learning app used by missionaries. It includes words, phrases, lessons, audio, and quizzes across 72 languages.

When I joined the Content Team, each language had its own Google Sheet. The sheets had different columns, tabs, formulas, and instructions. A normal project required someone to request a file, wait for a developer to create it, copy it into a shareable folder, train a contributor, follow up, and import the finished work.

The process was slow and easy to break. IDs or columns could go missing. Teachers often lacked enough context to translate a word correctly. Managers also had no simple way to see which languages were moving, which contributors had stopped, or which finished work still needed to be imported.

I was hired as a content team member, not as a developer. I started by fixing the parts of the process that frustrated me most. I improved the spreadsheets, showed the results to my supervisor, and earned more freedom to work on technical projects.

Over time, my role grew into product ownership and hands-on development. I:

• Found and defined workflow problems.
• Met with two main stakeholders and balanced their priorities.
• Planned features and prioritized the backlog.
• Built most of the backend logic and automated workflows.
• Coordinated a QA-focused teammate and a UI-focused developer.
• Led user testing, training, rollout, and production support.

Before asking for a new platform, I made the Google Sheet workflow easier to use. I added better context, translation suggestions from several services, dropdowns, and one-click tools for creating and importing missing-translation sheets.

I also automated an audio upload process that required AWS authentication and several technical steps. The old process could take about an hour. The new tool only required a recording link and completed the work in seconds.

These changes saved time, but they also proved that better spreadsheets could not solve the larger problem. The operation still depended on manual setup, file transfers, and people remembering many technical steps.

The team decided to move the content from Google Sheets into Microsoft Dataverse. The old data was too inconsistent to move directly, so we first designed a relational database.

I helped the team create the entity relationship diagram and explain how the tables should connect. I then built a Python migration process that collected the language sheets, merged them, cleaned inconsistent columns, and split the data into the new Dataverse tables.

This work mattered because the new app needed more than a cleaner screen. It needed one reliable source of truth for translations, contributors, languages, reviews, audio, and workflow status.

The Contributor App automatically finds missing translations and shows them to the right contributors. Teachers can review context and suggestions, submit their own translation, add comments, flag questions, review alternatives, and help with audio.

The Content Team no longer needs to create and move a spreadsheet for every project. A manager can give a contributor the app link, assign a language, and let the system handle the work and its status.

I designed the Manager Screen around the problems I had faced on the Content Team. It shows language progress, contributor activity, stalled work, flagged questions, conflicting submissions, and high-priority items.

I also built a notification system for errors and unusual results. It now contains about 1,500 notifications and can route an issue to the manager responsible for that language. This turns errors into a work queue instead of letting them disappear inside a flow.

Power BI reporting gives managers another view of the operation. One commonly used dashboard shows missing audio by language, including total, male, female, and article-specific recordings.

The app launched on August 14, 2025. It now supports 72 languages, about two dozen active contributors, and six managers or Content Team users. Contributors have completed several thousand new translations through the system, while the wider review process has scored existing content and processed about 18 million translation records and evaluations.

A standard missing-translation project previously required at least 25 to 30 minutes of internal setup, transfer, and import work for one language. Difficult cases could take closer to an hour, and the request often waited several days before a contributor could begin.

The new process removes most of that work. Based on the old minimum process time, a full 72-language cycle represented about 30 to 36 hours of internal administration that is now largely automated. Managers report that contributors can often finish a request the same day or within one to three days without further administration.

• Removed developer-generated spreadsheets from the normal translation workflow.
• Created one audit history for content changes.
• Made contributor progress and inactivity visible.
• Added review scores so teachers can focus on likely errors first.
• Made it easier for teachers to correct content directly instead of reporting problems informally.

One automated flow checked whether changed translations still matched their audio. I tested it, released it quickly during the Christmas period, and moved on to other work. Later, we found that an edge case caused the flow to trigger itself and detach audio that should have stayed.

The audit history allowed me to build a recovery flow and restore the audio. The larger lesson was that testing should match the possible impact. A workflow that can touch the whole database needs staged release, monitoring, and follow-up checks even when the code looks simple.

Internal products create value by reducing coordination, not only by adding features. The most important parts of this system are often invisible: clean data, clear status, reliable handoffs, exception handling, and a useful view for managers.

I also learned that I enjoy working across product ownership, project coordination, and development. Building the system helped me understand its limits, while managing the backlog helped me focus that technical work on the problems that mattered most.