colonist.io游戏国际化架构实现方案技术咨询

我们正在开发一款网页端游戏，计划对产品进行国际化，此前调研了i18next框架，但测试后发现难以适配需求。

技术栈与代码结构 #

• 全栈使用TypeScript
• 服务端：基于Node.js的Express框架，处理API并渲染EJS模板
• 客户端：原生TypeScript，搭配SASS做样式、PIXI.js做游戏渲染，Webpack打包
• 代码分为server、client、shared三个目录

当前文本分布 #

• 存储在shared目录下的文本文件，服务端与客户端均可访问
• 直接嵌入EJS模板内
• 直接写入服务端与客户端的TS代码中

理想国际化系统需求 #

服务端需求 #

• 可轻松将区域设置（locale）与HTTP请求/API请求/Socket连接绑定（语言变更时断开Socket连接可接受）
• 可在EJS模板中便捷使用本地化文本
• 必要时可本地化渲染SASS（如适配LTR与RTL等特殊样式规则）

客户端需求 #

• 仅加载所选区域设置所需资源（如英文用户无需下载西班牙语文本）
• 优先通过Webpack打包处理，避免显式异步请求资源
• 支持缓存

通用需求 #

• 共享区域设置文件，无需为服务端与客户端分别创建
• 易于添加新翻译条目，多数文本将通过GitHub Copilot/Google Translate自动生成
• 各语言/区域设置相互独立，不集中在单个文件中
• 可自动检测需翻译的字符串并发出提示

问题解答 #

1. 是否可通过现有插件直接实现上述全部需求？ #

不能直接通过现有插件实现所有需求，尤其是SASS本地化渲染、自动检测未翻译字符串并提示这两项，现有插件很难完全匹配；另外客户端要求的「Webpack打包时仅包含所选locale资源」也需要结合定制化配置，无法单纯靠插件开箱即用。

2. 若无法全部实现，哪些需求可通过插件满足，哪些不能？ #

可通过插件满足的需求

• 服务端：locale与请求/Socket绑定（i18next的i18next-express-middleware可绑定HTTP请求，Socket部分可结合中间件逻辑实现）；EJS模板中使用本地化文本（i18next有EJS适配插件或可自定义模板函数）
• 客户端：资源缓存（i18next的缓存插件或浏览器自身缓存机制配合）；共享locale文件（i18next支持从shared目录加载资源）；语言文件独立存储（i18next默认支持按语言拆分文件）；添加翻译条目便捷性（配合i18next的编辑器插件或CLI工具，可快速导入自动翻译内容）
• 复数、格式化等常见国际化场景（i18next原生支持，搭配i18next-intl-fallback等插件增强）

无法通过插件直接满足的需求

• 服务端：SASS本地化渲染（如LTR/RTL适配）
• 客户端：Webpack打包时仅加载所选locale资源（需定制Webpack配置，而非单纯插件）
• 通用：自动检测未翻译字符串并发出提示（现有工具多为半自动化，需结合定制化脚本或ESLint规则）

3. 针对无法开箱即用的需求，自行实现难度如何？是否易出错或崩溃？是否需要持续更新？ #

SASS本地化渲染

• 难度低：可通过在Webpack中根据locale注入全局SASS变量（如$direction: ltr/rtl），或拆分不同locale的样式文件，配合路由/请求参数动态加载。实现逻辑简单，不易出错，后续仅需在新增RTL语言时补充样式规则，无需频繁更新。

Webpack按需打包locale资源

• 难度中等：可通过webpack-context-replacement-plugin或动态导入+环境变量实现，比如构建时指定locale，仅打包对应语言文件；或客户端根据用户选择预加载对应语言包（避免显式异步请求的话，建议构建多语言独立包）。配置过程需要熟悉Webpack机制，调试时可能遇到路径问题，但稳定后无需频繁更新，仅需在新增语言时调整配置。

自动检测未翻译字符串

• 难度中等：可通过编写ESLint规则扫描TS/EJS文件中的硬编码字符串，或使用i18next的i18next-scanner工具生成待翻译条目清单。需要适配项目的代码结构，可能会误报非业务文本，需维护规则的白名单/黑名单，后续代码规范变更时需同步更新规则。

整体来看，这些自定义实现的风险较低，测试充分后不会导致系统崩溃，维护成本可控。

4. 是否存在其他可实现上述需求且支持复数、格式化等常见国际化场景的框架？ #

有以下几种可选框架：

• Format.js：原生支持复数、格式化，服务端可结合Express使用，客户端适配Webpack，支持按需加载语言包。但自动检测未翻译字符串的能力需要配合额外工具，SASS本地化仍需自行实现。
• LinguiJS：轻量且TypeScript友好，支持Webpack按需打包，有CLI工具提取待翻译字符串，服务端可适配Express/EJS。同样需要自行处理SASS本地化逻辑。
• Polyglot.js：Airbnb出品，支持复数、插值，体积小，适合原生TS客户端，但服务端集成需要自定义中间件，自动检测功能需额外开发。

这些框架都能覆盖大部分需求，剩余的SASS本地化、自动检测等需求仍需自行实现，整体适配成本和i18next相近。

内容的提问来源于stack exchange，提问作者Esqarrouth