LINE 官方账号多语言菜单怎么做？Rich Menu 翻译、切换与验收指南

LINE 官方账号的用户可能先看到菜单图片，再点击预约、商品、位置或客服入口。如果只翻译聊天回复，没有翻译菜单、按钮动作和目标页面，用户仍然可能在第一步就迷失。

LINE 多语言 Rich Menu 应同时管理四件事：菜单图上的文案、按钮实际点击区域、用户明确选择的语言，以及点击后页面的语言。 把一张中文菜单复制成英文图片，只完成了其中一部分。

本文面向需要规划多语言 LINE Official Account 的运营与开发团队，介绍可复核的设计和发布方法。平台资料核对日期为 2026 年 10 月 23 日。文中的数据结构与流程示例是方案说明，不是可直接提交到 LINE 的完整请求。

一、Rich Menu 翻译与普通文字翻译，差在哪里？

Rich Menu 是官方账号聊天底部的菜单区域，可以连接网站、预约页面或其他服务。LINE 的Rich Menu 概览说明了这一用途，并指出 Windows 与 Mac 电脑版不显示 Rich Menu。

它的特殊之处在于，用户看到的是设计好的图片，系统响应的却是配置好的点击区域与动作。文字看起来正确，不代表点到的功能正确；目标功能正确，也不代表用户看得懂入口。

因此，菜单本地化需要同时验收视觉与行为。设计师检查每种语言的排版，运营确认措辞，开发核对热区和动作，测试人员从真实用户路径验证目标页面。只把图片交给翻译人员，无法完成整个任务。

对电脑用户还需要准备其他入口，例如清楚的文字链接或可用的替代操作。不能把所有服务能力都藏在仅手机显示的菜单中，再期待所有设备都具有相同体验。

二、先做菜单内容盘点，不要立即开始翻译

先列出每一个入口的真实用途：展示商品、创建预约、查询地点、联系人员，还是打开说明。不同用途需要不同动词，不能为了排版整齐而统一写成模糊的“更多”。

盘点表应包含功能标识、中文文案、目标地址、是否需要登录、是否存在多语言页面，以及维护负责人。缺少目标页面的语言时，先决定如何处理，而不是让翻译掩盖缺失。

这张表中的标识属于自己的业务设计，不应随着菜单翻译而改变。文字可以从“预约”变成其他语言，业务动作仍应是同一个经过确认的流程。

三、菜单文案要翻译用户动作，而不是逐字对照

短按钮最容易出现“字少但意思不完整”的问题。例如“预约”可能指查看可选时间，也可能指提交预约申请。若按钮点击后只是提交待确认申请，文案就不能让用户以为已经成功预约。

翻译前给每个短词补充一句用途说明，例如“打开页面选择时间，提交后由人员确认”。翻译人员据此选择目标语言表达，再由业务负责人核对真实行为。

同样，“客服”应与实际支持范围一致。若只能通过表单留言，就不要使用会让人期待即时人工聊天的表达。翻译不应为尚未提供的服务制造承诺。

长度受限时，优先使用简洁、明确的常用动作词。不要仅用缩小字号来容纳长译文，也不要擅自删掉改变行为含义的词。确实无法放下时，先重新设计入口层级。

四、菜单图片的语言版本，怎样保持可维护？

保留可编辑设计源文件，把每种语言的文案放进独立文本层。尽量避免只保存最终位图，否则下次一个词调整，就可能需要重新绘制整张图。

每种语言使用相同的功能结构和图标语义，方便用户切换后继续识别。布局可以根据语言长度调整，但调整后必须重新核对点击区域，不能只更换图片文件。

不要把所有语言挤在一张菜单图里。多语并排可能适合极少量入口，但随着语言增加，会降低字号和可读性。更清楚的方案通常是让用户选择语言，再显示对应版本。

还应检查浅色背景、深色显示环境中的边界与文字对比度。图片中的细小字无法像普通网页文本一样自由调整，因此重要入口应使用清楚字号，并在其他位置提供文字说明。

五、为什么用户语言最好允许主动选择？

设备语言、个人习惯和当前业务需要并不总是一致。一个使用中文系统的用户可能希望查看英文商品名称，另一个用户可能只想临时切换菜单。自动判断可以作为初始提示，但应保留清楚的人工选择入口。

语言名称尽量使用该语言自己的写法，例如“简体中文”“繁體中文”“English”。不要仅靠旗帜表示语言，因为同一种语言可能跨多个地区，一个地区也可能使用多种语言。

用户选择后，应让他能确认结果，并知道如何再次切换。不能把语言选择藏到只有当前语言熟练者才能找到的深层菜单中。

同时明确语言影响的范围。如果只改变菜单图，并不会改变历史消息或所有外部页面，就在设计中保持一致预期。最好逐步让当前菜单、后续回复模板和目标网页采用同一个已确认偏好。

六、默认菜单与个人菜单，怎样避免优先级混乱？

LINE 的按用户设置 Rich Menu 文档说明，可通过 Messaging API 为不同用户关联不同菜单；个人菜单的显示优先级高于默认菜单。这个机制可以用于多语言菜单方案，但语言识别与业务选择仍需自己的系统负责。

因此，更新默认菜单后，不能只用一个已经绑定个人菜单的测试账号检查。它可能仍然显示个人版本，让测试人员误以为默认更新没有生效。

建议分别测试新用户、已选择语言的用户、切换语言的用户，以及撤销个人关联后的用户。每种状态都要记录预期菜单，不要只测试“我自己的账号现在看到了正确图片”。

如果用户偏好记录存在，但对应菜单资源暂时不可用，应给出可用的回退入口，并保留用户选择。不要因为一次配置失败就永久把他改回其他语言。

