Bilingual Curriculum Translation Pipeline Development

The problem Our music education platform served students in English and Spanish, but there was no automated way to produce bilingual curriculum files. Content coordinators pulled translations from Google Docs one document at a time, checked them against the English source, and built the output files by hand. It was slow, error prone, and couldn't keep up as the curriculum grew.

What I built As Director of AI Integration, I built a serverless ETL pipeline on AWS using Python, Lambda, and S3. Each stage had one job:

Read and normalize the English curriculum JSON.

Pull human translations from Google Docs.

Apply our music education glossary so terminology stayed consistent.

Fill any gaps with DeepL.

Rebuild clean bilingual JSON for the platform.

Key design decisions Files ran in parallel, up to 10 at a time, which balanced speed against API rate limits. I used a soft-fail design: if a source file couldn't be read, that file stopped, but every later stage passed partial results forward instead of stopping the batch. Partial output was almost always better than no output. Each stage was modular, so it could be updated, tested, and deployed on its own.

Scoping and retro We used MoSCoW to agree on what V1 had to deliver and what could wait for V2. After launch, I led a technical retrospective and a technical debt review. We found gaps in observability, retries, and per-file status tracking, then ranked them into a V2 roadmap by operational impact.

Results A full run took 8 minutes and replaced months of manual work, with consistent terminology across every file. The retro gave leadership a clear plan to take the pipeline from working V1 to production ready.

Tools: Python, AWS Lambda, Amazon S3, CloudWatch, Google Docs API, DeepL API, JSON, MoSCoW prioritization, Vector Database, SQL