String freezes, context gaps, release delays, per-word pricing on 4-word strings, and translators who have never seen your product. A guide for product and engineering teams shipping in multiple languages.
Jump to the bottleneck checklist ↓These are not edge cases. They are structural problems built into how most SaaS teams set up localization. Recognizing them is the first step to fixing them.
Engineering ships biweekly or continuously. Translation operates on "project" timelines of 3 to 10 business days. The gap means either holding releases for translations (slowing velocity) or shipping untranslated strings (degrading the user experience in non-English markets).
Translations arrive after the release shipsTranslators receive string keys without screenshots, without knowing the UI location, without understanding whether "Save" is a button, a menu item, or a heading. The result: translations that are linguistically correct but functionally wrong. Engineers spend hours answering questions that context would have prevented.
Engineers become localization supportTo give translators time, teams implement string freezes: a period before each release where no new user-facing strings can be added. This forces engineering to stop adding features days before each release. The result is an artificial deadline that reduces product velocity and creates scheduling pressure.
Feature work stops for translation timingUI strings are 3 to 8 words each. The context instructions for translating those strings (screen location, character limits, tone, adjacent strings) can be longer than the string itself. Per-word pricing charges for 4 words and ignores the context work that determines quality. The economics are misaligned.
4 words to translate. 40 words of context to provide.Enterprise LSPs rotate project managers every 6 to 18 months. Translators assigned to your project change without notice. Each new person starts from zero: learning your product terminology, your brand voice, your UI conventions. The result is quality dips after every team change.
New PM every 6 to 18 monthsMost teams start with option one and hit a wall at 5 to 8 languages. The question is which model fits your stage and velocity.
You set up Phrase, Lokalise, or Crowdin. You source freelancers or a small agency. You write context, manage timelines, answer translator questions, and run QA. Full control, full overhead. Works until string volume or language count exceeds your bandwidth.
An enterprise LSP manages translation in their own TMS. Strings are exported from your system, imported into theirs, translated, and returned. Two platforms. Sync friction. Their project timeline, not your release cadence. Quality depends on which team gets assigned this quarter.
Dedicated translators get access to your Phrase/Lokalise instance, your Slack channel, your Figma files. They see the product. They learn your terminology. Translations happen within your sprint cycle. No export/import. No separate timelines. No string freezes.
From integration assessment to sprint-aligned delivery. The goal is to make localization invisible to your engineering team.
Map your localization workflow: TMS, CI/CD pipeline, string delivery method, context provision, release cadence. Identify where the bottleneck lives. Usually it is not the translation itself. It is the handoff between engineering, translation, and release.
Dedicated linguists get access to your Phrase/Lokalise instance, your Slack channel, and your Figma or design files. They study your product. They learn your terminology and UI conventions. They process their first strings with your review. Calibration, not production, is the goal of this phase.
Strings pushed on Monday are translated and reviewed by midweek. No string freezes. No separate project timelines. The localization team operates on your release cadence. Translations land when your code lands. Quality improves over time because the same team accumulates product knowledge.
Published data from long-term localization operations. These are not project metrics. They are operational baselines.
If three or more of these apply, your localization setup is the bottleneck, not the translation itself.
A global fashion company shipping to 20+ markets trusted the same localization team for 12+ years. Synchronized multilingual launches across all markets. Peak season scaling: 3x volume increase handled without quality degradation. Revision rate under 0.5%. Zero missed launch deadlines in over a decade. The team that translated the first collection still translates today.
"Translation as such is almost solved. The operations around it, validation, result improvement, system connections, that is where growth potential lies."Industry consultant, practitioner interview, 2026
"Complexity management matters more than automation. Buyers pay more to simplify decision-making, governance, and accountability."CSA Research, Prediction #3, 2026
"Every $1 invested in localization can generate $25 in incremental revenue."CSA Research
Most translation workflows operate on project timelines (days to weeks) while engineering ships on sprint cycles (biweekly or continuous). The mismatch creates a bottleneck: you either hold releases for translations, ship untranslated strings, or implement string freezes. The fix is not faster translation. It is a localization operation that runs on your release cadence.
A string freeze is a period before release where no new translatable strings can be added to the codebase. It gives translators time to work. The problem: it forces engineering to stop adding user-facing features days before each release. Teams that eliminate string freezes do so by having translators work within the sprint cycle, not after it.
The most effective context methods: screenshots showing the string in its UI position, character limits and formatting constraints, descriptions of the user action ("Save" as a button vs. a heading), and links to design files. The best approach gives translators direct access to the product or design environment rather than asking engineers to write context for every string.
They separate infrastructure (a localization platform for string management) from operation (dedicated translators who understand the product and deliver within the sprint cycle). The platform handles version control and string delivery. The operation handles quality, context, and timing. Most bottlenecks come from trying to make the platform do both jobs.
Machine translation works for some content types: help center articles, release notes, documentation. For UI strings, MT without human review creates UX problems: awkward phrasing, broken layouts from string expansion, inconsistent terminology. Most effective SaaS teams use MT for documentation and human translation for the product interface.
Three costs: reduced conversion in non-English markets (users abandon products that feel unfinished), increased support tickets from poorly translated interfaces, and developer time fixing localization bugs. Companies with properly localized products see 25%+ higher engagement in local markets (CSA Research).
Through the localization platform's API or CLI. New strings pushed to the repository sync automatically to the translation platform. Translated strings sync back and can be validated in the build pipeline (missing translations, string length violations, placeholder errors). The key is making localization a step in the pipeline, not a separate process after the build.
It depends on where your revenue comes from. For most B2B SaaS, 5 to 8 languages cover 80%+ of the addressable market (English, Spanish, French, German, Portuguese, Japanese). For B2C, local language support correlates directly with conversion. Add languages based on market data, not arbitrary targets.
We assess your current workflow, identify where the bottleneck lives, and show you what sprint-aligned localization looks like for your stack.
Prefer email? ricard@kobaltlanguages.com