Snapshot

TL;DR

Scanat’s Chinese, Japanese, and English copy was originally scattered across design files, code, and multiple translation versions. More than 1,000 historical strings lacked a shared standard, while design, localization, and engineering worked in a largely sequential process.

In July 2024, with only two months before the multilingual release, I consolidated the copy data, defined ownership and maintenance rules for keys, and redesigned the workflow so design, localization, and engineering could work in parallel. The process was then extended from iOS to Web, supported the planned three-language launch, and remained stable for more than a year. After AI was introduced, we encoded the established key conventions and Japanese localization patterns into a Skill so Claude could extract copy from designs, compare it against historical strings, and suggest reuse—while product and localization retained final approval.

1. Problem

Main Issues

• A fragile, error-prone process: localization started only after engineering implementation, and translators edited text directly from code with little traceability;
• Design and production drifted apart: design files remained Chinese-only, so every copy change had to be reconciled across design, code, and production;
• Inconsistent localization style: multiple Japanese teammates translated opportunistically, producing inconsistent tone and terminology across the same product;
• Copy was largely hard-coded: multilingual maintenance was difficult, and 1,000+ historical strings had accumulated inconsistencies. iOS had already completed a first pass introducing keys, while Web still had no comparable foundation.

Constraints

• Tight timeline: only about two months remained between taking ownership in July and the Chinese / English / Japanese release at the end of August;
• Different platform maturity: iOS already had an initial key-based structure, while Web had to start from zero; both still needed to converge on one standard;
• Execution through a new teammate: I also needed to onboard a newly hired localization teammate and make the process executable by someone other than myself.

2. Approach

The core of the redesign was to clarify ownership and dependencies so design, localization, and engineering could work in parallel around the same source of truth.

Step 1: Establish a Single Source of Truth and Define Key Ownership

I first had the latest iOS strings exported and reconciled them against the existing spreadsheets, removed obsolete entries, and consolidated fragmented historical versions into one master copy table. Engineering and I agreed to treat this table as the single source of truth going forward.

I also defined design as the owner of copy keys. The design file is where copy first gains concrete UI context, so assigning the key there ties it directly to its intended use and prevents localization and engineering from independently guessing context.

Step 2: Replace the Sequential Workflow with Parallel Collaboration

Previously, localization began only after engineering finished, and engineering had to pick the work back up after translation. I decoupled these steps: design defined the key and Chinese context in the design file; localization entered the key and source copy into the master table and added Japanese and English; meanwhile, engineering could already implement against the key without waiting for every translation to be complete.

Once translations were ready, design updated the final localized copy in the design files and engineering synced the latest table. All three functions now worked around the same keys, allowing localization and implementation to overlap.

For the 1,000+ historical strings, I prioritized the cleanup rather than treating every language equally: Japanese first, then English, then Chinese review. Japanese was both the primary user language and the area with the greatest historical inconsistency after years of ad hoc translation.

With only a two-month launch window, I deliberately concentrated effort where user impact and inconsistency were highest instead of distributing cleanup effort evenly across all three languages.

Step 3: Validate the Rules on iOS Before Expanding to Web

iOS already had a first-pass key structure, while Web had almost none. Rather than refactoring both platforms at the same time, I used iOS to validate the rules first. This separated workflow risk from technical migration risk, and once the model proved stable, I worked with engineering to extend the same rules to Web.

Web was more complex because some copy came from backend responses, but by then the ownership model, master-table structure, and collaboration pattern had already been validated on iOS. We could extend the same system instead of inventing a second workflow.

Step 4: Encode Stable Rules into an AI Skill

When the company later introduced AI, we did not replace the workflow with a new one. Instead, we encoded the stable rules into a Skill. It captures the existing key naming conventions and established Japanese localization patterns to support copy preparation for new features and identify opportunities to reuse historical content.

After a design is ready, Claude uses the Skill to extract copy directly from the design file, generate a review document in the existing table structure, and classify strings into shared copy and business-specific copy. It then compares the Chinese source text against the historical table, identifying exact matches as well as older strings with similar meaning.

• Exact match for shared copy: reuse the existing key, Japanese, and English, and record the source in the notes;
• Exact match for business-specific copy: reuse the existing Japanese and English, but create a new key for the current business context and document the relationship;
• Semantic similarity only: surface potentially related historical strings in the notes, but do not auto-fill the key or translations; leave the decision to a human reviewer.

After AI completes the first pass, product reviews the key semantics, whether historical copy is truly reusable, and whether business-specific copy needs a new entry. Only after approval is the content merged into the master table, with localization performing the final Japanese and English quality check.

3. Outcome

• By the end of Aug 2024, the product launched Chinese / English / Japanese switching as planned, with the multilingual foundation established across both iOS and Web;
• Design, localization, and engineering began collaborating around shared keys and a single copy table, and the workflow remained stable for more than a year;
• As the team grew and ownership became clearer, the workflow could be handed off to the product team without rebuilding the process;
• After AI was introduced, the established rules were further encoded into a Skill for copy extraction, historical comparison, classification, and reuse suggestions. The original workflow was not replaced; it evolved on top of the same ownership model;
• Human review by product and localization remains mandatory; semantic similarity, key meaning, and final translation quality are not delegated entirely to AI;

4. Reflection

1. This was not primarily a UI-design problem; it was a collaboration-system problem. The real design questions were who owns key definition, which steps must remain sequential, which can run in parallel, and how to make the workflow transferable to another team.
2. The project reinforced the value of addressing cross-functional issues that sit outside the interface but directly affect delivery quality. Formalizing ownership and collaboration patterns creates a more durable system than repeatedly solving the same coordination problem ad hoc.
3. The AI phase made one principle especially clear: automation only works when the underlying rules are explicit. Key naming, the boundary between shared and business-specific copy, reuse criteria, and required human review all had to be defined first before the Skill could reliably take over repetitive work.