LINE LIFF 多语言翻译指南：语言识别、用户切换与内嵌页面本地化
LINE 内打开的 LIFF 页面怎么做多语言翻译？区分 LINE 应用语言、浏览器语言、SDK 提示与业务文案，介绍 getAppLanguage、语言选择优先级、登录返回、表单状态、分享预览及端到端验收。
用户在 LINE 菜单里选择中文，打开服务页面却看到英文；页面切换成中文后，系统提示仍然是另一种语言；登录返回后，刚才的选择又丢失。这些都是 LINE 内嵌网页多语言项目中容易被忽略的问题。
LIFF 页面翻译需要分别处理环境语言、用户主动选择、业务文案与 SDK 提示，再让登录、跳转和返回流程保持一致。 仅调用一个语言方法，不会自动翻译自己的按钮、表单和服务内容。
本文面向开发者与产品负责人，围绕 LINE Front-end Framework（LIFF）的运行环境设计语言流程，平台资料核对于 2026 年 10 月 23 日。它讨论的是 LINE 内打开的网页应用，聊天图片和通译账号应使用各自的翻译方式。
一、先把 LIFF 的四层语言分开
第一层是环境线索，例如 LINE 应用语言或外部浏览器语言；第二层是用户已经明确选择的界面语言；第三层是你自己的页面文字；第四层是 SDK 提供的提示和界面文字。
这四层可能不同。例如，用户把手机系统设为英文，但希望在一个中文预约页面办理业务；又或者业务文案已加载中文，而某个 SDK 提示回退到英语。产品应理解这些差异，而不是把任何不一致都归因于翻译文件没更新。
LINE 的LIFF 开发指南说明，LIFF 应用基于 HTML 与 JavaScript 构建。因此，自己的标题、表单、帮助文字和页面布局，需要由应用负责维护。
设计开始时就给四层语言安排各自的数据来源。这样当某个提示语言错误时，可以检查对应层，而不必把整个页面重新翻译一遍。
二、语言识别应该使用哪个方法？
当前 LIFF API 参考推荐 liff.getAppLanguage()；liff.getLanguage() 已标为弃用。前者需要 LIFF SDK v2.24.0 及以上；在 LIFF 浏览器中且 LINE 为 v14.11.0 及以上时获取 LINE 应用语言，不满足相应环境条件时按文档回退到运行环境语言。实施时仍应核对所用版本。
因此，不建议把旧教程中的 getLanguage() 直接复制进新项目。对于已有应用，也应先查看实际 SDK 与 LINE 版本，安排兼容验证，而不是只改方法名就认为迁移完成。
环境语言只能作为线索，不等于用户永久偏好。不要因为一次检测返回日语，就覆盖用户此前明确选择的中文。语言检测应服务于首次进入体验，主动选择应有更高权重。
还要区分设备和地理位置。语言标签表示语言设置，不能据此推断国籍、付款货币或服务地区。这些业务字段应在适当位置单独确认。
三、明确语言优先级，避免页面来回跳变
一套可理解的优先级示例是：本次用户主动选择、已保存且允许使用的个人偏好、受信任入口指定的语言、运行环境语言、站点默认语言。实际顺序可以按产品需要调整，但必须保持一致。
受信任入口可以是自有官方账号菜单或内部页面。即使 URL 带有语言参数，也应校验它是否属于支持列表，不能任意加载用户输入对应的文件路径。
首次进入时，尽量在渲染主要文字之前确定语言，减少先英文后中文的闪动。如果需要异步读取偏好，可以显示不依赖具体语言的加载状态，同时保留清楚的超时处理。
一旦用户主动选择，就不要在后续接口返回时突然改回检测语言。异步结果的先后顺序，不应决定用户最终看到哪种语言。
四、语言标签不要只截取前两个字母
把 zh-Hant 和 zh-Hans 都截成 zh，会丢失简繁信息；把区域后缀简单当成无关字符删除，也可能使用户进入不合适的版本。
更合适的方式，是先规范化输入，再映射到产品实际支持的资源。对于未支持的语言，使用明确回退，必要时展示语言选择器。下面是一个应用层映射示例，不包含 LIFF 初始化与完整错误处理：
const supported = new Set(['zh-Hans', 'zh-Hant', 'en', 'ja', 'th']);
function resolveLocale(raw) {
try {
const [tag] = Intl.getCanonicalLocales(raw);
if (supported.has(tag)) return tag;
const locale = new Intl.Locale(tag);
if (locale.language === 'zh') {
const traditional = locale.script === 'Hant' || (!locale.script && ['TW', 'HK', 'MO'].includes(locale.region));
return traditional ? 'zh-Hant' : 'zh-Hans';
}
if (supported.has(locale.language)) return locale.language;
} catch {
// 无效或缺失标签采用应用默认值。
}
return 'en';
}这里把不带脚本信息的中文映射到简体，是示例产品的默认策略，不是对所有用户偏好的判断。实际项目可在这种情况下提示选择，或采用组织已经定义的规则。
发布前至少验证大小写、带地区标签、显式脚本、空值与不支持语言。语言代码不仅影响资源加载，还可能进入链接、缓存与统计，统一规范能减少后续分歧。
五、SDK 语言设置，为什么不会翻译业务页面？
liff.i18n.setLang() 用于指定 LIFF SDK 显示文字的语言，返回 Promise；官方文档说明，指定标签没有对应翻译时会使用英语回退。它不负责把你自己的业务页面自动翻译成该语言。详见LIFF 国际化 API。
因此，应用切换语言时，至少要分别处理业务资源与 SDK 语言，并各自应对失败。自己的中文文案加载成功，并不能证明所有 SDK 提示也会显示中文；SDK 设置成功，也不能证明预约说明已完成翻译。
可以把语言切换设计成一个可观察过程：先解析目标语言，加载业务资源，设置相应环境提示，更新页面语义，再呈现完成状态。必要时对 SDK 可用范围作单独映射，不要假定业务支持列表与 SDK 支持列表完全一致。
切换失败时应保留一个可操作的界面，而不是把整页清空。用户至少需要能重试、返回或选择其他语言，并知道先前表单内容是否仍然保留。
六、内嵌浏览器与外部浏览器，要分别测试
同一个 LIFF 链接可能从 LINE 内打开，也可能在外部浏览器中访问。两种环境的登录状态、语言线索和 API 可用性不能完全等同。官方 API 参考对环境条件作了区分，并注明 LIFF 与 OpenChat 的兼容限制。
实际测试时，应把“LINE 内首次进入”“LINE 内再次进入”“外部浏览器未登录”“外部浏览器已登录”等状态列开。不要只在开发电脑浏览器测试一个网址，就宣布 LINE 内体验已经完成。
如果某个能力在当前环境不可用，页面应提供合适替代，而不是显示一个只有开发者能理解的错误。语言选择器尤其不能依赖一个尚未可用的特定环境功能，否则用户连修正语言的机会都没有。
对 OpenChat 场景，应重新核对官方限制，不能直接把普通聊天中的 LIFF 能力原样套用。社群翻译相关功能可参考OpenChat Bot 指南。
七、登录和返回后，如何保留语言？
语言状态经常在跨页面登录时丢失。应先画出实际路径：入口页面、授权或登录、回调、业务页、完成页和返回入口。每个节点都需要知道语言从哪里来。
不要把密钥或访问令牌当作语言参数放进 URL。公开的语言标签与认证资料有不同用途，不能为了让跳转“省事”而混在一起。认证应遵循平台推荐方式，语言则使用经过校验的单独状态。
用户取消登录、重新打开页面或刷新后，也应有稳定行为。比如保持已选择语言，让用户继续查看公开信息，或清楚说明哪项操作需要登录，而不是无提示地回到默认语种。
若使用本地存储或账户偏好，要明确退出登录与更换用户时如何处理。共用设备不能把上一位用户的私人表单恢复给下一位用户，语言偏好与个人业务数据应分别管理。
八、切换语言时，不要丢掉用户已经填写的内容
语言切换应改变标签和说明，不应默认清空姓名、选择时间或用户自己的备注。可以保存表单状态，再加载相应语言资源，避免用户为修正语言重新填写。
错误提示也要随语言更新。字段标签是中文，校验错误却突然显示另一种语言，会使用户难以判断怎么改。服务器返回的状态应映射到可维护的本地文案，而不是把任意后端字符串直接展示。
对于用户自由填写的正文，不要在界面切换时悄悄翻译并替换原文。若业务确实需要翻译，应作为明确操作，保留原文并让用户知道结果用于什么地方。
确认页尤其重要。提交之前，用户需要用能够理解的语言看到自己正在确认的内容、时间和条件。不能只翻译成功页，却让关键选择过程仍然难以理解。
九、日期、货币和服务地区，不应由语言自动决定
用户选择英文，并不意味着金额应该变成美元；选择中文，也不意味着服务地点变成某个中文地区。语言负责表达，业务数据负责真实条件。
时间应明确所属时区，必要时同时显示用户本地时间与服务所在地时间。切换界面语言可以改变日期的格式，却不能改变同一事件的实际时间。
货币应从订单或服务配置读取，并保留币种。不能只显示一个没有上下文的符号，再期待用户通过页面语言判断。数量、单位和税费条件也需要保持原来的业务含义。
这些字段可以按目标语言进行可读性格式化，但应有独立校验。翻译流程不应该通过改写普通字符串来生成正式金额或预约时间。
十、菜单、页面与分享预览如何保持一致？
如果用户从某种语言的 Rich Menu 进入，页面应尊重已确认的语言上下文。菜单只改变图片、网页又自行检测成另一种语言，会使用户觉得切换没有成功。菜单侧方案见多语言 Rich Menu 指南。
分享预览还涉及页面标题、描述与图片。公开可分享页面应设置清楚、与实际内容对应的信息；私人业务页则不能把姓名、订单或认证资料写进预览元数据。
自动语言检测与搜索引擎可抓取内容也要分开考虑。确实面向公开搜索的多语言内容，宜使用稳定 URL 与真实对应页面；需要登录的个人页面则应按访问控制处理，不能为了 SEO 暴露私人数据。
不要把一个仅客户端切换、没有稳定语言地址的页面，直接等同于完整多语言搜索方案。更系统的规划可阅读多语言 SEO 与 hreflang 指南。
十一、TranslateHub 在 LIFF 翻译项目中放在哪里？
它可以放在业务文本初稿或动态文字翻译的服务端环节。LIFF 前端向自己的后端提交已授权、必要的文本，再由后端按TranslateHub 接口文档调用服务。密钥不应随前端资源一起发布。
固定按钮和重要说明，适合先翻译、审核并形成稳定资源。不要让每次页面打开都重新翻译同一个提交按钮，否则会增加等待时间，也会让同一功能的措辞变化。
动态内容则需要保留原文、语言和处理状态。用户应能区分原始内容与翻译结果；翻译失败时，业务仍应有清楚反馈，而不是表现为一条永远转动的加载提示。
LINE 登录、页面权限、语言偏好、翻译接口与消息分享，应分别设计和验收。任何一个环节成功，都不等于整个用户路径已经可用。
十二、LIFF 多语言端到端验收矩阵
| 场景 | 重点检查 |
|---|---|
| LINE 内首次打开 | 初始语言、加载状态与选择器 |
| 用户主动切换 | 文案、SDK 提示与表单状态 |
| 登录后返回 | 语言保留与业务页面恢复 |
| 外部浏览器访问 | 可用能力、登录与回退说明 |
| 不支持的语言标签 | 明确默认值，不加载任意资源 |
| 简繁中文 | 标签解析、术语与真实排版 |
| 网络较慢或资源失败 | 重试路径、内容保留与可操作状态 |
| 分享公开页面 | 标题、描述、语言与隐私字段 |
每个测试都应该记录实际环境与版本。发现差异时先判断是语言资源、环境能力还是状态恢复问题，不要一律归入“翻译不准”。
十三、LINE LIFF 翻译常见问题
改变 LINE 应用语言，LIFF 页面会自动翻译吗？
不会由此自动生成业务译文。应用需要读取适当线索、加载相应资源，并提供用户选择。
新项目还应该使用 liff.getLanguage() 吗？
当前参考文档将其标为弃用，推荐查看 getAppLanguage()。迁移时仍要核对实际 SDK 和客户端条件。
liff.i18n.setLang() 能翻译整个网页吗？
它负责 SDK 显示的文字。自己的按钮、说明、表单错误和业务内容需要由应用维护。
用户已经选中文，为什么不应该再被自动检测覆盖？
主动选择比环境线索更能表达当前意图。明确优先级可以避免异步加载导致语言反复跳变。
LIFF 页面在外部浏览器里也要测试吗？
需要按实际开放路径测试。环境和 API 条件可能不同，不能只测试 LINE 内或只测试开发浏览器。
切换语言应该清空表单吗？
通常不应因界面语言变化而丢失已填写内容。应把业务状态与显示文案分开管理。
可以根据语言自动切换货币吗？
不应这样推断。货币、服务地区和实际时间来自业务数据，语言只决定如何表达。
最值得优先修复的多语言问题是什么？
登录返回后丢失语言、切换时清空内容、关键条件没有翻译，以及菜单和目标页面不一致。这些都会直接影响用户完成任务。
把环境识别当作起点，把用户选择作为明确状态，再分别维护业务文案和 SDK 提示。经过登录、表单与返回路径的完整验证，LIFF 多语言体验才算真正贯通。
