Arkian logo
Start free
Menu
← All articles

Release Managers: 2–4 Week String Freeze Checklist and Receipt

Release Managers: 2–4 Week String Freeze Checklist and Receipt

Release manager reviewing a freeze build

A string freeze locks every user-visible piece of text in your app so translators can finish their work without chasing edits. It applies to UI labels, error messages, and menu items, not to code logic or backend behavior. Call one 2 to 4 weeks before your release candidate, announce the exact date on your team’s release channel, and start exporting your translation files the same day.

TL;DR:

  • A strict string freeze typically lasts two to four weeks before release, during which no user-visible text changes are allowed without approval.
  • Exceptions must be formally requested with clear impacts, often requiring approval from the localization lead and release manager to prevent untracked changes.
  • Developers should export, unfuzzy, and share translation files early in the freeze to avoid last-minute chaos and ensure translation completeness.
  • Last-minute string changes should be logged, batched, and managed carefully to minimize translator rework and maintain language parity.
  • Automating export and validation workflows can significantly reduce manual effort and prevent fuzzy entries, especially for small teams without dedicated localization engineers.
Arkian
Simplify Your Next Localization Freeze
Arkian automates multilingual scripts, voice outputs, validation, and structured language packages for small teams managing release localization.

Table of Contents

What String Freeze Means and Why It Matters

A string freeze stops changes to translatable text, things like button labels, dialog boxes, notifications, and onboarding copy, while leaving code, styling, and non-visible logic open for continued work. The Fedora Project’s string freeze policy puts it plainly: the point is to give translators enough time to produce high-quality work without racing a moving target.

Skip this discipline and here’s what happens on the ground:

  • Every edited string turns “fuzzy” in translation memory tools, meaning the old translation is flagged as possibly outdated and needs re-checking.
  • Translators re-review strings they already finished, burning hours that should go toward new content.
  • QA has to re-test any screen where text changed, often days before ship.
  • Some languages ship with untranslated English fallback text because there wasn’t time to catch the change.

The cost isn’t abstract. A single “quick fix” to a button label two days before release can force a re-check across a dozen languages, and that re-check often takes longer than writing the original string.

Hard Freeze, Soft Freeze, or Something in Between?

Not every project needs an all-or-nothing lockdown. Choose the model that matches your release size and risk tolerance:

  1. Hard freeze. No new or changed translatable strings anywhere, full stop, until release. This is the Fedora and GNOME default, and it works best for smaller codebases or teams shipping infrequently.
  2. Soft or partial freeze. Non-critical or low-visibility strings can still shift with sign-off, while primary UI text locks. This buys engineering some flexibility without derailing translators.
  3. Modular freeze. Freeze by category or component instead of the whole app at once, UI-first, then help content, then marketing copy. Practitioner guidance on modular string freezes points to this as a strong fit for larger projects with frequent releases, since it avoids one giant freeze window stalling everything.
  4. Continuous localization. Some teams skip a formal freeze entirely and push strings to translators as they’re written, relying on automation to keep pace. This works only when your export and translation pipeline is fast and reliable enough to keep translators from ever chasing a backlog.

Most projects land on a hard or soft freeze lasting 2 to 4 weeks before the release candidate, announced with a specific end date, not a vague “sometime before launch.”

The Rules and How to Break Them Properly

The baseline rule is simple: no new or modified user-visible strings without prior approval. GNOME enforces this with a documented string change announcement period and a two-approver requirement from its Internationalization Coordination Team before any exception is granted.

A proper exception request should include:

  • A clear description of the string change and exactly which screens or flows it touches.
  • An honest impact assessment: how many languages are affected, and whether the change alters meaning or just fixes a typo.
  • The rationale for why this can’t wait until the next release.

Approval typically runs through your localization lead and release manager together, announced via a mailing list, a tagged ticket, or an internationalization (“i18n”) label so translators see it immediately.

Pro Tip: Set up a dedicated Slack channel or mailing list thread just for freeze exceptions before the freeze even starts. When requests are scattered across DMs and random tickets, approvals slow down and untracked changes slip through.

Your Pre-Freeze Checklist for Developers and Localization Teams

The week before freeze matters more than the freeze itself. Rushed prep here is what causes the fuzzy-string chaos everyone’s trying to avoid.

Work through this before you lock anything:

  • Export and lock your translation files. Generate clean POT/PO or XLIFF files, or JSON, iOS .strings, and Android XML exports depending on your platform, and verify your POTFILES list catches every source file, including any new branches merged recently.
  • Unfuzzy carefully, not aggressively. When you fix a typo or reword something without changing its meaning, use a tool like msgattrib to clear the fuzzy flag rather than forcing a full re-translation. The TranslateHouse unfuzzying guide warns against blanket unfuzzying, since it can mask genuine meaning changes translators need to see.
  • Preserve context, don’t erase it. Keep msgctxt entries and comments intact so translators know whether “Post” means a verb or a noun. Losing context here is one of the most common causes of mistranslation.
  • Give translators more than the string. Screenshots, variable annotations (what {count} or {name} actually renders as), and updated translation memory entries all cut back-and-forth questions dramatically.
  • Publish language packages early. Get exports into translators’ hands the day the freeze starts, not two days later. Mozilla’s localization notes point to keeping a maintained repository of PO files and using upkeep scripts like pomigrate2 so nothing goes stale between releases.

