Brand glossaries: AI translation under your rules

Machine translation stopped being clumsy years ago. The output that comes back from a good model today is fluent, natural and grammatical, and that is precisely what makes it dangerous, because fluent copy gets shipped. The failure mode of AI localisation is no longer the obviously broken sentence. It is the perfectly readable one that is quietly off-brand.

Three versions of it turn up constantly. The product name gets translated: your bedding line becomes a literal German compound noun that has never appeared on any packaging, ever. The tagline gets re-translated: the sentence your legal and brand teams argued over for a month in 2024 comes back slightly different on every request, so ten ads carry four variants of a line that was supposed to be fixed. And the compliance phrase gets dropped: the qualifier that must accompany a product claim vanishes, because the model judged it redundant and nobody was checking twelve languages line by line.

None of these are fluency problems. They are authority problems. The model does not know which words are open for translation and which were decided long ago by people with sign-off. Left to itself, it will translate everything, because translating things is what it is for.

The fix is to make the decided words machine-readable. In Nubu that is the brand glossary: a per-market rule set that rides every AI translation request as binding constraints, feeds image generation, and gives the built-in assistant something concrete to check your copy against. This post covers what a glossary holds, how the claims library works, how the rules actually bind the model, and where the honest limits are.

What a brand glossary is in Nubu#

A glossary belongs to your organisation and covers one brand. Glossaries live on their own page at /glossaries, with their own permissions, so you control who can edit brand rules separately from who can edit campaigns. If you run one brand, you keep one glossary; an agency workspace keeps one per client brand.

The glossary itself is mostly a container. The substance hangs off it as market rule sets, one per market, because brand language is a per-market decision: the tone that works in Germany is not the tone that works in France, and a word that is fine in one market is banned in another. Each market rule set carries:

• Tone of voice, up to 500 characters describing how the brand speaks in that market. Formal or informal address, energy, register, the things this market's copy never does.
• Do not translate: terms that stay exactly as written in every language. Product names, feature names, trademarks, the English tagline you keep in English everywhere.
• Forbidden words: terms that must never appear in that market's output, whatever the model would naturally reach for.
• Approved phrases: the vocabulary the brand prefers, so when the model has a choice of phrasings it chooses yours.
• Approved translations: exact source-to-translation pairs that are reused verbatim. These are your pre-translated sentences and words. When a line has already been signed off in a market, the pair goes here, and the model does not re-translate what the brand has already decided.
• Exclude from visuals: terms that must not appear in generated imagery. These tell image generation what to keep out of the frame and are ignored by translation, which means one glossary governs both your words and your pictures.

Each market also carries aliases, and they matter more than they look. Market values in Nubu flows are free text: one campaign says "UK", another says "United Kingdom", a CSV column says "GB", a Korean office writes the market name in Hangul. The glossary matches each request's market value against the market name and every alias, case-insensitively, so all of those spellings resolve to the same rule set. Names and aliases are unique within a glossary, also case-insensitively, and a duplicate is rejected the moment you try to save one, because an ambiguous match would mean nobody could say which rules applied. And market rule sets respect validity windows: a rule set with effective and expiry dates stops matching outside them, while remaining visible in the editor.

Here is what that looks like for a fictional homeware brand, Fernhaven, selling into Germany and France.

Six decisions, written down once. "CloudWeave" survives every language untouched instead of becoming a literal compound. The tagline renders as the exact signed-off sentence in each market, not a fresh improvisation per request. German copy never says "billig", which reads as shoddy, and reaches for "preiswert" instead. The tone lines settle the du versus Sie and tu versus vous questions permanently, which is exactly the kind of decision that otherwise gets remade, differently, by every request.

That is terminology and voice. Claims are a bigger subject, and they get their own machinery.

Claims: the sentences legal actually cares about#

Terminology tells the model which words to use. Claims are different: they are statements about the product, and whether you may make them is a legal question with dates, scope and evidence attached. So Nubu holds claims as their own library inside the glossary, and each claim sits in one of three states:

• Approved: the claim may be used. "Woven from 100 per cent organic cotton."
• Prohibited: the claim must never be used. Fernhaven's legal team never substantiated "hypoallergenic", so it is recorded as prohibited rather than merely left unwritten, and now the system knows the difference between a claim nobody has made yet and a claim nobody may make.
• Needs qualifier: the claim may be used only with its qualifier line alongside it. "Keeps you cool through the night" carries the exact line "Compared with Fernhaven's standard cotton range", and the claim and its qualifier travel as a unit. The qualifier is not a note for humans to remember; it is the specific text that must accompany the claim.

