Localized Strings Automation

Overview

Before this project, translation updates meant hand-editing JSON while coordinating keys and stale entries across branches. Strings drifted, keys went stale, and translations missed releases.

I built the pipeline that replaced the manual step. It hashes eligible strings in watched files, garbage-collects keys that are no longer referenced, and appends new ones to the JSON automatically. I also wrote a small interface in front of the i18n utilities that determines which strings actually need translation.

What I built

The core idea is boring on purpose: a build-time hook watches team files for changes, computes a stable hash per string, and rewrites the JSON. The hashing approach came from a teammate's suggestion, which made keys deterministic across branches. A staff-engineering review tightened key ordering and mutagen sync so generated files stayed aligned across environments.

The interface layer kept Automated Compliance-specific calls behind a product-facing wrapper. Feature engineers using the new path stopped calling the i18n utilities directly. They wrote product code while the framework handled translation eligibility, key generation, and JSON updates.

I also raised a proposal with the i18n team around reverse lookup of translated strings for search in non-English locales. The overlap between my proposal and the i18n team's proof of concept helped validate the direction and clarified that the broader search problem belonged in the translation system, not in Automated Compliance.

Collaboration

The Automated Compliance work focused on deterministic key generation; the i18n discussion focused on whether reverse lookup belonged in the broader translation system.

Outcome

• Manual translation-key management stopped being routine feature work in Automated Compliance.
• Deterministic source-string keys and automatic stale-key cleanup reduced the manual drift that caused missed or stale translations.
• The reverse-lookup proposal clarified that broader translated-search behavior belonged in the shared translation system.
• The interface layer removed direct i18n utility calls from routine Automated Compliance feature work.

The narrow boundary made the automation useful. One error-prone step disappeared from routine feature work, and the resulting shape stayed clear enough to review with the i18n team.