Before you officially mark the freeze as active, check translation completion percentages for every target language. A freeze announced on a Monday means nothing if half your languages haven’t received the export by Wednesday. Tools built around common TMS export formats, or a platform like Arkian’s localization strings handling, can shorten that gap by producing validated exports automatically instead of waiting on a manual pull.

What to Do When a String Has to Change Anyway

Sometimes a bug or a legal requirement forces a change after freeze. The goal is containing the damage, not pretending it won’t happen.

  • Keep a changelog of every post-freeze string edit, recording the original text and the new version side by side. This single document saves translators from guessing what actually changed.
  • Batch changes instead of trickling them out. One consolidated update sent once is far easier for translators to process than five separate pings over a week.
  • Lean on translation memory to auto-match anything similar to previously translated text, cutting redundant work for near-identical strings.
  • Decide early whether to extend the freeze or ship with a follow-up patch. A change touching a handful of strings in one language can usually wait for a post-release patch. A change touching core navigation across all languages may justify pushing the release date instead.

A Freeze Receipt: The Manifest That Makes Approvals Faster

Professional localization teams increasingly keep a compact manifest, sometimes called a freeze receipt, that proves language parity before anyone signs off on release. It’s a small file, but it answers the one question everyone asks during crunch: “are we actually ready?”

A useful receipt includes:

Field Purpose
Commit hash Ties the export to an exact source snapshot
Exported file list Confirms which formats were generated (JSON, .strings, XML, YAML)
Language coverage % Shows how complete each locale is
Fuzzy count per language Flags how much re-checking work remains

Drop this manifest into your CI pipeline as a gate, attach it to release notes, or post it directly to the release ticket so approvers aren’t hunting for status updates. Most export scripts and TMS platforms can already produce the raw numbers; the manifest just standardizes how you present them.

Pro Tip: Fail the build automatically if fuzzy counts exceed a set threshold for any required language. It’s a small check, but it catches the one language everyone forgot to look at.

Language tiles passing automated threshold gate

Where Freeze Discipline Usually Breaks Down

The biggest mistake is using the freeze window to “finally clean up” strings that should’ve been fixed weeks earlier. Freeze isn’t an editing sprint. Finish your wording before you lock it. A short dry run of your export and build pipeline before the real freeze catches plumbing issues while there’s still time to fix them, and time-boxing exception requests keeps approvals from dragging into the release date itself.

— Arkian

Let Arkian Handle the Export Grind Before Your Next Freeze

Preparing a freeze manually means someone on your team pulling exports, checking fuzzy counts, and formatting language files by hand, usually the same week everything else is on fire. Some platforms automate that production step: generating validated exports across JSON, iOS .strings, and Android XML formats, flagging issues that would otherwise create fuzzy entries, and packaging everything into structured, delivery-ready language files, without needing repository access or a full translation management system.

Arkian

That matters most for small teams who don’t have a dedicated localization engineer to babysit the export pipeline every release cycle. Arkian’s structured packaging and localization strings tools slot in as a production layer alongside your existing freeze policy, not a replacement for it. If you’re already thinking about your next freeze receipt, check Arkian’s pricing plans and see whether automating the export step saves your team the week it usually costs.

Sources

FAQ

What Are the Different Types of Freeze in Software Releases?

Release cycles typically use three freeze types: feature freeze, which stops new functionality; code freeze, which stops all code changes except critical bug fixes; and string freeze, which locks user-visible text for translation. String freeze often happens alongside or slightly after feature freeze, since new features usually introduce new strings.

What Does “Freeze Period” Mean in a Release Cycle?

A freeze period is a defined stretch of time, usually announced in advance, during which a specific category of changes (code, features, or strings) is locked down. For string freeze, that window commonly runs 2 to 4 weeks before the release candidate to give translators a stable target.

How Do You Request an Exception During a String Freeze?

You submit a written request describing the string change, its impact on affected languages, and why it can’t wait. GNOME requires two approvals from its Internationalization Coordination Team before any string change is allowed once the freeze is active.

Can You Change a String After the Freeze Has Started?

Only through the approved exception process, not unilaterally. Unapproved changes create fuzzy entries that force translators to re-verify work they’d already finished, which is exactly what the Fedora string freeze policy is designed to prevent.

Does Arkian Help With String Freeze Preparation?

Arkian automates the export and validation steps teams handle manually before a freeze, generating structured, delivery-ready language files across formats like JSON, iOS .strings, and Android XML. Current pricing and plan details are available on Arkian’s pricing page.