Tomedes Keeps a SaaS Platform's Japanese Localization Consistent Across Every Sprint

Most software localization problems do not announce themselves at launch. They accumulate quietly, one update at a time, until the cost of fixing them exceeds the cost of having done it right from the start.

About the Client

A U.S.-based SaaS company had localized its product into Japanese as part of an Asia-Pacific expansion. The initial localization had gone well — a focused project with clear scope, defined deliverables, and a finished product that worked. The problem arrived with the second sprint.

New features meant new UI strings. A settings rename meant existing strings needed updating. A pricing page redesign meant new marketing copy. A help center refresh meant dozens of support articles needed Japanese versions. None of these were large projects individually. Together, they created something the company had not planned for: a continuous, unpredictable stream of Japanese translation work arriving on a development schedule that did not accommodate a procurement process for each new batch.

By the time the company approached Tomedes, it was managing Japanese localization through a patchwork of approaches — some strings handled internally by a bilingual employee who was not a professional translator, some sent to a vendor used for the initial launch, some simply left in English and flagged for "later." The Japanese product had begun to drift from the English source. Terminology was inconsistent across features. UI strings used three different Japanese renderings of the same English product term. Help center articles referred to features using names that no longer matched what appeared in the product itself.

Industry and Services

• Technology / SaaS Software Localization
• Ongoing Sprint Support
• English to Japanese

The Challenge

Software localization for a live product is a fundamentally different problem from software localization for a launch. A launch has a defined scope, a fixed deadline, and a clear finish line. A live product has none of those things. Three specific problems had developed inside this company's Japanese localization program before they engaged Tomedes.

1. Terminology had drifted across eighteen months of incremental updates

The initial Japanese localization had established consistent terminology for the product's core concepts — the Japanese equivalents for the company's feature names, navigation labels, pricing tier designations, and user role descriptions. Over eighteen months of updates, that consistency had eroded. A feature that was renamed in English partway through the year had been updated in some Japanese strings and left unchanged in others. A new onboarding flow introduced a Japanese term for a concept that already had an established Japanese equivalent elsewhere in the product, because the person handling that batch of strings did not have access to what had been translated before.

The result was a Japanese product where the same concept appeared under different names depending on where in the product the user encountered it. Japanese users had begun raising support tickets about features they could not find, not because the features did not exist, but because the Japanese name in the help article did not match the Japanese name in the UI.

2. Sprint-based delivery had made consistent vendor engagement impossible

Software development does not deliver translation work in predictable batches. A sprint might produce forty new strings one week and four hundred the following week, depending on what shipped. The company's existing vendor relationship was built around project-based pricing and defined turnaround windows, a model that worked for the initial launch and broke down immediately for ongoing sprint support. Short batches were not worth the vendor's setup overhead. Rush requests generated rush surcharges. Strings that arrived mid-sprint sometimes missed the release window and shipped in English.

The delivery model and the development model were structurally incompatible, and the product was paying the price in inconsistency and English fallback text appearing in a product marketed as fully localized.

3. No single point of accountability for the Japanese product's linguistic integrity

When localization work is distributed across an internal bilingual employee, a project-based vendor, and a backlog of unflagged English strings, no one owns the quality of the Japanese product as a whole. The bilingual employee made reasonable decisions within their knowledge but had no access to the full translation history. The project-based vendor accurately translated what it received but had no visibility into what had been translated before. The result was a Japanese product whose quality depended entirely on whether the right person happened to handle each batch — and increasingly, the right person was not handling it.

Why Tomedes?

The company came to Tomedes not because their Japanese product was broken but because they could see where it was heading. Eighteen months of drift had produced a product that still worked but had begun generating support friction — users confused by inconsistent terminology, help content that did not match the UI, and a growing backlog of strings sitting in English.

What they needed was not another project-based vendor. They needed an ongoing localization partner with a defined workflow for continuous delivery, a terminology governance structure that would prevent the drift from continuing, and a single point of accountability for the Japanese product's linguistic integrity across every sprint.

Tomedes' engagement with this client was structured from the outset around those three requirements, not around a fixed project scope that would expire when the strings were delivered.

The Solution

1. A terminology audit before any new strings were translated

The first step was not translation. It was a full audit of the existing Japanese localization (every string in the product, every help article, every UI label) to identify every instance where the same English concept had been rendered inconsistently in Japanese. The audit produced a list of 34 terminology conflicts: cases where the same English term appeared in two or three different Japanese renderings across different parts of the product.

Each conflict was resolved through a structured decision process: the Tomedes Japanese specialist reviewed each conflict, identified which rendering was most natural for Japanese SaaS users, and documented the approved term. The resulting glossary (34 resolved conflicts plus the full established terminology from the original localization) became the governing reference for every translation decision going forward. Before a new string was translated, the translator checked it against the glossary. Before a help article was updated, the approved terms were applied. The drift stopped because the mechanism that had been producing drift was replaced with a mechanism that prevented it.

2. A standing weekly intake process aligned to the sprint cycle

Rather than requiring the company to initiate a new translation project for each batch of strings, Tomedes established a standing weekly intake window aligned to the development team's sprint schedule. Strings ready for translation were submitted each Monday. Translated strings were returned by Thursday, in time for QA and release on Friday. Batches of four strings and batches of four hundred strings moved through the same process at the same cadence — no setup overhead, no rush surcharges for sprint-aligned delivery, no strings missing the release window because the translation procurement process could not keep pace with the development cycle.

