Lingo.dev MCP server让 AI 编程助手能够直接访问你的本地化引擎配置。本指南将带你从零开始完成本地化引擎设置——从安装，到搭建一个完整配置的引擎，涵盖各语言区域的品牌语调、术语表条目、语言规则和模型路由。
你将配置哪些内容#
| 层级 | 作用 | 示例 |
|---|---|---|
| 品牌语调 | 按 locale 设定语气和正式程度 | 面向德国开发者使用更随意的“du”，面向日语使用礼貌正式语气 |
| 术语表 | 自定义翻译 + 不可翻译项 | “Deploy” 在德语中译为 “Bereitstellen”，而 “OAuth” 在所有语言中都保持不变 |
| 规则 | 特定语言区域的语言规范 | 法语标点前使用不换行空格，日语使用全角字符 |
| 模型路由 | 按 locale 选择模型，并设置回退 | 欧洲语种组合使用 Claude Sonnet，日语回退到 GPT-4o |
前 3 项属于你的组织，而不是某一个引擎：术语表、规则集和品牌语调都是通过挂载到引擎上来生效的，因此第二个引擎可以直接复用同一套配置，无需再复制一份。模型路由则始终属于引擎本身。
最终你会得到一个有状态的翻译 API。你可以通过 localization API 在代码中调用它，通过 CLI 在命令行中调用它，或者通过 CI/CD 在每个拉取请求中自动运行。每一次请求都会自动应用所有层级。
问题是什么#
每个本地化引擎都需要按语言区域配置品牌语调、术语表条目、语言规则和模型路由。如果全都通过仪表板来设置，不仅耗时，而且重复——尤其是第一次上手时，你还得先弄清每一层的作用，以及它们之间如何配合。
Lingo.dev MCP server 可以让 AI 编程助手在一次对话中完成初始设置。你只要把它指向产品内容，它就会创建引擎、撰写品牌语调文本、识别术语表条目、补充特定语言区域的规则，并配置模型路由——一轮全部完成。你再审阅输出结果，并在此基础上继续调整即可。
第 1 步：安装 MCP#
在 Lingo.dev 控制台的 API Keys 页面生成一个 API 密钥，然后把 MCP 服务器添加到你的编码代理配置中。
将其添加到你的 .claude/settings.json 或项目级别的 .mcp.json 中：
{
"lingo": {
"type": "http",
"url": "https://mcp.lingo.dev/account",
"headers": {
"x-api-key": "your_api_key"
}
}
}组织作用域
API 密钥决定了 MCP 服务器管理的是哪个组织。所有操作都会自动在该组织下执行——你的助手无需手动指定组织 ID。
重启你的代理后，让它列出当前已有的本地化引擎，以验证连接是否成功。如果 MCP 已启用，它会返回结果（新组织则可能返回空列表）。
第 2 步：配置引擎#
复制下面的提示词并粘贴到你的 AI 编码助手中。将末尾的 URL 替换为你的产品官网、文档或 README——代理需要有代表性的内容，才能推断你的语调、术语和目标受众。
Create a localization engine called 'My Product' for localizing into
German, French, Japanese, and Spanish. Study the content at the URL
below to understand our tone, terminology, and audience. Then configure
everything in one pass: brand voice texts for each locale (and English),
glossary terms that need consistent translations or should stay
untranslated, and locale-specific linguistic rules.
https://docs.yourproduct.com别忘了替换 URL
这个提示词最后有一个占位 URL。请将它替换为能真实体现产品表达风格的内容链接——比如文档、README、引导流程或营销网站。否则，代理生成的配置会比较通用。
代理会读取你的内容，创建引擎，并一次性完成所有层级的配置。接下来的步骤，就是审核并微调它生成的内容。
第 3 步：微调品牌语调#
查看 agent 创建的 品牌语调。品牌语调会为每个语言区域提供一段文本，用来定义你的产品在该语言中的表达方式——包括语气、正式程度和风格。这些内容会由 agent 根据你的内容推断得出，但其中的文化细节仍值得仔细核查。
重点检查：
| Locale | 常见调整项 |
|---|---|
| 德语 | 使用“du”（非正式）还是 “Sie”（正式）——取决于你的受众 |
| 法语 | 使用“tu”（非正式）还是 “vous”（正式）——取决于面向消费者还是企业客户 |
| 日语 | 礼貌等级——对大多数产品来说，礼貌正式体（です/ます）是更稳妥的选择 |
| 英语 | 源语言文本通常会缺失——补上一条可保持整体一致 |
一段配置得当的德语品牌语调文本大致如下：
Use informal "du" address. Keep a direct, technical tone.
Prefer short sentences. Use active voice. When a German equivalent
exists for a technical term, use it (e.g., "Bereitstellung" for
deployment), but keep widely-adopted English terms as-is
(e.g., API, CLI, Token).如果语体不对，直接告诉你的助手：
The German brand voice is too informal for our enterprise docs.
Switch it to formal "Sie" register.第 4 步：微调术语表#
查看 agent 创建的 术语表条目。术语表能让引擎精确控制特定术语——要么强制采用指定译法，要么完全不翻译。agent 会从你的内容中识别术语，但也可能漏掉产品特有术语，或选错译法。
初次配置后，一个典型的术语表大致如下：
| 源文本 | 目标文本 | 源 locale | 目标 locale | 类型 |
|---|---|---|---|---|
| Deploy | Bereitstellen | en | de | 自定义翻译 |
| workspace | espace de travail | en | fr | 自定义翻译 |
| Lingo.dev | Lingo.dev | * | * | 不可翻译 |
| OAuth | OAuth | * | * | 不可翻译 |
需要检查：
- 遗漏术语——代理没有接触到的产品功能名称或内部术语
- 错误译法——代理可能会选用与你现有用法不一致的同义表达
- 遗漏的不可翻译项——应该保持原样的品牌名、协议名或缩写
术语通过语义相似度进行匹配——例如，“Deploy”这一术语也会匹配“Deploying”“deployment”以及“deploy your application”，无需分别单独建条目。对于适用于所有语言区域的术语，请使用 * 通配符。
Add a glossary term: 'checkout' should stay as 'Checkout' in
German - it's our product feature name, not the shopping action.第 5 步：调整规则#
查看 agent 创建的 规则。规则是面向特定语言区域、可单独测试的明确规范，并会归入引擎使用的规则集中。品牌语调负责设定整体语气，而规则则用来补足通用模型容易忽略的细节——比如标点、缩写、字符宽度和数字格式。
完成初始设置后，一组典型规则通常如下：
| Locale | 名称 | 规则 |
|---|---|---|
| fr | 法语标点空格 | 在 :、;、! 和 ? 前始终使用不换行空格 |
| de | 德语地址缩写 | 将 “Straße” 缩写为 “Str.”，将 “Nummer” 缩写为 “Nr.” |
| ja | 日语字符宽度 | 使用全角括号（）而不是半角 () |
每条规则只针对一个问题，因此都可以单独测试——如果德语缩写出了问题，只需更新那一条规则，不必动其他内容。
需要检查：
- 遗漏规则——目标 locale 中的数字格式、日期格式和货币习惯
- 源语言 —— 英文里关于牛津逗号、标题大小写或数字格式的规则往往容易缺失
In French, there should always be a non-breaking space before
colons and semicolons. Add that as a rule for fr.第 6 步：配置模型路由（可选）#
新引擎会预先配置好默认模型，针对常见语言和低资源语言的翻译质量做了优化。大多数团队都不需要调整。
如果你有特定需求——例如某个模型在你的领域表现更好、预算有限，或有合规要求——也可以覆盖默认设置：
Set Claude Sonnet as the primary model for European language pairs,
with GPT-4o as fallback for Japanese.每个模型配置都支持按优先级排序的回退方案。如果主模型失败（如服务中断、触发速率限制或被弃用），引擎会自动尝试下一个模型。
