String freezing

When a team reaches string freeze, developers stop making changes to any user-facing text. No strings can be added, removed, or reworded until the freeze is lifted. This gives translators a defined window to complete their work with confidence that the content they are translating will not shift underneath them before release.

The freeze typically happens after feature development is complete but before the final build goes out. During that window, developers can still fix bugs and make code changes, as long as those changes do not touch translatable strings.

🤔 Why it matters for localization #️⃣

Translators need a fixed reference. If the source text changes during translation, earlier work may need to be redone, slowing down delivery and increasing the chance of mismatched or missing translations in production. Freezing gives everyone a clean baseline, syncs development and localization timelines, and makes release cycles predictable for both sides.

The duration of a string freeze varies by team and release size, ranging from a few days to several weeks depending on the number of languages and strings involved.

In teams using continuous localization, the concept of a hard string freeze becomes less rigid. Since strings are translated incrementally as they are written, there is no single freeze event. However, even in agile workflows, teams may still declare a soft freeze close to a major release to prevent last-minute string churn from disrupting translators who are close to finishing.

🔗 String freeze vs. code freeze #️⃣

These two often happen around the same time but are not the same thing. A code freeze locks all code changes, including logic and functionality. A string freeze specifically locks translatable content. A team can be in string freeze while still actively pushing code, as long as that code does not affect any user-visible text.

Some open source projects like GNOME and Fedora have formal freeze exception policies that require approval from a localization steering committee before any string change is allowed during the freeze period.

🧊 Key points about string freezing #️⃣

• Prevents new or updated source strings from disrupting translation progress close to a release.
• Developers can continue working on bug fixes and non-string code changes during the freeze.
• Breaking a string freeze by rewording a string after translators have started invalidates existing translations and forces rework.
• In continuous localization workflows, the hard freeze is largely replaced by automated detection of string changes, but soft freezes before major releases are still common.
• Works naturally with versioned release workflows that separate dev, staging, and production translation states.

🤨 How does Localazy handle this #️⃣

Localazy supports this workflow through Releases, which act as versioned snapshots of your translation state. A release locks the exact strings used for a specific version of the product, even if the main project keeps evolving. This mirrors a traditional string freeze but with full automation and a clear separation across dev, staging, and production environments, without requiring manual coordination between developers and translators.

See how to properly do this on Localazy in our documentation.