Simplified localization for SaaS

The rename that touches every locale

You're the product engineer who manages user interface terminology. On a Monday you begin preparing for a rename: "Teams" becomes "Workspaces." By Friday, that rename is being pushed out to five locales including Spanish, German, Japanese, French, and Portuguese. That rename also needs to be reflected in billing emails and in the help center for a consistent user experience.

Unfortunately, instead of a smooth transition, you're cross-referencing a spreadsheet someone updated last quarter, a directory of ad hoc scripts, and whatever the last person pasted into a browser tab. The billing email still says "Teams plan" and the help center references the old terms.

Where the manual loop breaks

When product terminology lives in a spreadsheet, three things drift:

• Feature names get translated loosely, so "Workspaces" reads as three different words across locales.
• Lifecycle strings, release notes, and help content keep separate copies, and nobody reconciles them.
• Every release turns into a round of search-and-replace instead of a review.

These are not quality problems in isolation. Each string translates acceptably on its own. The problem is that the strings disagree, because every content type was translated against a different idea of what the product terms mean.

What Lexel Translate covers

• Glossaries can be used for consistent terminology control. A quick fix can be rolled out to relevant teams in seconds using per-team scoping or rolled out in sync across the entire organization using a pinned version identifier glossary_version_id. See the glossary docs.
• The playground offers a simple user interface for translation requests, allowing anyone on the team to verify an update without touching code.
• Use synchronous translation to rapidly iterate on content changes. The batch route supports up to 16 items per request with per-item languages, glossaries, and do_not_translate values.
• Use asynchronous translation for larger background refreshes. POST /api/v1/translate/async queues work for background processing, and completion can be delivered by callback. See the async docs.

The stored glossary is what keeps feature names stable across translation requests. Update a term once and every subsequent request uses it, because user interface strings, transactional emails, and help content all translate against the same stored terms. Jobs pin the glossary version at creation time, so a release batch translates against the same terms even if the glossary changes while the job runs.

These four paths cover the release workflow without a separate tool per content type.

A setup that holds up at volume

1. Keep product terminology in a stored glossary, organized into groups for feature names, plan names, and other user interface language (see the glossary docs).
2. Use synchronous translation for smaller changes on the critical path. Use do_not_translate for brand and feature names, and preserve_placeholders for tokens like {name} and [Order #482913] (see the translate docs).
3. Use asynchronous jobs for larger release batches so the big refreshes run in the background, and fetch results or cancel queued work from the job endpoints (see the async docs).
4. Review output in staging before publishing, and fix terminology drift in the glossary rather than in individual translations.

The staging review is where drift gets caught. Fix a term in the glossary once, and the fix applies to every locale on the next run.

The result

A rename ships across the user interface, the billing emails, and the help center in one release, because all of them translate against the same stored glossary terms. Product, growth, and support stay aligned on the same terminology and the same release cadence. Terminology errors surface in staging, before the release is live.