Overview
LocaleHub is a content management admin panel that we designed and built for teams who publish in more than one language. It keeps each piece of content beside its translations and shows, for every language, how complete the work is, so editors and managers always know what is ready to publish and what is missing.
The Challenge
Multilingual content multiplies. Every page, string or article exists once per language, and each version can be in a different state: untranslated, in progress, out of date after the source text changed, or finished. Without a system, teams track this in spreadsheets and chat, and gaps go unnoticed until a visitor lands on a half-translated page. Right-to-left scripts, longer German or Finnish strings and different date formats add further edge cases. The tool also had to suit editors and translators who are not developers.
Who Uses It and How
A content manager opens the overview and sees each supported language with its completion status, then picks the market that launches next week. A translator, often an external freelancer, filters the table to items awaiting their language and works through them. A reviewer approves finished translations. When the source copy changes, the affected translations are flagged so they are not published stale.
Permissions can be limited by language, so a Spanish translator sees only Spanish work.
Our Approach
We started from the status of each language because that is what a manager wants first, and made translation progress a primary concept rather than an afterthought. For daily editing we chose a plain table, familiar to non-technical people, over an editor full of options. We designed for scale from the beginning, so that adding another locale means one more column of work and not a rethink of the screen.
What We Built
The overview shows each supported language and its completion status. From there, editors open a table of content items with the translation state per language shown in the row. Editing a translation is a simple action, and saving updates the status. Locales can be added as the organisation enters new markets, and the panel keeps source content and translations linked so nothing is orphaned. Layout and labels are kept simple to shorten training.
Architecture and Data
The model separates a content item from its per-locale translations, each carrying its own status and a reference to the version of the source it was based on. Comparing that reference with the current source is how the system detects out-of-date translations. The Node.js API stores and serves content per locale, and can offer a fallback to a default language when a translation is missing. Delivery to a website or app is via API, with locale codes following standard tags such as en-GB or ar. PostgreSQL stores text in Unicode, so any script works, and record history can show who changed a phrase.
Security, Privacy and Quality
Unpublished content, such as a product launch, is confidential, so access is authenticated and role-based, with language-level limits for external translators. Translators also enter text that becomes public, so a review step and sanitising of markup guard against accidental or malicious injection. Testing includes right-to-left rendering, long strings that overflow layouts, plural and date rules that differ by language, and stale-flag behaviour when source text changes.
Technology
React suits the interactive tables and inline editing that a localisation workflow depends on. Node.js provides the API that stores and serves content per locale and applies the rules for completeness. PostgreSQL keeps each translation tied to its source item and handles text in any script.
Outcome
LocaleHub gives a team a single place to manage content across languages and to see, without asking anyone, how far each locale has progressed. Editors work in an interface they can pick up quickly, managers gain visibility, and the published product avoids the inconsistency of partially translated content. It is a foundation for growing into new languages in a controlled way.
Frequently asked questions
How much does it cost to build a multilingual CMS?
Cost depends on the number of content types, the languages involved, review and approval workflows, and how content is delivered to sites or apps. Integration with translation agencies or machine translation adds scope.
How do you handle translations that go out of date?
Record which version of the source each translation was based on. When the source changes, flag the translation for review instead of silently publishing an old version.
Can a CMS support right-to-left languages such as Arabic?
Yes, provided the database stores Unicode text and the front end is built and tested for right-to-left layout, mirrored where needed. It should be verified with real content early.
Highlights
- Per-language completion status at a glance
- Built for teams managing many locales
- Simple table interface for non-technical editors
- Out-of-date translations flagged when source text changes
- Unicode storage for right-to-left and non-Latin scripts
- React, Node.js and PostgreSQL