七、显示文案与机器动作，应该分开存储

按钮显示的自然语言可能调整，后端动作标识应保持稳定。LINE 的动作说明区分了 Postback、消息、URI 和菜单切换等动作。选择哪一种，需要结合实际控件和当前平台支持范围。

下面是自定义配置的概念示例，不是 LINE 请求体：

{
  "actionId": "reservation",
  "locale": "zh-Hant",
  "label": "預約諮詢",
  "destinationKey": "reservation_page",
  "copyVersion": "2026-10-23"
}

系统根据稳定的 actionId 处理业务，根据 locale 选择语言，根据 destinationKey 找到经过审核的目标地址。不要把翻译后的按钮文本当成唯一业务判断条件，否则改一个词就可能破坏路由。

如果使用 Postback，将收到的数据按自己的允许范围校验，不要把任意语言字符串直接当成可执行指令。若使用 URI，语言参数与目标路径也应有明确映射，不能让翻译过程随意生成地址。

八、图片换了，点击热区为什么也必须重测？

热区是几何区域，文案是视觉内容。把“联系客服”从左下移到右下，却继续沿用旧区域配置，会出现用户点客服却打开商品页的错误。

因此，语言版本应记录图片尺寸、区域布局和动作配置的对应版本。设计图发生位移、边距调整或按钮重排时，都需要重新核对热区。

测试时不要只点每块中央。还要点击接近边界的位置，确认相邻按钮不会混淆；在不同屏幕尺寸上观察图像缩放后，文字与可点击区域的关系是否仍然清楚。

菜单中不建议放看起来像按钮却没有动作的装饰块。若某个区域只是说明，应通过视觉方式与真正入口区分，以免用户以为功能坏了。

九、点击后还是另一种语言，问题出在哪里？

多语言菜单常见失败，是入口已经翻译，目标页仍然回到默认语言。排查时应检查完整路径：菜单动作、URL、页面语言解析、登录跳转，以及完成操作后的返回页。

对于支持语言参数的页面，应在跳转过程中保留已确认的选择。不要只在第一跳添加语言，后面的身份验证或表单提交又丢失它。

如果目标服务暂时只有一种语言，提前说明比让用户点进去后才发现更好。可以提供简短的目标语言说明和其他支持方式，但不要伪装成完整多语言体验。

使用内嵌网页时，还需要单独处理网页应用语言。参见LINE LIFF 多语言翻译指南，将菜单语言与页面文案连接起来。

十、翻译流程怎么接入团队发布？

推荐先确定功能和源文案，再翻译目标语言，然后完成设计排版与真实路径验收。不要在图片已经定稿、热区已经配置后，才让翻译人员第一次看到用途。

可以让每次发布包含一份资源清单：源文案版本、各语言图片、动作配置、目标页面与审核结果。这样回滚时可以恢复一组相互匹配的内容，避免新图片配旧动作。

如果使用 TranslateHub 生成文字初稿，可从文本 API 文档规划服务端翻译环节。图片制作、Rich Menu 创建与关联、Webhook 处理和发布仍是自己的系统工作，不能由文本翻译能力直接推断出来。

对短按钮和业务状态，人工审核尤其重要。自动翻译可以提高初稿效率，但不能替业务负责人确认“申请”“确认”“完成”之间的实际差别。

十一、发布前的多语言菜单验收表

验收结果应记录实际观察，不要把“接口返回成功”当成视觉与行为全部通过。资源创建成功，只说明请求被接受；用户是否真正看到正确版本，还需要从客户端核对。

十二、上线后，观察哪些问题更有价值？

除了点击量，还应关注语言切换是否成功、用户是否频繁返回上一步、某个入口是否带来大量“看不懂页面”的支持请求。这些信号更能反映语言链路是否完整。

分析时不要收集不必要的聊天正文。记录语言版本、动作标识、目标页面和结果状态，通常就能定位许多问题。需要研究具体表达时，再按明确范围取得适当样本。

如果某种语言点击少，先确认该语言的真实用户量和入口可见性，不要立即判定译文质量差。内容、展示位置与用户需求都会影响数据，不能只靠一个数字归因。

十三、LINE 多语言 Rich Menu 常见问题

菜单图片会自动翻译吗？

不能把它当成默认行为。应制作并维护需要的语言图片，核对文案与动作，不依赖用户自行理解图片文字。

只更新默认菜单，所有用户都会看到新版吗？

需要考虑个人菜单优先级。测试时分别检查默认状态与已绑定个人菜单的用户。

可以按用户显示不同语言吗？

平台提供按用户关联 Rich Menu 的能力。语言选择、偏好保存和版本映射需要自己的业务设计。

可以用翻译后的按钮文字判断后端动作吗？

不建议。使用稳定动作标识，把显示文字与机器处理的数据分开，避免翻译修改破坏业务路由。

英文太长，直接缩小字号可以吗？

应先优化表达与布局，再检查可读性。过小字号会使菜单难以使用，必要时重新组织入口。

Windows 和 Mac 看不到菜单怎么办？

官方概览说明电脑版不显示 Rich Menu。应提供文字链接或其他适当入口，并单独验收这些路径。

菜单和 LIFF 页面语言要分开维护吗？

资源形态不同，需要各自维护，但应使用一致的语言选择与术语，避免用户进入页面后突然切换语言。

上线前最容易漏掉哪项检查？

按钮边缘热区、已绑定用户的优先级，以及登录后的目标页面语言。它们都无法仅通过查看设计图确认。

从功能清单开始，把菜单图、点击动作、用户语言和目标页面组成一个完整版本，再通过真实路径验收。这样做出的 LINE 多语言菜单，才真正帮助用户完成任务。