1. Problem

Inconsistent translations and wasted effort across projects

Core issues:
Organizations managing multiple projects (web + mobile, Android + iOS, product variants) face critical translation challenges:

• Duplicate work: The same phrases are translated repeatedly in each project. "Add to cart" gets translated 3x across 3 projects — pure waste.
• Inconsistency: One project uses "Next", another "Continue" for identical source text. Users perceive this as unprofessional and confusing.
• Isolated translation memories: Each project maintains its own TM with no sharing. New projects start from zero, ignoring existing translation work.

Additional enterprise challenges:

• Quality degradation: Poor translations in TM get propagated through AI and auto-translate features, multiplying errors across the system. (This could be addressed by controlling data quality in the shared TM used for reading.)
• Legacy migration: Large companies need to import existing TMX files from other tools and make them accessible across all projects.

Business problem:
To be competitive in the enterprise localization market, Tolgee must support cross-project resource sharing. For enterprise clients, this is essential — including TMX import/export capabilities. Without this, we lose deals to established competitors.

---

2. Appetite

One cycle (4 weeks)
The frontend reuses UI components from Glossaries and the TM translation view, which should significantly reduce UI work.

---

3. Solution

Based on competitive analysis of existing localization platforms, we propose the following design — taking the best patterns while keeping complexity low.

Pricing & Availability

• Free plan: No shared TM. The existing "similar translations" feature stays, but must be renamed and all references to TM removed — suggestions, links, bulk operations (Pre-translate by TM).
• Business plan: Full TM available.

TM Architecture

TM is a single object type — it behaves the same everywhere. The only difference is how many projects have access to it.

• When a project is created, a project TM is automatically created and assigned only to that project.
• At the organization level, users can create any number of additional TMs and assign them to multiple projects — this is how sharing works. The requirement is a matching source language across projects.

Organization Level: TM Management

New section in Organization Settings with two tabs:

• TAB Shared TMs — shared TMs created at the organization level
• TAB Project TMs — project TMs created automatically. Not shown by default, but users can view their project TM and upload data to it independently.

Capabilities:

• Create named Translation Memory instances (e.g., "Main", "Product A", "Legal")
• Browse TM content (source/target langs table with search)
• Import/export TMX
• Delete entries or entire TM
• See which projects use each TM

Project Level: TM Configuration

In Project Settings:

• List of connected TMs with priority ordering
• For shared TMs: configure read/write access per TM
• User can set TM priority — by default shared TM has higher priority

Rules:

• A project must always have at least 1 TM — the project TM, which is destroyed only when the project is deleted
• Shared TMs can be deleted manually
• When a project is removed from a shared TM, its historical data stays in the TM, new translations stop being written. User gets the choice: keep or delete this project's records from the shared TM.

Opt-in sharing model: We prefer project TM as an isolated base, with sharing as a conscious opt-in. A single org-wide TM shared automatically causes noise in practice — translations from unrelated projects (marketing web, mobile app, developer docs each with different tone of voice) mix together. If we hit major problems during implementation, we can switch approach.

Writing to TM

• Trigger: Translation is saved to TM automatically on every save. Each record always links to the specific translation (translation ID) — so when a translation changes, the TM record is updated instead of creating duplicates.
• Project setting — toggle: "Save to TM only Reviewed translations". Default off — all translations are saved.
• Where it writes: Based on the project's TM assignments — records go to TMs that have write access enabled. If the project has multiple write-enabled TMs, it writes to all of them.
• On translation change: The TM record is updated via the translation ID link — no duplicates.

Reading from TM (Suggestions, AI prompt, Auto-translate)

Match logic — carried over from current implementation: suggestions show from 50% match upward. For each suggestion: translated text, source text, match percentage, key name.

1. Inline suggestions in editor: When translating a key, TM suggestions show automatically. Clicking applies the suggestion to the editor.
2. Pre-translate (batch): Bulk pre-fill of a language or project from TM. Configurable minimum match threshold. Uses existing logic.

Which TMs are searched: All TMs assigned to the project. Results are sorted by match percentage. In project settings, user can set TM priority — the prioritized TM is searched first when match percentage is equal.

TM Data Format

Import and export TM in TMX 1.4b format — the industry standard for localization, compatible with all major CAT tools.

Each TM record stores: translation language, source/target text, key name (context), creation date, author, last change date, and last change author.

Detailed format specification to be explored during Shape-up.

TMX Import & Export

• Import TMX files directly into an existing TM. Import is simple — does not resolve conflicts record by record.
• Confirmation dialog: Before import, user decides whether to overwrite existing records or ignore them (keep current).
• Export: Download the entire TM as a TMX file.

Conflict Resolution

When selecting a TM suggestion, the system decides progressively:

1. Match percentage — the suggestion with the highest match percentage takes precedence
2. TM priority — when match is equal, the TM priority order set in the project decides

---

4. Basic Drawings

Sketches to discuss
https://www.figma.com/design/H6BDCYRjNFgXymTtnkQriW/Tasks-2026?node-id=1-31&t=CfpgqhcDb4yunQnU-1

---

5. Rabbit Holes

• Performance for batch operations — Auto-translate 40k keys x 5 languages must not be slower than the current solution
• Deduplication — Handled via translation ID linking: TM records update on change instead of creating duplicates
• Merging TMs — Admin action to promote translations to shared TM — keep simple
• Migration — Strategy for existing data and auto-translate configs
• Priority logic — Search all assigned TMs, rank by match percentage first, then by TM priority
• TMX format specification — Detailed mapping of Tolgee fields to TMX properties to explore during Shape-up

---

6. No-Goes

• Avoid big complexity and scope, keep it simple
• No record-by-record conflict resolution during import (simple overwrite/ignore dialog)
• No contextual/AI-driven match evaluation

---

7. Success Criteria

• More business/enterprise customers
• Better AI results (through higher-quality shared TM data)
• Shared TMs are used by our customers
• No performance regression for existing batch operations
• TMX import/export works with standard CAT tools

---

Research reference: Translation Memory Platform Comparison 2026 — competitive analysis of existing localization platforms