Use case
On a website, the wording is the product
Application strings can be merely correct. A landing page has to be persuasive in the target language, which is a different job — and the one place where a literal machine translation costs you the most.
The formats you will be pulling
.jsonNext.js, Astro, Nuxt
.yamlJekyll, Hugo
.poWordPress, Drupal
.csvHandover to an agency
How the week goes
- 1Fix the vocabulary firstPut your product names, the words you never translate and the words you always translate the same way into the glossary. Everything after this inherits it.
- 2Draft, then rewriteTreat the AI pass as a first draft for a human who knows the market. For marketing copy that is the honest expectation to set.
- 3Vary by market, not by forkA market that needs different claims gets a variant that overrides those strings and inherits the rest.
- 4Publish from the buildThe same pull step as an app. Nothing is edited live and everything is revertible.
What to watch for
The glossary is the whole game
One term translated two ways across a site reads as carelessness. Fixing it centrally costs an afternoon once.
Review is not optional here
Application copy survives a mediocre translation. A homepage does not.
Keep the source in the repo
The English lives with the site. locoloop holds the translations, not the authority over your copy.
Set it up before the next release
Import the English file, enable a language, paste the CI job.