SaaS Localization: UI Strings & Continuous Localization¶

“Save changes” - two words, one line in a JSON file, and five minutes of work for a translator. But when there are 12,000 such strings, they change every sprint, and the product ships every Thursday - that’s not “just translation” anymore. That’s continuous localization, a distinct niche with its own workflow, tooling, and logic. The software localization market is valued at $5.57 billion (2024) and growing at 11.8% annually, and a significant chunk of that growth comes from SaaS products that need translation not once a year, but continuously.

What SaaS Localization Is and How It Differs from Website Translation¶

SaaS localization is the adaptation of a software product (web app, mobile app, desktop client) for users of another language and culture. It’s not the same as translating a landing page or corporate website.

Here are the concrete differences:

Parameter	Website Translation	SaaS Localization
Update frequency	Every 3-6 months	Weekly or daily
Batch size	5,000-20,000 words	50-500 strings per sprint
Context	You see the full page	Isolated strings without context
File formats	HTML, CMS	JSON, XLIFF, PO, YAML, ARB
Workflow	Manual: receive file → translate → send back	Automated via TMS + CI/CD
Repetitiveness	Low	High (70-80% of strings overlap between versions)
Typical challenges	SEO, tone of voice	Character limits, pluralization, placeholders

Website translation is a project with a beginning and an end. SaaS localization is a process that runs as long as the product lives. And it’s precisely this continuity that makes the niche attractive for translators: a single client can provide a steady stream of work for years.

As Crowdin notes in their SaaS localization guide:

SaaS localization is a continuous process, not a project. Your product evolves weekly, and your localization workflow must keep pace with development sprints.

In other words, if you’re working with a SaaS client, you effectively become part of their team rather than an external contractor on a one-off job.

UI Strings: What Exactly Gets Translated in a SaaS Product¶

A UI string is any piece of text a user sees in the interface. It could be a one-word button, a three-sentence error message, or a 15-character tooltip. The translator works not with a document, but with a set of isolated strings.

Types of UI Strings¶

• Navigation and buttons - “Save”, “Cancel”, “Back”, “Next step”. Short, often lacking context, critical for UX
• Labels and forms - “Email address”, “Password”, “Company name”. Precision and brevity are key
• Error messages - “This field is required”, “Invalid email format”. Tone should be clear, not aggressive
• Tooltips and hints - “Click here to upload your file (max 10 MB)”. Length constraints, context needed
• Notifications and alerts - “Your payment was successful”, “Session expired”. Push notifications, in-app banners
• Emails and templates - onboarding emails, confirmations, reminders. More text here, tone of voice matters
• Microcopy - empty states (“No results found”), loading states (“Just a moment…”), success states. Often overlooked, but heavily impacts user experience

As Translated Right describes in their microcopy article, 50+ types of UI strings are regularly missed during localization - from placeholder text in search fields to image alt-text and aria-labels for accessibility.

Why Context Is the Number One Problem¶

When you translate “Back” - is it “Return” (navigation) or “Back” (anatomy)? “Set” - is it a “Collection”, “Configure”, or a “Set” in tennis? Without a screenshot or reference to where it appears in the interface, you don’t know.

In real SaaS projects, the context problem looks like this: a translator receives a spreadsheet with 500 rows, each containing an isolated word or phrase. The word “Post” could mean “Publish” (verb on a button) or “Post” (noun in a heading). Without context, the translator guesses, and in 30-40% of cases, guesses wrong.

Two solutions exist: 1. In-context editor - the translator sees the string directly in the product UI and translates it in place 2. Screenshots and descriptions - each string comes with a screenshot or description of where it appears

Technical Challenges of UI Strings¶

Text expansion. German UI text is typically 30-40% longer than English, according to SimpleLocalize. A “Submit” button (6 characters) becomes “Absenden” (8) or “Відправити” (11 in Ukrainian). If the designer didn’t build flexibility into the layout - the button breaks.

Pluralization. English has singular and plural. Russian and Ukrainian have three forms (1 file, 2 files, 5 files). Arabic has six. This isn’t the translator’s problem to solve - it’s the developer’s job to implement ICU MessageFormat or equivalent. But translators need to know these formats and work with them correctly.

Placeholders and variables. The string “You have {count} new {count, plural, one {message} other {messages}}” needs to be translated while keeping the {count} variables in place. One mistake - and instead of “You have 3 new messages,” users see raw technical markup.

Continuous Localization: Why Batch Translation No Longer Works¶

The traditional approach to software translation was waterfall: developers finish a release, export strings to a file, send it to a translator, wait a week, import it back. This worked when software shipped once a quarter.

SaaS companies ship weekly or daily. If translation delays a release by a week - that’s unacceptable. This is why continuous localization emerged - an approach where translation is integrated into the CI/CD pipeline and happens in parallel with development.

