# General Translation Knowledge Base: 如何为软件字符串的 AI 翻译提供足够的上下文？ URL: https://generaltranslation.com/zh/kb/ai-translation-context.mdx Docs index: https://generaltranslation.com/llms.txt Description: 翻译完整的消息，并附上含义说明、占位符的作用、长度限制和统一术语。General Translation 的 CLI 会将标记的 JSX 提取为结构化的 block，并将上下文备注带入生成过程。对于已有的 JSON 和 YAML 目录，键级元数据可为每个字符串提供单独的指令。上下文组会将你的词汇表和自定义提示词应用到所有已分配的项目，审校人员则可在仪表板中修正输出结果。 Category: 翻译 Last updated: 2026-11-13 Authors: Jackie Chen Published: 2026-11-13 一个简短的界面字符串可能有多种正确译法。以“Free”为例：在价格徽章上，它表示“免费” (德语 *kostenlos*) ；在座位图上，它表示“空闲” (德语 *frei*) 。仅凭这个词本身，无法判断你想表达的是哪种含义。因此，请提供人工译者会询问的信息：这段文本描述的是什么，以及用户接下来可以执行什么操作。 ## 翻译模型需要哪些上下文？ | 上下文 | 向模型传达的信息 | 示例 | 提供方式 | | ----------- | ---------------------- | ------------------------------- | ------------------- | | 所在的句子或 UI 块 | 词语之间如何衔接，包括链接和格式 | 将“继续之前，请阅读我们的**条款**”作为一个完整的句子翻译 | 翻译完整的块，而不是零散片段 | | 含义备注 | 有歧义的词具体取哪种含义 | “Free”表示“空闲可用” | 描述、注释或 `context` 备注 | | UI 角色和长度限制 | 它是按钮、标题还是提示框，以及可用的显示空间 | 不得超过 12 个字符的标签页标签 | 角色备注和最大长度 | | 变量和占位符 | 某个值代表什么内容，并且该值无需翻译 | `{name}` 表示一个人的名字 | 占位符语法和备注 | | 术语 | 只有唯一认可译法的产品名称和术语 | “Workspace”绝不能译为“办公室” | 词汇表 | | 语气和正式程度 | 产品的表达口吻 | 德语中使用敬称 *Sie* | 风格规则 | | 出现位置 | 字符串所在界面的样子 | 结账页面的截图 | 在 TMS 中附加截图 | 术语和风格规则适用于所有字符串，因此只需设置一次。[词汇表指南](/kb/ai-translation-glossary)介绍了如何保持术语一致。其余上下文则需针对每个字符串单独提供，这也是不同工作流之间差异最大的地方。 ## 基于目录的工作流如何提供上下文？ 当字符串存放在键值对形式的目录中时，上下文通过每个键旁边的字段传递： * **消息描述。** [react-intl 消息描述符](https://formatjs.github.io/docs/react-intl/api#message-descriptor)接受一个 `description` 字段，提取时可以将其保留。gettext PO 文件提供面向译者的提取注释 (`#.`) ，并通过 [`msgctxt`](https://www.gnu.org/software/gettext/manual/html_node/Contexts.html) 区分文本相同但含义不同的字符串。 * **平台注释。** Android XML 和 Apple `.strings` 文件支持注释；Apple String Catalogs 和 .NET `.resx` 条目都带有注释字段。你的导出流程和翻译集成必须完整传递这些备注。 * **键名。** 像 `pricing.badge.free` 这样的键能暗示含义，但模型不能完全依赖它。[键命名指南](/kb/i18n-key-naming)介绍了如何按含义为键命名。 * **TMS 字段。** 翻译管理系统会为每个键添加描述、截图和字符数限制。例如，[SimpleLocalize](/kb/general-translation-vs-simplelocalize) 会为每个键保存一份由开发者编写的代码描述和一份面向译者的描述。[SimpleLocalize AI](https://simplelocalize.io/docs/general/auto-translation/#simplelocalize-ai) 在翻译时会参考这些描述、截图和评论。 请让每个句子保持完整，包括其中的占位符和标记。目录可以将整句放在同一个键下；若拆成多个分别翻译的片段，就难以调整语序。接着，确认这些备注确实传递到了翻译环节。编辑器或源文件中的描述，只有在集成将其传递下去时才能发挥作用。 ## General Translation 如何从代码中发送上下文？ General Translation 以组件为起点。[``](/docs/react/reference/components/t) 用于标记一段 JSX，CLI 会从中提取文本、元素结构、变量占位符和备注，并发送给翻译服务。随后，SDK 会结合你的运行时值渲染翻译结果： ```tsx title="src/SeatStatus.tsx" import { T, Var } from 'gt-react'; export function SeatStatus({ seat }: { seat: string }) { return (

