n8n 中文支持的真实情况：官方语言包里只有英文

搜「n8n 中文」和「n8n 汉化」的人不少，说明这是个真实痛点。先把现状说清楚。

现状：官方语言包里只有英文

我们去官方仓库确认过：n8n 前端的语言包目录里，目前只有英文一个语言文件。

但有一点值得注意：i18n 机制本身是存在的。也就是说，界面文案是被抽出来做成语言包的，架构上支持多语言，只是官方没有提供中文版本。

这个区别决定了汉化的可行性——不是「代码里写死了英文所以改不动」，而是「有位置放中文，只是没人放」。

开源项目的目录结构和文件会随版本变化，上面这个结论基于我们查看官方仓库时的状态。你要用之前，建议自己去仓库对应位置确认一眼当前情况。

三种汉化路径，代价差很多

路径一：浏览器翻译插件

最省事的办法：用浏览器自带的网页翻译，或者装个翻译插件。

优点：零成本，不动任何代码，升级 n8n 也不受影响。

缺点：机器翻译对技术术语的处理经常离谱，有时候比英文原文还难懂。而且翻译会作用于整个页面，包括你自己填的变量名、JSON 内容——这个副作用挺烦人。

适合：偶尔用一下，或者只是想快速看懂界面在说什么。

路径二：社区的中文语言包

有社区在做中文语言包。这条路的效果比机器翻译好，因为是人工翻译的术语。

要注意的三件事：

一是版本对应。 语言包是跟着某个版本的文案做的。n8n 版本更新后新增的文案，旧语言包里没有，会出现中英混杂。

二是维护状态。 社区项目的更新未必跟得上上游。用之前先看看最近一次更新是什么时候。

三是来源可信度。 这一条最重要——语言包是要放进你的运行环境的。装来路不明的文件，风险不只是翻译质量问题。从有明确维护者、有公开仓库的地方拿，别随便找个网盘链接就下。

路径三：自己维护一份

如果你的团队要长期用，而且有人能读英文，其实可以自己维护一份只翻译常用部分的语言包。

优点：术语按你们团队的习惯定，只翻你们真正用到的部分，工作量比全量翻译小得多。

缺点：升级时要跟着维护。

适合：把 n8n 作为长期基础设施、且有非英语用户要上手的团队。

但比界面语言更值得关注的是这三件事

说实话，界面英文只是上手期的门槛，用两周就习惯了。中文场景下真正会持续咬人的是下面三个。

一、中文资料稀缺，排查问题成本高

这是比界面语言严重得多的问题。

遇到报错、遇到某个节点行为不符合预期，搜中文基本搜不到答案，得去啃英文文档和社区讨论。对不擅长英文的团队，这个成本要提前算进去。

反过来看，Dify 和 FastGPT 都有国内团队在维护，中文文档和社区讨论多得多。如果团队的英文能力是硬约束，这一条在选型时的权重应该往上调。

二、中文内容处理的坑

如果你用 n8n 跑的是中文内容处理流程，有几个具体的坑：

字数统计。 中文按字节算会虚高好几倍——一个汉字在 UTF-8 里通常占三个字节。如果你在流程里做「字数不够就重试」这类判断，用错了统计方式会让判断完全失效。要按字符数（码点）算。

截断处理。 按字节截断中文字符串，可能会把一个汉字从中间切开，产生乱码。

编码。 数据在不同节点、不同外部系统之间流转时，编码不一致会产生乱码。这个问题在纯英文流程里很少遇到，中文场景要多留意。

三、许可限制跟语言无关，但更要紧

顺带提醒一句，这条比汉化重要得多：

n8n 用的是 Sustainable Use License，不是 OSI 意义上的开源。 核心限制是只允许用于你自己的内部业务目的或非商业用途，分发给别人必须免费且非商业。

自己团队内部搭流程用，完全没问题。但如果你打算把 n8n 部署给客户再收费，这件事很可能超出许可允许的范围——不管界面是中文还是英文。

详细的对比见开源 Agent 平台的许可证差别。

上手期真正卡人的其实是这些概念

界面语言只是表层。我们观察到，中文用户在 n8n 上卡住的地方，多数不是看不懂单词，而是不熟悉这几个概念——知道它们的中文名也一样卡。

节点之间传的是「一批数据」，不是「一条」。 这是最反直觉的一点。上游节点输出多条记录时，下游节点会对每一条各执行一次。很多人按「一条数据流过管道」去理解，结果发现执行次数对不上、或者只处理了第一条。

表达式引用的是上一步的输出结构。 要在后面的节点里用前面的数据，得知道前面那步实际输出了什么结构。这件事光看图看不出来，得看实际的执行结果——执行一次、看清楚数据长什么样，再写引用，比对着文档猜快得多。

测试执行和正式执行不是一回事。 手动点执行和被定时器、Webhook 触发，环境和数据来源可能不同。手动跑通了不等于自动跑得通，这个坑很多人踩过。

凭据和节点是分开的。 凭据独立存储、被节点引用。理解了这一点，才知道为什么改一个凭据会影响多个流程。

如果你要带团队上手 n8n，讲清楚这四件事，比给他们一份汉化包有用得多。

实际建议

内部自用：装个浏览器翻译先跑起来，用熟了自然就不需要了。把精力花在理解节点的行为上，比花在汉化上值。

团队推广：如果要让不懂英文的同事也能维护流程，考虑社区语言包或自己维护一份常用部分。但同时要评估——如果团队整体英文能力不足，长期看选一个国内团队维护的平台可能更省事，界面和文档都是现成的中文。

给客户交付：先看许可，再看语言。许可这一条不通过，汉化做得再好也没用。

关于什么时候平台已经不够用、该转向定制开发，判断标准见低代码 Agent 平台的能力边界。选型拿不准也可以找我们聊聊。