How to rename a language (change its code)?

Sometimes a language was created under the wrong code, for example Norwegian Bokmål content living under nn (Nynorsk), or a plain de that should be de-DE. You do not need to recreate the language or migrate content by hand, and you do not need to contact support: renaming a language is a normal self-service action.

Steps

Open your Project settings and select the PROJECT SETTINGS tab.
In the Languages card, pick the version if your project has several, then open the menu of the language and choose rename.
Pick the new code. The list offers the standard codes; a custom code can be typed, but stick to standard BCP 47 codes so machine translation, AI and exports identify the language correctly.
By default the rename applies to the selected version only. Enable Rename in all versions to change the code everywhere at once. Then confirm.

The rename runs in the background; a large project takes a few moments.

What moves automatically

All translations of that language in the renamed version(s), together with their per-segment history and review data. Fuzzy markers and tags survive.
Published files: the old code's files are removed from the CDN. A version with auto-publish republishes under the new code right away; a manually published version shows the new code on the CDN with its next publish.
Statistics are recalculated.
Permissions: team members, pending invitations and API keys whose restriction names the old code follow the rename; each adapted permission shows up in the audit log.
Language-keyed settings: glossary terms, the styleguide (per-language guides and the AI language mapping), per-language AI provider context, order-service language mappings, the review workflow language list and the source language override for orders.
After a single-version rename, permissions and settings carry both codes: the old one is only dropped once no version of the project uses it any more.
Branched projects and tenants that stay in sync with the parent follow automatically; the dialog's Execute this also on all tenants switch extends the rename to tenants that do not sync.
The translation memory needs nothing: it is built from the published content, so the entries are simply found under the new code afterwards.

Renaming a language (like any change to the project structure) needs an admin or manager permission without a version, language or namespace restriction, see user management.

Side effects to plan for

Your app must request the new code. Requests for the old code receive an empty file, and i18next falls back according to fallbackLng. Adapt your integration (i18next supportedLngs / language detection, CLI or CI configuration that names the code) and deploy it together with the rename.
Fresh "last changed" timestamps. Every segment of the renamed language counts as changed at the moment of the rename. "Changed last x days" filters will show them, and if you rename the source language, all target languages are flagged with issue 302 afterwards (the source now looks newer than every translation). If you rely on such filters or tags for your workflow, set them up before the rename.
Finish open translation orders first. A rename clears the "ordered" marker on the renamed language's segments, so results of an order that is still running for that language can no longer be imported automatically. Wait for open orders to complete (or avoid placing one) before renaming.

Which code to pick

If you use several Locize projects as a shared translation memory, use the same code in every project: memory suggestions match on the exact language code, so no-NO in one project and nb-NO in another will not see each other's entries.

Changing which language is the source (reference) language is a different operation, see What happens when I change the source language? Renaming a namespace works similarly to a language rename, see How to delete or rename a namespace?