String freeze
The pre-release cutoff when UI wording stops changing so translators and localization QA can finish against a stable build.
What it is
A string freeze is the date after which source UI copy stops changing for a release. It gives translators time to finish the final batch and gives localization QA a stable build to test. It freezes words, not code: engineers can still fix bugs as long as those fixes do not add, remove, or rewrite user-visible strings. GNOME has run a formal string freeze before every stable release for decades, and breaking it needs sign-off from the translation team rather than a quick commit.
Set it by working backward from launch. Leave enough room for the last catalog export, translation, linguistic review, import, and an in-app QA pass in every target locale. After the cutoff, route genuine release blockers through an exception process and tell translators exactly which segments changed.
Gotcha: a freeze without enforcement is only a calendar note. A tiny English edit can invalidate completed translations, screenshots, and approval status across every locale. Do not sneak copy polish into bug fixes, and do not freeze so early that translators work from screens which no longer resemble the product.
Ask AI for it
Enforce a string freeze for this release with GitHub Actions. Record the cutoff timestamp and protect every source message catalog after it: fail a pull request that adds, removes, or changes a source string unless it has the label 'string-freeze-exception'. When an exception is present, produce a machine-readable diff of changed translation keys, add the localization team as the CODEOWNERS owner of the source catalog paths so branch protection demands their review, and post the affected keys and locales in the check summary. Ignore code-only changes and generated target-locale catalogs.