According to Tomedes' project data, SaaS clients operating on sprint-based localization programs reduce their per-string translation cost by eliminating rush surcharges and rework cycles that account for a significant share of localization spend in project-based models. The cost reduction is not from lower per-word rates, it is from removing the structural inefficiencies that project-based models build into ongoing localization work.

3. A single dedicated Japanese specialist owning the product's linguistic continuity

One Japanese specialist was assigned to this client's account and remained on it for the duration of the engagement. That translator developed familiarity with the product's feature architecture, its user base, its tone, and the specific Japanese register that worked for its audience. When a new feature shipped, the translator understood what it did and how it related to existing features — context that allowed them to make localization judgments that a rotating pool of translators working from strings in isolation could not make.

When a product decision created a localization question (a feature rename that conflicted with existing Japanese terminology, a new pricing tier that needed a Japanese name consistent with the existing tier naming convention), the translator flagged it before translating, not after. That upstream catch is where the cost savings actually live. A terminology question caught before translation costs nothing. The same question caught after a string has shipped to production, been seen by users, and generated support tickets costs engineering time, QA cycles, a re-release, and (in the worst case) a round of user communication explaining the change.

4. Help center and UI string alignment as a standing quality check

One of the specific failure modes the audit had identified was a mismatch between UI terminology and help center terminology, users reading help articles that described features using names that no longer existed in the product. Tomedes built a standing alignment check into the workflow: whenever a UI string was updated, the corresponding help center articles were flagged for review. Whenever a help article was updated, the UI strings it referenced were checked against the glossary.

This check did not require a separate QA process or a separate budget line. It was built into the translator's workflow as a standard step, because the cost of the check is negligible compared to the cost of a user opening a support ticket because the feature name in the help article does not match the feature name in the product.

5. Quarterly terminology reviews to absorb product evolution

A glossary built at one point in a product's lifecycle does not stay accurate forever. Products evolve. Features are renamed, deprecated, or repositioned. New concepts enter the product vocabulary that the existing glossary does not cover. Tomedes built a quarterly terminology review into the engagement structure — a scheduled review of the full glossary against the current state of the product, identifying terms that needed updating, resolving new conflicts that had emerged, and adding approved equivalents for concepts introduced since the last review.

The quarterly review is what keeps a living localization program from reproducing the same drift problems over time. Without it, a glossary becomes a historical document rather than a governing reference — and the terminology drift resumes.

The Result

Six months into the Tomedes engagement, the Japanese product's terminology was consistent across every surface — UI strings, onboarding flows, help center articles, pricing pages, and release notes. The 34 terminology conflicts identified in the initial audit had been resolved and had not recurred. Support tickets related to feature naming confusion had dropped measurably in the Japanese user segment.

The development team submitted strings each Monday and received translations each Thursday. No sprint had missed its localization window since the standing intake process was established. No strings had shipped in English fallback since the workflow was implemented.

The bilingual employee who had been handling overflow translation work had been redeployed to customer-facing work that better used their skills, because the localization program no longer needed a stopgap.

That last point is where the real value of a structured ongoing localization program shows up. It is not in the per-string rate. It is in what the organization stops spending on rework, support overhead, and the internal time cost of managing a localization process that was never designed for the way the product actually ships.

Are you a SaaS company managing ongoing Japanese translation services or other language localization programs across sprint-based development cycles? Explore Tomedes' technical translation services or contact Tomedes for a free consultation.

Frequently Asked Questions

1. What is software localization?
Software localization is the process of adapting a software product (including UI strings, help content, marketing copy, and release notes) for a specific language market. It goes beyond translation to include terminology consistency, cultural adaptation, and alignment between all product surfaces so users encounter the same language across every touchpoint.

2. What causes terminology drift in software localization?
Terminology drift happens when different translators, different batches, or different timelines produce different Japanese renderings of the same English concept. Without a shared terminology reference applied consistently across every update, each new sprint introduces small inconsistencies that compound over time into a product that contradicts itself across features.

3. How does sprint-based localization work?
Sprint-based localization aligns translation delivery to a software development team's release cycle. Strings are submitted at the start of each sprint and returned before the release window closes. This eliminates the setup overhead and rush surcharges that project-based models generate for ongoing work, and prevents English fallback text from shipping when translation cannot keep pace with development.

4. How much does software localization cost?
Software localization cost depends on language pair, volume, turnaround requirements, and whether the program is project-based or ongoing. According to Tomedes' project data, ongoing sprint-based programs typically reduce effective per-string cost compared to project-based models by eliminating rework, rush fees, and the overhead of initiating a new project for each batch. Tomedes provides free quotes for ongoing localization programs at tomedes.com/contactus.php.

5. What is a localization glossary and why does it matter?
A localization glossary is a documented reference of approved translations for a product's core terminology — feature names, UI labels, pricing designations, user role descriptions. It matters because without one, each translator makes independent decisions about the same terms, producing inconsistencies that users encounter as a product that contradicts itself. A governed glossary prevents that inconsistency from accumulating.

6. How do you maintain localization quality across ongoing product updates? Consistent localization quality across ongoing updates requires three things: a single translator or consistent team with institutional knowledge of the product, a governed terminology reference updated on a regular schedule, and a workflow that checks UI and help content alignment whenever either surface is updated. Quality in ongoing localization is a process outcome, not a per-string outcome.