后端社交即时通讯【免费下载链接】NodeBBNode.js based forum software built for the modern web项目地址https://gitcode.com/gh_mirrors/no/NodeBB点击查看免费下载NodeBB 的界面文案通过public/language/目录下的 JSON 语言包进行本地化该目录由机器人每日同步、禁止直接人工编辑所有翻译工作统一经由 Transifex 平台完成。本文将基于 public/language/README.md 这一核心文档结合仓库源码梳理 NodeBB 语言包的目录结构、编辑禁令背后的原因、Transifex 提交流程以及翻译在运行时如何被加载、合并与回退帮助你理解并正确参与 NodeBB 的本地化协作。一、核心协作规则为什么public/language/是只读的public/language/README.md开篇便明确了最关键的一条约束该目录下的文件是只读的且每天如有变更都会被机器人 Misty 覆盖重写。这意味着禁止直接提交修改任何指向此目录的 Pull Request 都会被自动关闭同步源是 Transifex官方翻译项目托管在 Transifex 的 NodeBB 项目中翻译内容的唯一正确来源是 Transifex本地文件只是其导出物不要绕过同步链路直接编辑本地 JSON 文件会导致与 Transifex 上的译文脱节out-of-sync这是该禁令存在的主要原因。在仓库中public/language/en-GB/_DO_NOT_EDIT_FILES_HERE.md 进一步用一行标题重申了这一点——The files here are not meant to be edited directly并指向本 README。也就是说每个语言子目录中都放置了同样的警示文件例如zh-CN/、ar/等 80 个语言目录内均含此文件从目录结构层面反复提醒协作开发者。遇到未翻译字符串怎么办README 给出了明确指引如果存在未本地化的字符串且你在 Transifex 中找不到对应条目应当在官方问题追踪器bug tracker上提交新 issue让维护者介入处理——而不是直接编辑本地文件补上翻译。这类字符串通常意味着它在代码中是新引入的、尚未同步到 Transifex需要核心维护者处理。二、语言包的目录结构解剖public/language/下按语言代码组织每个语言一个目录例如en-GB/英式英语也是基准语言、zh-CN/、zh-TW/、ar/等。以 public/language/en-GB/ 为例一个语言目录包含language.json语言元数据声明name、code、dir文字方向ltr或rtl例如 en-GB 的配置为{name: English (United Kingdom/Canada), code: en-GB, dir: ltr}一组命名空间 JSON 文件如global.json、topic.json、category.json、user.json、email.json、error.json、login.json、search.json等每个文件对应界面上的一个功能模块admin/子目录存放管理后台的翻译46 个命名空间文件themes/子目录存放主题相关文案2 个文件_DO_NOT_EDIT_FILES_HERE.md前述只读警示文件。而src/meta/languages.js的getTranslationMetadata()函数见 src/meta/languages.js在构建阶段会递归遍历整个public/language目录把每个.json文件的相对路径拆解为语言代码/命名空间其中_会被替换为-、会被替换为-x-兼容旧式en_GB、zhCN类命名从而生成语言与命名空间的完整清单并写入build/public/language/metadata.json。注意language.json与_DO_NOT_EDIT_FILES_HERE.md因其自身路径拆分后缺少 namespace会被该逻辑跳过不会进入翻译清单。三、完整的本地化工作流3.1 常规流程改文案 → Transifex → 每日同步开发者/翻译者在Transifex 项目中完成各语言条目的翻译与校对机器人Misty每天拉取 Transifex 的最新翻译写入public/language/各语言目录构建过程nodebb build把这些源 JSON 处理、合并后输出到build/public/language/供运行时使用如果你发现有字符串未翻译且 Transifex 上也没有按 README 指引到 bug tracker 提 issue。3.2 那代码里的硬编码文案呢翻译工作流只覆盖已接入本地化体系的字符串。若开发者直接在模板或代码中硬编码了英文文本未经[[namespace:key]]语法包裹这类字符串不会出现在语言包中也不存在于 Transifex——这正是 README 提示找不到对应条目就提 issue的典型场景。因此编写 NodeBB 插件或核心代码时务必使用[[...]]翻译占位符而非硬编码字符串这是本地化协作的前提。四、运行时翻译加载链路从 JSON 到界面文案理解只读禁令后再看翻译在运行时的完整生命周期你会更清楚为什么本地改文件是不被允许的。4.1 服务端读取src/languages.jssrc/languages.js 提供运行时读取语言包的 APILanguages.get(language, namespace)读取build/public/language/语言/命名空间.json并解析为对象随后触发filter:languages.get插件钩子允许插件修改译文数据Languages.listCodes()读取build/public/language/metadata.json中的languages数组返回全部可用语言代码带缓存Languages.list()遍历语言代码读取各语言的language.json元数据过滤掉缺少code/name/dir的非法条目返回供界面下拉框使用的语言列表Languages.userTimeagoCode(userLang)把用户语言映射为 timeago 相对时间插件的 locale 代码避免1 小时前之类的时间文案语言错乱。值得注意的是Languages.get中的路径校验startsWith(languagesPath)防止通过语言/命名空间参数实现目录穿越。4.2 构建与合并src/meta/languages.jsbuildLanguages()src/meta/languages.js是构建期的核心流程清空build/public/language重新生成metadata.json对每个语言 × 命名空间组合执行buildNamespaceLanguage()回退机制先加载en-GB的命名空间文件作为基底再叠加目标语言的翻译覆盖缺失/未翻译键——这保证了任何语言缺词时界面仍显示英文不会出现空白空值过滤assignFileToTranslations()会过滤掉值为的条目src/meta/languages.js#L133-L144注释明确指出这是 Transifex exports untranslated strings as\\即 Transifex 导出的未翻译条目是空字符串绝不能覆盖已有回退翻译——这从源码层面印证了以 Transifex 为准的设计插件语言合并addPlugin()会为每个插件按其languages字段指定的路径按正确语言代码 → 旧式代码 → 插件默认语言的优先级顺序回退合并最终为每种语言产出full.json服务端全量、full.min.js、client.json/client.min.js浏览器端window._i18n。4.3 渲染时替换src/translator.jssrc/translator.js 通过translator.common模块把模板中的[[namespace:key]]占位符替换为实际译文其翻译数据源正是languages.get(lang, namespace)——也就是上面提到的src/languages.js。lang由当前用户偏好或站点默认语言决定。4.4 语言设置的写入校验用户可在账户设置中切换界面语言管理员也可在 管理后台设置页 的defaultLang下拉框中选择站点默认语言。相应地src/user/settings.js 在保存userLang/acpLang时会调用languages.listCodes()校验该语言确实存在否则抛出[[error:invalid-language]]——从写入端保证了语言代码与语言包清单一致。五、给插件与主题作者的本地化建议虽然本 README 面向核心仓库的语言文件但同样的协作规则可推广到插件生态插件的语言文件放在插件自己的languages/目录由插件plugin.json中的languages字段声明构建时经addPlugin()合并进对应语言包无需也不应改动核心public/language/插件同样支持多语言与 en-GB 回退但插件翻译不一定经过 Transifex 同步需自行维护多语言文件始终用[[namespace:key]]占位符并在plugin.json中正确声明languages路径否则构建时插件译文无法被纳入。六、常见问题速查问题正确做法发现某语言缺少某条翻译到 Transifex 补充翻译等待每日同步本地语言文件与 Transifex 不同步以 Transifex 为准机器人会覆盖本地文件不要手工修复界面出现[[xxx:yyy]]原文占位符说明该语言缺这条翻译且 en-GB 也缺检查代码是否硬编码/拼错 key想新增一种语言在 Transifex 上创建新语言并完成翻译无需改动仓库目录字符串在 Transifex 中找不到按 README 指引到 bug tracker 提交 issue七、小结NodeBB 的本地化体系是一套Transifex 为源、机器人同步、构建合并、运行时回退的完整流水线public/language/README.md锁定了协作方式只读 平台翻译 issue 上报src/meta/languages.js 与 src/languages.js 定义了构建期合并与运行期加载的实现细节src/translator.js 则负责把语言包变成用户看到的界面文案。对普通翻译者而言记住一句话即可所有翻译都去 Transifex 做不要动仓库里的语言文件对开发者而言还需要理解空值过滤、en-GB 回退与插件语言合并机制才能写出真正国际化的插件与主题。赞分享后端社交即时通讯【免费下载链接】NodeBBNode.js based forum software built for the modern web项目地址https://gitcode.com/gh_mirrors/no/NodeBB点击查看免费下载相关推荐Joplin 本地化Localisation指南应用翻译与文档翻译的完整工作流Joplin 本地化Localisation指南应用翻译与文档翻译的完整工作流 本篇指南以 Joplin 仓库中的 readme/dev/localisa知识管理跨平台插件系统Sudachi Qt 前端多语言翻译工作流Transifex 协作与 TS 文件构建指南Sudachi Qt 前端多语言翻译工作流Transifex 协作与 TS 文件构建指南 Sudachi 的桌面版 Qt 前端支持多语言界面其翻译补丁统一存桌面应用移动开发虚拟化searx 翻译协作指南基于 Transifex 与 Babel 的 i18n 工作流searx 翻译协作指南基于 Transifex 与 Babel 的 i18n 工作流 导读 searx 是一款注重隐私的元搜索引擎其界面文案支持数十种语言后端搜索引擎上一篇IOPaint AI 图片修复入门指南3 步去除照片水印与路人下一篇三步做出会动的幻灯片Slidev 开发者演示工具完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考