Shipping a new feature is only half the job. If your localized UI breaks, your help docs lag behind, or your release notes arrive in English-only, you've just degraded the experience for every non-English user, often the majority of your revenue base. SaaS teams running two-week sprints face a compounding problem: each release introduces new strings, updates existing copy, and deprecates old content across UI, documentation, and marketing surfaces simultaneously. Without a disciplined localization workflow baked into the development cycle, defect rates climb, launch timelines slip, and international users churn. This playbook gives product, engineering, and localization teams a concrete system for authoring, managing, and releasing localized text at the pace modern SaaS demands.
Authoring Strings That Scale
The quality of your source strings determines everything downstream. Poorly written, ambiguous, or context-free strings multiply translation costs and generate bugs that surface only after release.
Writing Short, Translatable Source Strings
The single most impactful thing you can do for localization is write source strings that are inherently translatable. This means keeping strings short, semantically complete, and free of assumptions about word order.
Avoid concatenating sentence fragments at runtime. A string like "You have " + count + " items in your " + location forces translators to work with disconnected pieces that may need entirely different ordering in languages like Japanese or Arabic. Instead, use a single string with placeholders: "You have {count} items in your {location}." This gives translators a full sentence to work with.
Hard-coded variables are another common trap. Never embed units, currencies, or date formats directly into strings. Use your framework's internationalization (i18n) library to handle formatting. A string should contain the semantic intent, "Last updated {date}", and let the locale configuration determine whether the date renders as "15 June 2025" or "2025年6月15日."
Keep strings under roughly 40 characters for buttons and labels where possible. German text commonly expands 30-35% compared to English, and Finnish can expand even more. If your button barely fits "Submit Application" in English, it will almost certainly overflow in several target languages.
Adding Context Notes and Screenshots
Translators working without context produce mediocre translations. Every resource file should include developer notes that answer three questions: Where does this string appear? What does it do? Are there constraints?
A context note for a button label might read: "Appears on the checkout page. Triggers payment processing. Max 20 characters recommended." This takes seconds to write and prevents costly retranslation cycles.
Screenshots are even more powerful. Attach annotated screenshots to string entries showing exactly where each string renders in the UI. Modern localization platforms like Ollang, Phrase, Lokalise, and Crowdin support screenshot attachment at the string level. If your team uses Figma, export annotated frames and link them directly to your translation management system (TMS).
For strings that appear in multiple contexts, a word like "Post" that could be a noun or a verb, always disambiguate with a note or, better yet, use distinct string keys (post_noun vs. post_verb).
Handling Plurals, Gender, and ICU MessageFormat
English has two plural forms: singular and plural. Arabic has six. Polish has four. If you handle plurals with a simple if/else in code, you will produce incorrect output in most of the world's languages.
The ICU MessageFormat specification is the industry standard for handling plurals, gender, and select logic within translatable strings. A plural-aware string looks like this:
{count, plural,
=0 {No messages}
one {# message}
other {# messages}
}
Translators can then add the additional plural categories their language requires (few, many, etc.) without any code changes.
Gender handling follows a similar pattern using the select keyword:
{gender, select,
female {She shared a file.}
male {He shared a file.}
other {They shared a file.}
}
Adopt ICU MessageFormat from day one; retrofitting it into an existing codebase is more costly than starting with it.
Preventing Truncation and Supporting Right-to-Left
Truncation bugs are among the most common localization defects. They happen when translated text exceeds the space allocated in the UI, causing clipped labels, overlapping elements, or broken layouts.
Prevention starts in design. Use flexible containers, auto widths, min-width constraints, and text wrapping, rather than fixed pixel widths. For constrained spaces like mobile nav bars or table headers, set explicit character limits in your string context notes and communicate them to translators.
Right-to-left (RTL) language support, essential for Arabic, Hebrew, Farsi, and Urdu, requires more than flipping text direction. Your entire layout must mirror: navigation moves to the right side, progress bars fill from right to left, and icons with directional meaning (like arrows) need to flip. Use CSS logical properties (margin-inline-start instead of margin-left) and the dir="rtl" attribute to ensure your UI adapts correctly.
Test RTL support early. Adding it as an afterthought typically requires reworking significant portions of your front-end code.
Aligning Localization With Your Release Cycle
Localization cannot be a post-release afterthought. It must be a parallel workstream that moves in lockstep with your sprint cadence.
Pseudolocalization as a Pre-Flight Check
Pseudolocalization replaces source strings with accented, expanded, or bracket-wrapped versions, turning "Save" into something like "[Šåvé______]", to expose i18n issues before any real translation begins. It catches:
- Hard-coded strings that weren't externalized to resource files
- Truncation risks where expanded text overflows containers
- Concatenation bugs where fragments are assembled incorrectly
- Character encoding issues where accented characters render as garbled text
Run pseudolocalization as part of your CI pipeline. Tools like pseudo-localization npm packages or built-in TMS features can generate pseudo-locales automatically. Any build that fails visual regression tests under pseudo-locale should block the merge.
Feature Flags and Branch-Based Localization
Feature flags let you decouple deployment from release, and they're equally powerful for localization. When a feature is behind a flag, its strings can be translated and reviewed before the flag is turned on for any locale.
Branch-based localization extends this concept to your resource files. When a developer creates a feature branch, the corresponding strings are branched in the TMS as well. Translators work on the branch strings in parallel with development. When the feature branch merges, the translated strings merge too.
This approach eliminates the traditional bottleneck where engineering finishes a feature, throws strings over the wall to localization, and the team waits days or weeks for translations before the feature can ship internationally. Instead, translations land within hours of the code merge.
The key requirement is TMS-to-repository integration. Your TMS should sync with your Git repository via webhook or CLI so that string changes flow automatically in both directions. Platforms such as Ollang provide Git-integrated TMS features so string changes and branches stay synchronized with code.
Coordinating UI Copy, Docs, and Release Notes
A localized feature launch fails if the UI is translated but the help article explaining it is still in English, or if the release announcement only reaches English-speaking users.
Establish a single source of truth, typically a shared spreadsheet, Notion database, or project management board, that tracks every piece of content associated with a release:
| Content Type | Owner | Source Deadline | Translation Deadline | Status |
|---|---|---|---|---|
| UI strings | Product/Eng | Sprint day 5 | Sprint day 8 | In review |
| Help center article | Docs team | Sprint day 7 | Sprint day 10 | Drafting |
| Release notes | Product marketing | Sprint day 8 | Sprint day 11 | Not started |
| In-app tooltip | Product | Sprint day 5 | Sprint day 8 | Translated |
Stagger deadlines so that UI strings, which translators need first for context, are finalized before docs and release notes. Docs writers should reference the finalized translated UI terms to maintain consistency.
For teams managing this coordination across many languages and content types, platforms like Ollang can consolidate text, documentation, and software localization workflows into a single execution layer, reducing the coordination overhead that typically causes launch delays.