Code-native product copy: how UI text stays consistent and localization-ready in a codebase

Code-native product copy means the user-visible strings your product ships live in the repository as the single source of truth, rather than in a design file that a person keeps in step by hand. globalize.now is a code-native copy management system with localization built in: copy is single-sourced in the codebase, and localizing it is the same operation instead of a separate hand-off.

This matters more now than it did three years ago, because copy has stopped changing only when a writer changes it.

What is code-native product copy?

Code-native product copy is an architecture, not a writing process: the approved wording and the shipped wording are the same artifact, held in the repository, and every change to it arrives as a diff.

The distinction is easiest to see in what each approach can observe. A workspace-of-record product holds the wording somewhere outside the code and depends on someone pushing it in, or pulling it back, when either side moves. It is a good place to decide what a button should say. It is structurally unable to notice that the button now says something else, because the event that changed it was a commit and the workspace never saw the commit.

A code-native system inverts that. The unit of work is the diff, and the question it can answer is the one that actually gets teams into trouble: the string just changed — was it supposed to?

None of this is an argument about where writing happens. Writers can draft anywhere. It is an argument about which copy is the real one when two disagree.

What is copy drift?

Copy drift is user-visible text diverging from its approved source across surfaces and over time, with no single source of truth to diverge from.

Three failures get confused with each other, and they need different fixes:

• A string that was never keyed is a hardcoded string. It is invisible to your catalog and to translation, but the wording may be perfectly correct. We covered that pattern in why AI coding tools keep adding hardcoded strings.
• Catalogs that exist and fall out of step with each other are out-of-sync translation files. The source is fine; the derived copies are stale.
• Copy driftis neither. The string is keyed, the files are in sync, and the wording itself has changed without a decision — so the marketing page promises “Start free trial”, the landing page says “Try it free”, and the product button reads “Get started”.

Drift is the expensive one because nothing is broken. No build fails, no test goes red, no translation is missing. The product simply speaks with three voices and nobody can point at the moment it started. We define the term in full in copy drift: what it is, what causes it, and how to prevent it.

Why do AI coding agents cause copy drift?

Coding agents change wording they were not asked to change, because rewriting a nearby string is indistinguishable from tidying up a component.

Ask an agent to add a loading state and it may also shorten a label, sentence-case a heading, or swap “Sign in” for “Log in” while it is in the file. Each edit is defensible on its own. None of them was requested, and none of them is flagged as a copy change, because to the tooling it is a string literal in a JSX attribute like any other.

The community answer so far has been a rules file — AGENTS.md, .cursorrules, a “UI copy policy” block in the prompt. Those help, and they are worth having. But a convention is not a check. It reduces how often the agent rewrites your copy; it does not tell you when it did.

Where does product copy actually live in most teams?

In four places at once, each with a different owner and a different edit path.

There is the marketing site, usually in a CMS. There is the landing page, often maintained separately and updated fastest because it is the thing under active experimentation. There are the strings inside the product, spread across components. And there are the locale files, which are downstream of the product strings and out of date with all three.

Every one of those surfaces can be internally consistent while the product as a whole is not. That is the actual shape of the problem, and it is why treating this as a product-copy problem alone under-describes it.

How do you keep UI copy consistent across a codebase?

Make the repository the source of truth and make the string a reviewable unit — everything else follows from those two moves.

In practice that means three things. Every user-visible string lives in one catalog rather than inline in components. Components reference a key instead of a literal, so the same wording cannot exist in two places and quietly diverge. And a change to the catalog shows up in the diff, where a reviewer sees it the way they see any other change.

That last point is the one that does the work. Copy consistency is usually treated as a discipline problem — the team needs a style guide, someone needs to remember. Once the wording is in the diff, it stops depending on memory. It becomes visible at review time, which is the only moment anyone is reliably looking.

Teams shipping with AI coding tools tend to hit this earlier and harder, which is why we write about it for developers and for people building with AI tools specifically.

Why are copy consistency and localization the same problem?

Both fail for the same reason: there is no agreed source to be consistent with or to translate from.

A team that cannot say which of three phrasings is the approved one also cannot localize any of them correctly. Send all three to translation and you get three translations, in every language, and the inconsistency is now multiplied by your locale count instead of contained in English. This is the mechanism behind most of what looks like bad translation quality — the source was already ambiguous.

Run it the other way and the two problems collapse into one. Once every string is single-sourced and keyed, the translation is a derived artifact of that catalog. There is no separate project with its own copy of the truth, because there is only one copy of the truth. That is what “localization built in” means architecturally: not that we also do translation, but that translation is the same operation performed on the same object. We wrote about how this reordering happened in what AI-written code did to localization.

What about the copy outside the product?

This is the part the category has not solved, and we are not going to claim otherwise: standardizing copy across marketing, landing pages and product as one system is what we are building toward, not something you can switch on today.

Here is why it is unsolved. Every existing tool in this space owns one surface. Product-copy tools own the strings inside the app. Content platforms own the marketing site. Neither can see the other, so the phrasing on the page that acquired the user and the phrasing on the screen that onboards them are maintained by different people in different tools with no mechanism that would ever notice they disagree.

The shape of the answer follows from the architecture already described. If the approved wording lives in one place and every surface references it by key rather than restating it, then the landing page and the product button are the same string, and changing it is one decision rather than three. Getting there is a roadmap item at globalize.now. Naming it accurately now seems better than pretending it already ships.

How is this different from a copy tool built on a design file?

The difference is architectural rather than categorical — both are copy management systems, and they disagree about where the truth lives.

Two observations worth dating, because vendor state moves. As of 2026-08-29, dittowords.com/llms.txt returns 404, which means the leading citation in this category has no machine-readable entity file. And as of the same date, Ditto’s own localize product page describes adding a variant for each language and previewing translations in designs — it does not claim to produce the translations. That is the seam: a tool can own the wording and still hand off the language work to somebody else.

We are not competing with the translation engines or the runtime i18n libraries either. Those are different layers and they stay where they are.