如何为 GitHub MCP Server 配置多语言:国际化(i18n)完整指南 如何为 GitHub MCP Server 配置多语言国际化i18n完整指南【免费下载链接】github-mcp-serverGitHubs 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-serverGitHub 官方 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命令临时改某个工具的文案不用动任何配置文件。对应的最小代码长这样每个工具在注册时都会带上一个翻译函数ttype 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 是不是已经变成你的文案对不上号就按下面的顺序排查。排查顺序症状检查点1环境变量没盖过配置文件前缀是GITHUB_MCP_且键名全大写再确认它本来就该赢——优先级最高2配置文件完全没被读到文件名必须精确为github-mcp-server-config.json且放在进程的工作目录下README 的说法是与二进制同目录Docker 场景要挂载到容器内进程实际的工作目录3改完不生效、重启才好启动时缓存 一次性取值机制改完环境或文件必须重启进程4个别键没翻译过来键名可能拼错了。跑一次--export-translations拿全量键清单diff 一下你写错的键最后这个方向最隐蔽官方 README 里举例的键是TOOL_ADD_ISSUE_COMMENT_DESCRIPTION但键名并不总等于工具名 后缀的直觉拼法以导出的清单为准就不会错。写在最后一句话收束GitHub MCP Server 的国际化不是语言包而是翻译键 三级取值环境变量 配置文件 默认值 启动时缓存这一套极简组合灵活但需要你理解启动即定型这个前提。给你一个小建议第一次上手先跑--export-translations把键清单导出来只挑 AI 助手高频调用的那几个工具翻译成中文剩下的以后按需补——翻译键是按次查、按次缓存的不存在必须全量翻译的负担。【免费下载链接】github-mcp-serverGitHubs official MCP Server项目地址: https://gitcode.com/GitHub_Trending/gi/github-mcp-server创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考