How It Works Technically¶

1. Developer merges a feature branch with new strings into main
2. TMS (Crowdin, Lokalise, Phrase) automatically detects new strings via GitHub/GitLab integration
3. Translators receive a notification and start working in the TMS
4. Completed translations automatically return to the repository via pull request
5. CI/CD pipeline picks up translations and deploys them with the new code

The entire cycle - from developer commit to translation appearing in production - takes hours to 1-2 days, not weeks.

As Lokalise describes:

In a continuous localization workflow, translators and developers work simultaneously. Translation comes in small parts in parallel with agile sprints, rather than as a massive batch after the feature freeze.

What This Means for Translators¶

Instead of one large order for 5,000 strings once a quarter - you get 50-200 strings every week. Smaller batches, but a steady flow. You work directly in the TMS (not in Word or Excel), see context through screenshots or an in-context editor, and your translations hit production within a day.

This requires a different work rhythm: you can’t “put it off until tomorrow,” because tomorrow the developers are already waiting for translations for the release. On the other hand - you dive deeper into the product and translate faster over time because you know the terminology and context.

Tools: Crowdin, Lokalise, Phrase and Other TMS Platforms¶

In SaaS localization, translators don’t work with files - they work with a TMS (Translation Management System), a platform that manages strings, translation memory, glossaries, and automation.

Platform Comparison¶

Platform	Starting Price	Strengths	Best For
Crowdin	from $50/mo	Free plan for open-source, large translator marketplace, GitHub/GitLab integration	Agile teams, open-source projects
Lokalise	from $120/mo	In-context editor, Figma plugin, OTA updates for mobile	Developer-led product teams
Phrase	from $385/mo	Enterprise-grade, integration with marketing and docs workflows	Large companies with multiple content types
Transifex	from $100/mo	API-first approach, strong CLI	Technical teams, open-source

As Better-i18n’s comparison shows, TMS choice depends on company size and content type. Crowdin dominates among small and mid-size SaaS companies, Phrase among enterprise.

What Translators See in a TMS¶

A typical work screen: on the left - the original string, on the right - the translation field. Above or alongside - context: screenshot, description, developer comment. Below - suggestions from Translation Memory and machine translation (DeepL, Google, ChatGPT).

Features that make life easier: - Translation Memory (TM) - if “Cancel” has already been translated as “Abbrechen” 50 times, the TMS automatically suggests that translation - Glossary - consistent translation for key product terms (e.g., “workspace” is always “espace de travail,” not “zone de travail” or “workspace”) - QA checks - automatic detection of missing placeholders, double spaces, unclosed brackets, length overflow - Machine translation - initial draft from DeepL or an LLM that the translator edits (MTPE approach)

For more on CAT tools and how they compare, check out CAT Tools for Translators: Trados vs MemoQ vs Smartcat, and for the Lokalise vs Crowdin breakdown - Lokalise vs Crowdin: Which Is Better for Product Localization.

What It Costs and What You Can Earn¶

Translator Rates¶

UI string translation rates depend on language pair, complexity, and payment model:

Model	Rate	Notes
Per-word (human translation)	$0.08-0.25	Standard for agencies and freelancers
Per-word (MTPE)	$0.04-0.10	Post-editing machine translation output
Per-hour	$30-60	Less common, usually for review work
Retainer (monthly)	$500-3,000	Fixed payment for ongoing localization

According to Alconost’s data, a typical SaaS product with 50,000 words into 8 languages costs roughly $36,000 for human translation or $23,400 for MTPE. Annual maintenance (updates, new features) adds 15-25% of the initial amount.

Language Pairs and Demand¶

The most in-demand language pairs for SaaS localization: - Tier 1 (highest volume): EN→DE, EN→FR, EN→ES, EN→JA, EN→ZH - Tier 2 (growing demand): EN→PT-BR, EN→KO, EN→IT, EN→NL - Tier 3 (niche but well-paid): EN→UK, EN→PL, EN→TR, EN→AR

Tier 3 pairs mean fewer orders but higher per-word rates due to a smaller pool of qualified translators with SaaS experience.

For a broader look at translation rates, check out Translator Rates: How to Calculate Your Price and Avoid Underselling.

Common Mistakes and Pitfalls¶

For Translators¶

Ignoring character limits. If a string’s comment says “max 20 chars” - that’s a hard limit. A 30-character button overflows the layout. German text expands 30-40% compared to English, so “Submit form” (11 characters) becomes “Formular absenden” (17 characters), and that’s not even the worst case.

Translating placeholders. {userName} must stay {userName}, not become {nomUtilisateur}. It’s a variable, not text. One such mistake - and the feature gets sent back for rework.

Inconsistent terminology. If “Dashboard” is “Control Panel” in one string and “Dashboard” in another - it looks unprofessional and confuses users. A glossary fixes this, but only if you actually follow it.

