企业官网建设流程全解析

如何为 GitHub MCP Server 配置多语言：国际化（i18n）完整指南

【免费下载链接】github-mcp-serverGitHub's official MCP Server项目地址: https://gitcode.com/GitHub_Trending/gi/github-mcp-server

把你的 AI 助手接入 GitHub MCP Server 之后，工具列表里清一色的英文描述会让非英文用户很头疼：get_commit的描述写着 "Get details for a commit from a GitHub repository"，而你可能更希望助手用中文来解释它要执行什么。github-mcp-server（GitHub 官方 MCP Server）的国际化机制就是干这个的——它把每个工具的文案抽成"翻译键"，再允许你用环境变量或一个 JSON 配置文件覆盖默认英文。整个机制的核心逻辑就在 pkg/translations/translations.go 里，不到 100 行，读一遍就能全懂。

🔑 翻译键：每段工具文案的"门牌号"

先说人话：项目里没有硬编码的"语言包"，而是给每段文案分配一个统一的键名，配置时你只需要按键名填上想要的文本。

键名遵循一个固定套路：TOOL_+ 功能名 +_DESCRIPTION（或_USER_TITLE）。比如get_commit工具的描述对应TOOL_GET_COMMITS_DESCRIPTION，界面标题对应TOOL_GET_COMMITS_USER_TITLE。_DESCRIPTION是喂给 AI 助手看的工具说明，_USER_TITLE是给用户界面展示的短标题，两者可以翻译成不同粒度的中文——前者详细些，后者短一点。

工作原理：一次查找，三级取值

简单说就是：同一个键，服务端启动时按"环境变量 → 配置文件 → 代码默认值"的顺序取第一个命中的值，环境变量优先级最高，意味着你随时可以用一条export命令临时改某个工具的文案，不用动任何配置文件。

对应的最小代码长这样，每个工具在注册时都会带上一个翻译函数t：

type TranslationHelperFunc func(key string, defaultValue string) string // 工具注册处的一次典型调用 mcp.NewTool("get_commit", mcp.WithDescription(t("TOOL_GET_COMMITS_DESCRIPTION", "Get details for a commit from a GitHub repository")), mcp.WithToolAnnotation(mcp.ToolAnnotation{ Title: t("TOOL_GET_COMMITS_USER_TITLE", "Get commit details"), }))

t的查找过程是：先把键统一转成大写（所以大小写不用太纠结），然后依次查环境变量GITHUB_MCP_前缀 + 键名、github-mcp-server-config.json配置文件、最后才落到第二个参数的默认值。还有个值得注意的细节：第一次查到的结果会缓存进内存 map，之后同一键直接命中缓存。这一方面让查找飞快，另一方面也埋了个坑——进程启动后改环境，是感知不到的，后文排查时会再提到。

⚙️ 动手配置：先改一个，再批量铺开

改一个工具：给键名加上GITHUB_MCP_前缀，导出为环境变量即可，例如：

export GITHUB_MCP_TOOL_GET_COMMITS_DESCRIPTION="获取 GitHub 仓库中某个提交的详细信息"

批量翻译：在服务运行目录放一个配置文件，文件名必须精确是github-mcp-server-config.json，内容就是"键 → 文本"的映射：

{ "TOOL_GET_COMMITS_DESCRIPTION": "获取 GitHub 仓库中某个提交的详细信息", "TOOL_GET_COMMITS_USER_TITLE": "查看提交详情", "TOOL_ADD_ISSUE_COMMENT_DESCRIPTION": "在 Issue 下添加一条评论", "TOOL_CREATE_BRANCH_DESCRIPTION": "在 GitHub 仓库中创建新分支" }

拿到全量键清单：与其满仓库 grep 翻译键，不如直接用自带的导出命令./github-mcp-server --export-translations。它会生成（或更新）一份github-mcp-server-config.json，保留你已经写好的覆盖值，同时把二进制里新增的翻译键也补进来——以后升级版本，新工具的文案键会自动出现在你的清单里，这是最省心的翻译维护方式。

实际部署里怎么切换语言

这里有个坑：项目没有运行时语言切换开关，语言是在进程启动那一刻定下来的（启动时读一次配置并缓存）。所以"切换语言"本质上是"换一套环境再启动"：

• 单实例中文部署：容器启动时注入一组GITHUB_MCP_*环境变量（docker run -e），适合临时、个别的文案覆盖。
• 多语言文件部署：为每种语言准备一份github-mcp-server-config.json，用-v挂载到容器内，要切语言就换文件重启，适合团队共享一套固定文案。
• 混合用法：配置文件当"语言基线"，环境变量当"临时补丁"。因为环境变量优先级更高，它永远能盖过文件里的值——这也正是排查"为什么我改了文件没用"时首先要怀疑的方向。

顺带一提，同一套机制还能覆盖SERVER_NAME/SERVER_TITLE这两个键，比如把标题改成 "GHES MCP Server"，让 AI 助手在同时连着 github.com 和自建 Enterprise 实例时能分清是哪个。

❓ 翻译没生效？按顺序查这四个方向

验证是否生效也很直接：启动服务后在 MCP 客户端里列出工具，看目标工具的 description 是不是已经变成你的文案；对不上号，就按下面的顺序排查。

最后这个方向最隐蔽：官方 README 里举例的键是TOOL_ADD_ISSUE_COMMENT_DESCRIPTION，但键名并不总等于"工具名 + 后缀"的直觉拼法，以导出的清单为准就不会错。

写在最后

一句话收束：GitHub MCP Server 的国际化不是语言包，而是"翻译键 + 三级取值（环境变量 > 配置文件 > 默认值）+ 启动时缓存"这一套极简组合，灵活但需要你理解"启动即定型"这个前提。给你一个小建议：第一次上手，先跑--export-translations把键清单导出来，只挑 AI 助手高频调用的那几个工具翻译成中文，剩下的以后按需补——翻译键是按次查、按次缓存的，不存在"必须全量翻译"的负担。

【免费下载链接】github-mcp-serverGitHub's official MCP Server项目地址: https://gitcode.com/GitHub_Trending/gi/github-mcp-server