This page explains the core building blocks of Entri. Understanding how these pieces fit together will help you design your localization workflow and get the most out of the platform.
Projects
A project is the top-level container in Entri. It maps to a single product, application, or repository that needs to be localized.
Each project has:
- A source language — the language your team writes content in (usually English).
- One or more target languages — the languages you translate into.
- A set of keys and their translations.
- Its own member access and settings.
Most teams create one project per application. If you have a large product with multiple distinct surfaces (a web app and a mobile app, for example), you may choose to create separate projects to keep them organized.
Keys
A key is a named translation string — the fundamental unit of localized content in Entri.
Every key has:
- A key name — a unique identifier within the project, typically dot-separated (e.g.,
auth.login.title or settings.profile.save_button).
- A source value — the string in your source language.
- A translation for each target language.
- An optional namespace grouping.
- Optional metadata such as a description, screenshot context, or tags.
Key names should be stable. Once a key name is referenced in your codebase, renaming it in Entri without updating your code will break the reference.
Add a description to your keys to give translators context about where the string appears and how it should be read. A note like “Button label on the checkout page” makes a significant difference in translation quality.
Namespaces
A namespace is a grouping of related keys within a project — typically corresponding to a feature, page, or file in your codebase.
For example, you might organize keys like this:
auth/ → login, register, forgot-password screens
dashboard/ → main dashboard and sidebar
settings/ → all settings pages
Namespaces map directly to file names when you import or export translations, so they make it straightforward to keep your Entri structure in sync with your code structure.
Source and target languages
The source language is the language your team writes in — the authoritative version of every string. All translations are derived from the source value.
Target languages are the languages you translate into. You can add as many as you need. Each target language tracks its own translation status independently.
Translation status workflow
Every translation moves through a defined status lifecycle:
| Status | Meaning |
|---|
| Untranslated | No translation exists yet for this key in this language. |
| Translated | A translation has been provided but not yet reviewed. |
| Reviewed | A reviewer has checked the translation for quality. |
| Approved | The translation is finalized and ready to ship. |
You can filter the translation editor by status to focus on what needs attention — for example, to find all strings that are still untranslated before a release.
Translation Memory
Translation Memory (TM) is a database of previously translated strings that Entri maintains automatically.
When you’re editing a key, Entri searches your TM for strings that are identical or similar to the source value and surfaces them as suggestions. This saves time and improves consistency — a phrase that was translated once can be reused across your project.
Key properties of TM in Entri:
- Automatic — TM is populated when AI translations are saved; no setup required.
- Fuzzy matching — finds similar (not just identical) strings, with a match percentage shown.
- Cross-project — TM is shared across all projects in your organization, so work done in one project benefits all others.
Glossary
The Glossary is your organization’s dictionary of approved terms and their translations.
Use it to define product-specific terminology, brand names, and phrases that should always be translated (or explicitly left untranslated) in a specific way. For example:
| Term (EN) | Dutch (NL) | French (FR) | Notes |
|---|
| Dashboard | Dashboard | Tableau de bord | |
| Entri | Entri | Entri | Do not translate |
| Translation Memory | Vertaalgeheugen | Mémoire de traduction | |
When a glossary term appears in a source string, Entri highlights it in the editor and uses the approved translation when generating AI suggestions. This ensures AI-generated translations stay on-brand even for terminology that models might otherwise handle inconsistently.
Glossary entries can be marked Do not translate to preserve brand names or product terms in all target languages.
AI translation
AI translation lets you generate translations automatically using large language models — currently Anthropic Claude Sonnet and OpenAI GPT-4o.
AI translations in Entri are:
- Context-aware — the model receives surrounding strings, namespace context, and any description you’ve added to the key.
- Glossary-aware — your organization’s glossary terms are included in the prompt so the AI respects your approved terminology.
- Scored — each AI suggestion includes a confidence score so you can prioritize which translations need human review.
AI translations start in Translated status. A reviewer should verify and approve them before they are considered final.
Import and export
Entri supports importing and exporting translation files in the formats most commonly used by development frameworks:
| Format | File extension |
|---|
| JSON (flat) | .json |
| JSON (nested) | .json |
| Android XML | .xml |
| iOS Strings | .strings |
| Gettext PO | .po |
| Gettext POT | .pot |
| Gettext MO | .mo |
Importing a file creates new keys and fills in translations. Exporting produces a file in the same structure, ready to drop into your codebase.
CLI and API
For developer workflows, Entri provides:
- CLI (
nt3) — push source strings from your codebase and pull translations back down. Designed for use in CI/CD pipelines.
- REST API — full CRUD access to all resources (projects, keys, translations, glossary, TM).
- GraphQL API — query the data model with flexibility for complex integrations.
- Webhooks — receive real-time events when translations are created, updated, or approved.
How it all fits together
Your codebase
│
│ nt3 push (source strings)
▼
Entri Project
├── Keys (organized by Namespace)
│ └── Translations per language
│ ├── Status workflow (Untranslated → Approved)
│ ├── AI suggestions (Claude / GPT-4o + Glossary)
│ └── TM suggestions (from past approved translations)
│
│ nt3 pull (approved translations)
▼
Your codebase (translated files)
A typical workflow looks like this: developers push new or changed source strings to Entri via the CLI. Translators open the editor, work through untranslated keys using AI suggestions and TM matches, and submit for review. Reviewers approve translations, which populates the TM and triggers a webhook. The CI pipeline pulls the approved translations and deploys.