White-label
localization

White-label localization (also called client-specific localization or per-tenant translation management) is the process of managing translations for a product that is resold or rebranded by multiple clients. Each client (or tenant) needs the ability to customize text, labels, and messages to match their brand, industry, or audience, without affecting the base product or other tenants.

In practice, this means maintaining a single set of translation keys with optional per-tenant overrides. A booking engine might use “Book Now” as the default, while tenant A overrides it to “Reserve Your Stay” and tenant B uses “Book Today.” SimpleLocalize is the only localization platform that supports this natively through customer contexts, a dedicated layer for translation overrides that sits on top of your base translations. Read the full guide on customer-specific translations to learn more.

SimpleLocalize introduces the concept of customer contexts. A customer context is a named scope (e.g., hotel_chain_a) that holds translation overrides for a specific tenant. When you fetch translations for that tenant, SimpleLocalize merges the base translations with the overrides. The override wins where it exists, and the base is used everywhere else.

This approach eliminates the need to duplicate projects, fork translation files, or maintain separate export pipelines per client. You manage everything in one project, and the platform handles the layering. Customer contexts work across all delivery methods: Translation Hosting CDN, REST API, and CLI exports. There is no limit on the number of contexts you can create: one per client, one per reseller, or any grouping that makes sense.

The most common workaround in other TMS platforms is to create a separate project for each customer. This leads to duplicated keys, inconsistent base translations, and exponential maintenance overhead as the number of tenants grows. Updating a shared string means propagating the change across every project manually.

With SimpleLocalize's customer contexts, you maintain one project with one set of keys. Tenants only override what differs. Base translation updates propagate automatically to every tenant that hasn't overridden that key. This is the difference between a workaround and native multi-tenant localization support, and it scales from 2 tenants to 2,000 without changing your workflow.

Invite clients directly to your SimpleLocalize project and scope their access to a specific customer context. You control what each tenant can do: view, edit, or suggest translations. Tenants never see other customers' overrides or your internal project structure, ensuring full data isolation between clients.

For broader collaboration, enable public suggestions to let tenant end-users propose translation changes through a shared link. This is useful for community-driven localization or when tenants want their own users to contribute translations without requiring a project account.

SimpleLocalize provides three ways to deliver per-tenant translations. The Translation Hosting CDN publishes each customer context as a separate resource. Your app fetches translations by language key and customer ID (e.g., en_hotel_chain_a). The CLI supports a --customerId flag for downloading tenant-specific files in your CI/CD pipeline. And the REST API provides full programmatic access to query and export overrides per customer context.

All three methods return merged translations (base plus overrides), so your application logic stays simple. If a key has no override for the given tenant, the default translation is returned automatically. Your frontend or backend just fetches one URL and gets the right content for the right tenant.

White-label and multi-tenant localization applies to a wide range of products. White-label SaaS platforms where resellers rebrand UI text to match their own identity. Multi-tenant applications where each client has industry-specific terminology. A logistics platform might say “Shipment” for one client and “Delivery” for another. Booking engines, CRMs, and ERPs that serve hotels, clinics, or retailers, each with different expectations for button labels, notifications, and emails.

Enterprise software with department-level customization also benefits: HR, finance, and engineering teams within the same company may need different wording for shared features. And marketplace platforms often need entirely different text for seller-facing vs buyer-facing interfaces, which customer contexts handle cleanly.

The core benefit is operational efficiency: one project, one set of keys, with overrides only where needed. This eliminates the duplication and drift that come from maintaining separate projects per customer. Base translations update once and propagate to every tenant automatically.

For your clients, it means a personalized experience. The product speaks their language, literally and figuratively. Onboarding new tenants is fast because you only customize what differs. Support overhead drops because clients can manage their own translations. And your continuous localization workflow stays simple regardless of how many tenants you serve.

Yes. You can invite tenants to your SimpleLocalize project and restrict their access to their own customer context. They can view, edit, or suggest translations depending on the permissions you set, without seeing other tenants' data.

You can fetch tenant-specific translations via the Translation Hosting CDN by appending the customer ID to the language key (e.g., en_hotel_chain_a). Alternatively, use the CLI with --customerId or the REST API with the customer context parameter. See the documentation for full details.