Beyond its state, a claim can record a source, which is where it was substantiated: a study, a ruling, a legal sign-off. It names the products it covers, is scoped to the glossary's markets, and carries effective and expiry dates. An awards claim that expires at the end of the year is recorded with its expiry, and a claim approved for a launch next quarter is recorded with a future effective date. The assistant's claim reading respects both ends of the window: an expired claim is excluded and counted, and a claim that has not reached its effective date is excluded too, so a claim is never treated as live before its approval date.

Checking happens through the assistant. Ask it to check copy and it reviews the text against the claims library and the market's glossary rules, flagging problems by name:

• the copy contains a claim recorded as prohibited;
• a needs qualifier claim appears without its qualifier line alongside it;
• the copy uses a claim before its effective date;
• the copy uses a claim past its expiry.

Alongside those, it flags forbidden words from the matched market's glossary and rule violations from the delivery placement the copy is destined for, such as a headline over its field's hard limit. It works on one line or a whole batch in a single pass, or, pointed at a flow, on every written value in that flow, so nothing can be quietly skipped.

One thing needs saying exactly, because the difference matters. Claims checking is advisory. It is surfaced through the assistant; nothing blocks a build over a claim, and the build will not refuse to run because a prohibited claim appears in your copy. The check exists so that a human sees the flag before the ad ships, not so the machine can silently veto. Translation rules are the opposite case: they ride the translation prompt as binding constraints on every request the model receives. Rules constrain generation; claims checking informs review. Both are useful, and it is worth being clear about which is which.

How the glossary binds the AI#

The AI Translate node in the flow editor has a Brand glossary select. Choose the glossary once on the node and the rest is automatic: the glossary is set once and applies everywhere, on every lane, every build and every rebuild that runs through that node.

The binding works per request. A flow fans copy out by market and language, and each route arrives at the translate node carrying its own market value from the graph. The node matches that value against the glossary's market names and aliases, case-insensitively, picks the matching rule set, and sends it with that request as binding rules that outrank any other instruction. Only the matched market's rules travel: the French request carries the French rule set, the German request the German one, and the model only ever sees rules that exist.

Approved translation pairs get the strongest treatment. They are not hints; the pairs are supplied as exact source and translation text the model must reuse verbatim. That is what finally kills the re-translated tagline: the sentence the brand signed off is the sentence every ad gets, every time, rather than the model's fresh attempt at it.

The matching is honest about its edges. If a route's market value matches no market in the glossary, the node labels that value as running without rules, right on the canvas, so an unmatched market is a thing you can see rather than a silent gap. The fix is usually one alias: add the spelling your data actually uses and the match lights up.

Two behaviours keep the whole thing cheap. Unchanged content re-spends nothing: rebuild a campaign whose copy and rules have not changed and the build makes zero new provider calls. Edit the glossary and the next build re-runs exactly the strings those rules touch, under the new rules, and nothing more. And Original Language routes, the markets whose copy is already in its native language, pass through untranslated and unbilled: no request is made at all.

Two boundaries are worth stating plainly. There is no language list and no language count to quote: a translate step writes any language your connected model can write. And on cost, Nubu's AI runs on your own provider keys at raw provider prices with no margin added; the full model is covered in bring your own AI keys.

The visuals side completes the picture. The Exclude from visuals terms tell image generation what to keep out of the frame, while translation ignores them, just as image generation ignores the tone line. One glossary, maintained in one place, constrains what the brand says and what it shows.

Working with the assistant#

Everything above works with no assistant involved: build the flow by hand, pick the glossary on the node, and the rules bind. But this is where an assistant that can read your workspace starts paying rent, because brand rules are exactly the kind of context it should never guess at.

The assistant reads glossaries directly. Ask what rules exist for a market and it reads the full rule set, resolving aliases the same way the translate node does; ask about several markets at once and it reads them in one pass. When no glossary covers a market, it says so plainly and offers the real choice: add rules on the Glossaries page, or proceed without brand constraints for that market. Ask about claims and it reads the claims library the same way, split into live, upcoming and expired, and an empty library is reported as what it is: no claims managed yet, not an error.

The most useful habit is the whole-flow copy check. Ask the assistant to check a flow's copy and it reads every written value in the flow, template field values and Output copy alike, hand-written translations included, and checks each one against its own route's market rules and its own placement's field rules. It reports a coverage count with the verdicts, so a partial pass can never masquerade as a complete one. That turns "can someone read the German variants before this ships" from a favour into a thirty-second step.

