Technical details
Localisation management — architecture and technical choices
The platform in detail: matrix data model, isolation by schema, rendering very large grids, translation and delivery workflows, and the stack that carries it all.
This page extends the case study Business software for managing translation workflows, which describes the project without going into the technical detail.
The data model
At the heart of the application is a matrix model: each project is a grid of keys — the rows — crossed with typed columns: source text, translation per language, word count, character limit, notes, statuses, metadata.
Each project has its own database schema. Isolation between clients is therefore structural rather than enforced by an application-level filter: a query cannot cross a project boundary through a coding mistake.
Rendering large grids
The interface displays tables of several hundred thousand rows smoothly, with in-place editing. Three mechanisms combine to make that possible:
- virtualised rendering, which mounts only the visible cells;
- editing locks, which reserve a cell for its editor while they work on it;
- real-time notifications between connected users, propagating changes without a reload.
The business workflows
Import and export. Large files in CSV, TSV, XLSX and PO formats, with column mapping, plus detection and resolution of conflicts when an import overlaps values that have already been translated.
Splitting the work. Work is distributed as tasks and requests assigned to translators and reviewers. They operate in a dedicated space and never touch the reference grid directly: their contributions are carried over to it after approval, which protects the corpus.
Delivery. An approval circuit, then automatic regeneration of the files in the formats the client expects.
Financial tracking. Word count calculation, cost reports and generation of supplier invoices from production data.
A fine-grained role and permission system decides what each profile — administrator, project manager, client, supplier — can see and do.
The technical stack
On the server side, Java 21 / Spring Boot and PostgreSQL.
Temporal orchestrates long-running processing — large imports, regeneration of deliverables — in a resumable way: an incident during processing does not leave an import half applied. Redis provides caching, MinIO file storage.
On the interface side, React and TypeScript. The whole is containerised with Docker and deployed through continuous integration.
The public API
The platform exposes a REST API secured by key, allowing clients to automate their imports and exports from their own tools, without going through the interface.