W39 – Infrastructure, where you configure localization engines
Infrastructure is where you configure how localization works.
A localization engine is a translation API with your rules, models, terminology, and pipelines built in. You configure it once, then use it from the CLI, API, integrations, GitHub app, or playground.
Here's what you can configure in Infrastructure:
Localization engines. A localization engine brings together everything that affects how your content is translated. You'll usually have more than one: the setup for your product UI is different from the setup for your help center or legal content. Each one can have its own configuration.
Models. You can choose a model for each language pair and set a fallback. If the primary model is unavailable or rate-limited, Lingo.dev automatically moves to the next one instead of failing the request. New localization engines come with default model settings you can update and adjust to fit your needs.
Glossaries, rulesets, and brand voices live under Context. They belong to your organization, so the same glossary, rules, or brand voice can be used across multiple localization engines.
Glossaries handle terminology based on meaning, not just exact spelling, so a term for “Deploy” also covers “deploying”. Rulesets are for specific conventions, like abbreviating “Straße” to “Str.” in addresses. Brand voices define how the text should sound in each language.
These settings are ranked, so there's a clear order when they overlap: glossary terms take priority, then rules, then brand voice.
The localization pipeline. Translation is only one part of the process. From the Pipeline tab, you can add other stages depending on what the content needs: clean up typos and grammar in the source, send it for human review, reconcile edits with your glossary and rules, rephrase the translation, or translate it back to check the meaning.
Different content can use different localization pipelines. Legal content may skip rephrasing and stay close to the source. Marketing copy may benefit from it. Regulated content may require human review before it goes anywhere.
Pipeline stages can also degrade gracefully: if a non-critical stage fails, the job continues with a warning instead of failing completely.
Playground. Compare a localization engine with a bare model on the same text and see what your configuration changes. You can also run two localization engines side by side when you're comparing different setups.
Logs. Each localization engine now has its own Logs tab, so you can see what it served without filtering through an organization-wide log. The Model column shows which model handled each request, including when requests fall back to another model.
Open Infrastructure and give each kind of content its own localization engine.