Translating without context. If the TMS doesn’t provide a screenshot or description - ask. Better to spend 2 minutes on a question in the comments than 20 minutes on rework after QA.

For Client Companies¶

No i18n foundation. According to SimpleLocalize, attempting SaaS localization without proper internationalization (i18n) costs 3-5x more. Hardcoded strings, rigid layouts, missing Unicode support - all of this surfaces at the first translation attempt.

Batch approach in an agile environment. If developers ship weekly but translation happens monthly - 75% of the time the product is English-only. That’s not localization, that’s the appearance of localization.

No context for translators. A spreadsheet with 500 isolated strings without screenshots, descriptions, or character limits is a guaranteed 30-40% rework rate. Investing in screenshots and descriptions pays for itself in the very first translation batch.

For more on how AI is changing translation and when MTPE makes sense, read MTPE (Machine Translation Post-Editing): What It Is and Why It’s the Future.

How to Break Into SaaS Localization as a Translator¶

Step 1: Learn the Tools¶

Sign up on Crowdin (there’s a free plan for translators through the marketplace) and practice on open-source projects. This is free practice with real UI strings, real context, and real deadlines. Crowdin has tens of thousands of open-source projects looking for volunteer translators - it’s the perfect way to build experience and add lines to your portfolio.

Step 2: Learn the Formats and Technical Basics¶

You don’t need to code, but you need to understand: - JSON, XLIFF, PO, YAML - the main localization file formats - Placeholders and variables: {name}, %s, {{count}} - ICU MessageFormat for pluralization - How Git works at a basic level (because strings come from a repository)

All of this takes 1-2 weeks to learn independently. YouTube and Crowdin/Lokalise documentation have detailed tutorials.

Step 3: Build a Specialized Portfolio¶

Instead of a generic portfolio saying “I translate from English to German” - show specifics: “Localized UI for 3 SaaS products, 15,000 strings, EN→DE pair, work in Crowdin/Lokalise.” That’s the difference between a generalist and a specialist, and SaaS companies are looking for the latter.

Step 4: Where to Find Clients¶

• Crowdin Marketplace - SaaS companies find translators directly through the platform
• Direct outreach - find SaaS products available in English but missing your target language, and offer localization
• SaaS-specialized agencies - some LSPs specialize in software localization (Alconost, Lionbridge, TransPerfect)
• LinkedIn - SaaS companies frequently look for translators through posts and job boards
• ProZ - create a profile highlighting “software localization” as your specialization

For general client-finding strategies, check out Where to Find Clients as a Freelance Translator, and for the skills you need as a translator in 2026 - What Skills Translators Need in 2026.

FAQ¶

How is SaaS localization different from website translation?¶

A website is static content translated once and updated every few months. A SaaS product updates weekly or daily, UI strings change with every release, and translation runs in parallel with development through TMS integration. It’s a continuous process, not a project with an end date.

How much does SaaS localization cost?¶

A typical SaaS with 50,000 words into 8 languages costs roughly $36,000 for human translation or $23,000 for MTPE. Per-word rates are $0.08-0.25 depending on language pair. Annual maintenance (new features, updates) adds 15-25% of the initial cost.

Which languages do SaaS companies localize into first?¶

Usually 5-8 languages with the highest ROI - German, French, Spanish, Portuguese (Brazil), Japanese, Korean. According to CSA Research, 76% of online consumers prefer buying in their native language, so language selection is driven by the product’s audience.

Do I need a technical background to translate UI strings?¶

A technical degree isn’t required, but you need to understand basic concepts - string keys, placeholders, pluralization, JSON/XLIFF formats. This takes a week or two to learn through Crowdin or Lokalise documentation and practice on open-source projects.

What is continuous localization?¶

Continuous localization is a workflow where translation is integrated into the CI/CD development pipeline. New strings automatically flow into the TMS via GitHub/GitLab integration, translators work in parallel with developers during sprints, and translations are automatically pulled back into the codebase via pull requests. The result - translations appear in production within hours or days, not weeks.

Sources¶

1. GMI - Software Localization Market Size & Share 2025-2034 - software localization market analysis
2. Crowdin - SaaS Localization Guide - Crowdin’s SaaS localization guide
3. Phrase - Continuous Localization - continuous localization workflow explained
4. Lokalise - Continuous Localization 101 - continuous localization fundamentals
5. SimpleLocalize - Best Practices in Software Localization - best practices with concrete examples
6. Alconost - How Much Does Localization Cost in 2026 - real localization pricing from 3,200+ projects
7. Translated Right - 50 UI Strings You’re Forgetting to Translate - full list of commonly missed microcopy
8. CSA Research - Can’t Read, Won’t Buy - research on language impact on buyer behavior