Translations

Every project has translations. Strings live in bundles, and a project's locale files are composed from three kinds:

An override stays when the bundle moves to a new version. A key the bundle stops shipping is flagged on your override and still composed, so a build never loses a string silently.

In the console

Translations splits into what the project owns and what it shares. New bundle makes a bundle of your own; its keys are edited in place. A shared or package bundle shows its values read only, with a column for your overrides. Attach package adds a package's bundle at a version by hand; a build attaches the packages its lock files hold by itself, at the locked versions.

Pulling the files

The composed file per language is what a build reads. For a Nuxt app, the @syncronet/nuxt-ops module pulls it before every build:

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@syncronet/nuxt-ops'],
  ops: { project: 'rungholt' },
})

The languages pulled are the .json files already in the locale folder. Without a token (OPS_API_TOKEN), or when ops cannot be reached, the build keeps the files it has and says so; a translation pull never fails a build.

From a terminal:

ops tms pull da --project rungholt              # writes locales/da.json
ops tms pull en --project rungholt -o i18n/locales

A Rust service pulls the same file in its build.rs with the ops-sdk i18n feature.

Packages bring their own strings

A package's publish run registers the locale files of each npm package it publishes (i18n/locales/*.json) as a version of the package's bundle. The source language's file must be among them, or the tag is refused before anything publishes.