The assistant can also propose changes to the rules themselves. Describe what you want, "add a Netherlands market with these do-not-translate terms, and record these two claims as prohibited", and it drafts the whole batch as a single approval card: glossary, market rule sets and claims together, applied in order, so a new glossary and its markets and claims can arrive as one reviewable unit. A human approves the card before anything is written, the record set is frozen at offer time so approval cannot sweep in records you never saw, and the assistant cannot delete anything: there is no delete in its vocabulary, because removing brand rules stays a human's own act. The full proposal model is covered in AI proposes, humans approve.

Setting up a glossary that earns its keep#

A glossary pays for itself in proportion to how decided its contents are. Some practical guidance from that principle:

Start with do-not-translate terms and approved translation pairs. These are the highest-value rules and the cheapest to write, because the work is already done: your product names exist, and your signed-off taglines exist. Ten minutes of copying them in removes the two most embarrassing failure modes outright.

Add claims where legal cares, not everywhere. The claims library earns its keep on the statements with legal weight: product performance, comparisons, certifications, offers with end dates. Record the prohibited ones as deliberately as the approved ones, and give every needs qualifier claim its exact qualifier line, because "must include a disclaimer" is not a rule a machine can check while "must include this sentence" is.

Write an alias for every spelling your data uses. Look at your actual campaign data and CSV columns before deciding you are done: if the data says "DE", "Deutschland" and "Germany" in different places, the market needs all three. Every alias you add is a silent mismatch you have removed.

Keep tone lines short and behavioural. "Informal address, short sentences, never exclamatory" gives the model something to obey. Five hundred characters is the ceiling, not the target.

Pair forbidden words with approved phrases. A ban tells the model what to avoid; the approved phrase tells it what to reach for instead. The pair together is worth more than either alone.

Use validity windows for anything campaign-bound. Seasonal claims and award mentions get expiry dates when they are created, while everyone still remembers why.

Honest limits#

A few things this system does not do, stated as plainly as the things it does.

Claims checking does not block builds. It is advisory, surfaced through the assistant's copy check, and there is no gate that refuses a build over a prohibited claim. If a flagged claim ships, it shipped because the flag was not acted on, and your review step is where that gets caught. Nubu's position is that a human approves each market's creative before it renders and delivers; the tutorial in translate video ads at scale shows that review loop end to end.

The mechanical checks match exact wording. The copy check finds a prohibited claim or a forbidden word by its wording, whatever the capitalisation. A paraphrased claim, the same promise in different words, is beyond a mechanical pass, and judging paraphrase remains reading work for the assistant and for you.

Rules constrain, they do not measure quality. The glossary guarantees your product names survive, your signed-off lines are reused verbatim and your banned words stay out. It does not certify that a translation is good, which is why the approval step exists and why it is per market.

It sits on the Business+ plan. The AI toolkit, your own provider keys, the AI nodes and brand glossaries, is part of Nubu's top tier; details on pricing.

Prompts to try#

Four asks that put the glossary to work from the chat panel:

• "What rules does the Fernhaven glossary hold for Germany, and does DE resolve to them?": a direct read of the market's rule set, with aliases resolved the same way the translate node resolves them.
• "Check every written value in the Spring flow against the glossary": the whole-flow advisory check, reading every written value in the flow so nothing is skipped, with a coverage count alongside verdicts for forbidden words, prohibited claims and missing qualifiers.
• "Which of our claims expire before the end of December?": the claims library read back as live, upcoming and expired, so seasonal claims stop being a memory exercise.
• "Add a Netherlands market: CloudWeave never translates, informal address, warm and unfussy tone, and record the hypoallergenic claim as prohibited there too": one approval card carrying the market rule set and the claim changes together, applied in order once a human approves it. Nothing is written before that click.

Make the decided words machine-readable#

The pattern behind all of it is small: every piece of brand language that has already been decided should be written somewhere a machine is required to respect it. Terminology and tone bind every translation request. Approved pairs are reused verbatim. Claims carry their states, qualifiers and dates, and the assistant checks copy against all of it on request, whole flows at a time.

If you are localising ad creative with AI in the loop, set up the glossary before the next batch runs, because every request that runs before your rules exist runs without them. The glossaries guide covers setup step by step, and you can start with a free account and bring your own model keys when you are ready to translate.