# Brand terminology console that pushes terms live to DeepL

> Keep every approved product, feature, and industry term in one spreadsheet, then push it live to DeepL so every translation across the company uses it.

- Workflow type: app
- Services: DeepL, Google Sheets
- Categories: Marketing, Operations
- Published: 2026-08-21

## What it does

- One table of every approved term with the signed off translation for each language, an owner, and the date it was last reviewed, all editable right in the app and saved straight back to your spreadsheet.
- Filters that surface the terms that have gone stale past their review date and the ones that changed since the last publish, so reviewers are never working from an old list.
- A Publish button that pushes the approved terms for one language pair live to DeepL, retires the version it replaces, warns you first about terms with a missing translation, and keeps a history of who published what and when.
- A test bench and an audit: paste real marketing copy to see the translation with and without your terms side by side, or kick off a background check that verifies every approved term actually comes through and writes a pass or fail verdict with suggested fixes back into the app.

## What you'll need

- A DeepL API account (Free or Pro) with a key from your account page
- A Google account with edit access to the spreadsheet that holds your term list
- A term list with one row per term: the English source, a column for each target language, an owner, and a last reviewed date. An empty sheet with those headings works fine as a starting point.
- Glossaries only work for some language combinations, so the app will only offer the pairs DeepL actually supports

## Prompt

Build me a brand terminology console. Our localization manager is the main user: she maintains the approved translation of every product name, feature name, and industry term, and she needs to push that list live to DeepL so every translation the company runs uses the same wording. The term list lives in a Google Sheet, and that sheet stays the editable source of truth. The app is the working surface on top of it plus the publishing pipeline into DeepL.

Data source. Read the term list from Google Sheets with Get Values. The Terms tab has one row per term with these columns: English source term, one column per target language holding the approved translation (for example German, French, Spanish, Japanese), an owner, a last reviewed date, and a notes field. Let me set the spreadsheet ID and tab names in app settings so I can point it at our sheet. Save every inline edit back to the same row with Update Values, and add new terms with Append Values so nothing above them shifts. Also keep two more tabs the app writes to: a Publish Log tab and a Review tab.

Main screen. A table with one row per term showing the English source, the approved translation for each target language, the owner, and the last reviewed date. Every cell is editable inline and saves back to the sheet. There is an Add term button that appends a new row. Above the table put two filters that give me a reason to open the app: a language pair selector that narrows the table to the source and target columns for that pair, and a Stale toggle that shows only terms whose last reviewed date is older than a review window I can configure in settings (default 90 days). Show a count of stale terms and a count of terms missing a translation for the selected pair right at the top, so the work to do is visible on open. There is also a Changed since last publish view that compares the current sheet rows for the selected pair against the entries that were live at the last publish, and lists added, edited, and removed terms, so reviewers are never working from a stale list.

Publishing. A Publish button turns the sheet rows for one language pair into a live DeepL glossary. Populate the language pair selector from DeepL List Glossary Language Pairs so the app only ever offers combinations that glossaries actually support. When I hit Publish, first show a confirmation panel with the entry count, the diff against what is currently live, and a warning listing any term that has no translation in that target language, with the option to fix it first or continue and skip those rows. On confirm, call DeepL Create Glossary with the source and target language and the entries built from the sheet rows, then call Delete Glossary on the glossary this one supersedes. DeepL v2 glossaries are monolingual and immutable, meaning one source to target pair and no editing after creation, so replace and delete is the only way to update, and the app should explain that in the panel rather than making the user wonder why a new glossary ID appears every time.

Version history. After every successful publish, append a row to the Publish Log tab with Append Values recording the timestamp, who published, the language pair, the new glossary ID, the retired glossary ID, and the entry count. A History panel lists those publishes newest first, and can pull the live state for a selected entry with DeepL Retrieve Glossary Details and List Glossaries so I can confirm what is actually live in DeepL right now versus what the log says. Let me open any historical publish and see the entries that were live at that moment using Retrieve Glossary Entries, which returns them as TSV, so parse that into rows before displaying.

Test bench panel. I paste a paragraph of real marketing copy, pick a language pair, and hit Check. The app calls DeepL Translate Text twice on that paragraph, once with the live glossary for that pair applied and once with no glossary, and shows the two results side by side. Highlight every span that differs between the two versions, and underneath list the approved terms that appear in the source text along with whether the glossary version actually produced the approved translation. The point is to let the manager prove to stakeholders that the glossary is doing something, so the difference has to be visually obvious, not buried in a diff.

Term audit background agent. A Term audit button kicks off a background agent for the selected language pair. The agent uses DeepL List Glossaries to find the live glossary, pulls its current entries with Retrieve Glossary Entries (TSV), and for each approved term writes or selects a small batch of natural sample sentences that use the English term in context. It translates each sample with DeepL Translate Text using the glossary, checks whether the approved translation actually came through, and produces a pass or fail verdict per term with a short reason and a suggested fix when it fails, for example when the term needs a different inflection, when the source casing does not match, or when a shorter overlapping entry is winning. The agent writes its results back with Append Values into the Review tab, one row per term with the verdict, the failing sample, and the suggestion. The app has a Review panel that reads that tab and shows the latest audit run, filterable to failures only, with a button on each failing row that jumps to the matching term in the main table so I can fix it and republish.

Rules and nuances to bake in. Never publish silently over a pair with missing translations, always warn first. Only offer language pairs that DeepL supports for glossaries. Treat the sheet as authoritative and DeepL as the derived artifact, so the app never edits terms in DeepL directly. Show the last publish timestamp per language pair on the main screen. Handle DeepL glossary entries being returned as TSV when parsing. Keep the whole thing usable by someone non technical: the manager should see terms, owners, dates, and a Publish button, not glossary IDs, with the technical identifiers tucked into the history panel for when something needs debugging.

## How to customize

- Change the review window that marks a term stale, for example anything not reviewed in the last 90 days
- Add or remove target language columns as you expand into new markets
- Swap the sample sentences the audit uses so the check runs against wording from your own product copy

## FAQ

### Can I just edit a glossary inside DeepL instead?

Not once it is created. DeepL glossaries cannot be changed in place, which is the whole reason for this app: when you publish, it creates the new version and retires the one it replaces, so your spreadsheet stays the single source of truth and nobody has to hand rebuild a glossary.

### Does this work with a free DeepL account?

It works with a DeepL API account, free or paid. Glossary support depends on your plan and on the language combination, and the app only offers the pairs DeepL supports, so you will not hit a dead end after filling in a whole column.

### What happens if a term is missing a translation in one language?

You get a warning before anything goes live, listing exactly which terms are incomplete for that language pair. You can go fill them in or publish anyway, knowing what is missing.

### Can my team keep working in the spreadsheet?

Yes. The spreadsheet stays the source of truth. The app reads and writes the same rows, so an edit made in either place shows up in the other.

### How do I prove the glossary is actually doing something?

Paste a paragraph of real marketing copy into the test bench and hit Check. You get the translation with your terms applied and without, side by side, with every word the glossary changed highlighted.

### How will reviewers know when an approved term changes?

The app keeps a version history of every publish and a view of the terms that changed since then, so anyone opening it can see what moved and when it last went live.

Use this prompt in General Input: https://www.generalinput.com/prompts/brand-terminology-console-that-pushes-terms-live-to-deepl