Seat {seat} is free. Book it now

); } ``` * **block 是基本单位。** 句子、座位占位符和链接文本会一起发送，因此服务可以在保留元素的同时翻译并调整它们的顺序。座位的运行时值则保留在应用中。[条件 JSX 指南](/kb/translate-conditional-jsx)介绍了这一机制如何处理包含分支的句子。 * **备注和限制紧挨着文案。** `context` 属性用于消除歧义，`maxChars` 属性则请求 best-effort 的长度限制，例如在标签页标签上使用 ``。JSX 之外的字符串也可以在 [`gt()`](/docs/react/reference/hooks/use-gt) 中通过 `$context` 和 `$maxChars` 使用相同的选项。 * **将源代码作为上下文。** 在 `gt.config.json` 的 `files.gt.parsingFlags` 下，将 `includeSourceCodeContext` 设置为 `true`，即可将周围的源代码行作为额外上下文发送。此功能需主动启用，作为对提取出的 block 的补充。 (参见[内联内容解析](/docs/cli/reference/formats/gt-jsx-files#parsing)。) * **无需翻译的值。** 用 [``](/docs/react/reference/components/var) 包裹姓名、邮箱等动态值；其内容不会发送去翻译，译文会将占位符保留在原位。 * **为现有消息目录提供上下文。** 对于 JSON 和 YAML 文件，可通过配套的[键级元数据](/docs/cli/reference/keyed-metadata)文件为每个键添加 `context` 备注和 `maxChars` 限制。[Android `strings.xml`](/docs/cli/reference/formats/android-strings-files)、[Apple `.strings`](/docs/cli/reference/formats/dot-strings-files) 和 [`.resx`](/docs/cli/reference/formats/resx-files) 文件中的注释会作为上下文一并提交翻译。 * **共享术语和语气。** [上下文组](/docs/platform/dashboard/guides/defining-context-for-translations)包含词汇表和自定义提示词，并会应用到你分配的每个项目。在项目中通过 **Autogenerate from project files** 创建上下文组，即可根据现有文案自动起草术语和提示词；编程智能体也可以通过 General Translation 的 [MCP 服务器](/docs/overview/for-coding-agents#mcp)更新它们。 对于基于键的消息目录，同样的座位图说明应放在源文件旁边。借助以下两个文件，你可以继续沿用现有的键和库： ```json title="locales/en.json" { "seatStatus": "Free" } ``` ```json title="locales/en.metadata.json" { "seatStatus": { "context": "Seat map. Free means the seat is available, not that it costs nothing.", "maxChars": 12 } } ``` ## 如何判断上下文是否足够？ 收集只有一个词的按钮、一词多义的词语、包含变量的句子以及复数形式。将它们翻译成首发时要支持的语言，并请熟悉各语言的人在[仪表板](/kb/review-translations)中检查。先在仪表板中修正当前措辞，再把缺失的信息补充到合适的位置：为该字符串添加 `context` 备注；如果同类问题会反复出现，则添加词汇表术语或自定义提示词。更新后的指令会作用于后续生成，但不会自动改写已保存的译文。如需开展更全面的评估，请参阅 [AI 翻译准确性指南](/kb/is-ai-translation-accurate)。 ## 要点总结 * 无论是在 JSX 中编写消息，还是将其放在目录键下，都应让消息与其占位符放在一起。 * General Translation 会将已标记的结构和明确的备注纳入生成过程；主动启用的源代码行和共享的上下文组则可补充消息本身之外的含义。 * 既要修正现有输出，也要改进后续翻译所用的指令。含义和布局应分开检查。 ## Related questions - [如何在 AI 翻译中保持术语一致？](https://generaltranslation.com/zh/kb/ai-translation-glossary.mdx): 维护一份统一的词汇表来收录已批准的术语（包括无需翻译的名称），在每次翻译请求中都应用它，避免变量和代码被翻译，并对结果进行审校。General Translation 通过上下文组实现这一点：上下文组中的词汇表和自定义提示词会应用于其分配到的每个项目；对于始终不翻译的值，则可使用 Var 组件。 - [AI 翻译的准确度足以用于生产环境应用吗？](https://generaltranslation.com/zh/kb/is-ai-translation-accurate.mdx): 对于使用广泛的语言，通常可以，但前提是它要先通过针对你自己的语言、UI 字符串和高风险内容的评估。在 WMT25 中，Gemini 2.5 Pro 在 16 个语言对中有 10 个达到或超过了人工参考译文的水平，但文档级基准测试无法说明简短的界面字符串是否已经可以上线。 - [如何翻译 JSX 中的条件文本？](https://generaltranslation.com/zh/kb/translate-conditional-jsx.mdx): 保持句子完整，并翻译它的每个版本。三元表达式会把句子拆成碎片，使其失去含义，也无法适应各语言的语序。General Translation 通过在 `` 中使用 `` 解决这一问题，将整个句子作为一个整体进行翻译。 - [没有译者或本地化团队，也能实现软件本地化吗？](https://generaltranslation.com/zh/kb/localize-without-translators.mdx): 可以，没有专门的翻译团队也能完成本地化。General Translation 会在构建过程中结合代码上下文和共享术语，为新增和变更的文案生成译文；Locadex 则可以为新的 React 和 Next.js 文本添加标记。双语同事或自由审校人员可以直接在仪表板中修改措辞，无需支付席位费用。您可以根据语言和出错代价来设定审校要求。 - [应该如何命名 i18n 翻译键？](https://generaltranslation.com/zh/kb/i18n-key-naming.mdx): 应按文本出现的位置及其含义来命名键，例如 checkout.summary.title，而不是照搬英文措辞。即使英文相同，不同用途也应各用一个键：德语会把按钮上的 Open 译为 Öffnen，而把状态 Open 译为 Offen。 ## Previous and next questions - Previous question: [General Translation 与 SimpleLocalize 对比：该选哪一个？](https://generaltranslation.com/zh/kb/general-translation-vs-simplelocalize.mdx) - Next question: [没有译者或本地化团队，也能实现软件本地化吗？](https://generaltranslation.com/zh/kb/localize-without-translators.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.