开发工具前端【免费下载链接】js-lingui A readable, automated, and optimized (2 kb) internationalization for JavaScript项目地址https://gitcode.com/gh_mirrors/js/js-lingui点击查看免费下载Lingui 官方提供了eslint-plugin-lingui帮助开发者在代码提交之前发现并阻止常见的 Lingui 国际化i18n用法错误例如在模块顶层误用t宏、把完整句子拆成碎片、使用无意义的数字占位符等。本文基于当前仓库的 ESLint Plugin 参考文档完整介绍该插件的安装方式、Flat Config 与 Legacy Config 两种配置方案、Oxlint 兼容性并结合仓库内的指南与宏参考逐个解析各条规则的实际用途与落地场景。读完本文你可以在任意 Lingui 项目中用一条extends或一组rules快速启用质量门禁。为什么需要 Lingui ESLint 插件Lingui 的宏macro体系虽然让编写可翻译消息变得简单但也容易在不知不觉中埋下国际化隐患。比较典型的几类问题包括在模块顶层调用t宏——返回的字符串一旦赋值就不会随语言切换而更新翻译永远是“一次性”的把一句完整的话拆成多个Trans或模板片段导致翻译人员无法调整语序和语法消息里出现{0}这类数字占位符、0这类数字标签让译者完全无法判断插槽里到底放的是什么消息缺少给翻译人员看的注释comment或上下文context。这些错误靠 code review 很难做到全覆盖。Lingui ESLint 插件的定位正是把这些“最佳实践”固化成机器可执行的规则。在仓库的 Translator-friendly Messages 指南 中作者明确写道“用 ESLint 插件强制执行让质量不再依赖代码评审”。也就是说插件与 Lingui 的 宏参考、配置参考 形成互补宏负责“写出正确的消息”插件负责“拦住错误的写法”。安装先安装 ESLintnpm install --save-dev eslint再安装eslint-plugin-linguinpm install --save-dev eslint-plugin-lingui:::info 全局安装注意事项 如果你是用-g参数全局安装的 ESLint那么eslint-plugin-lingui也必须全局安装否则 ESLint 找不到该插件。 :::用法一Flat Configeslint.config.jsESLint 8 引入了名为 Flat Config 的新配置格式。与旧的.eslintrc不同Flat Config 直接把插件和解析器表示为 JavaScript 对象配置文件本身就是一个 JS/TS 模块。推荐配置Recommended只需一条配置即可启用插件的全部推荐规则import pluginLingui from eslint-plugin-lingui; export default [ pluginLingui.configs[flat/recommended], // Any other config... ];自定义配置如果你只想按需启用某几条规则可以加载插件并手工指定import pluginLingui from eslint-plugin-lingui; export default [ { plugins: { lingui: pluginLingui, }, rules: { lingui/t-call-in-function: error, }, }, // Any other config... ];当前仓库根目录的 eslint.config.js 和 website/eslint.config.mjs 本身就是 Flat Config 的真实范例前者用defineConfig组合eslint/js、typescript-eslint与eslint-plugin-import后者则采用数组形式显式声明plugins与languageOptions可以作为你书写 Lingui 规则时的参照结构。用法二Legacy Config.eslintrcLegacy 配置格式虽已被 ESLint 标记为弃用但目前仍然受支持。推荐配置Recommended把plugin:lingui/recommended加进extends即可{ extends: [plugin:lingui/recommended] }自定义配置把lingui加入plugins段。注意可以省略eslint-plugin-前缀{ plugins: [lingui] }然后在rules段按需开启规则。参考文档给出的完整示例{ rules: { lingui/no-unlocalized-strings: 2, lingui/t-call-in-function: 2, lingui/no-single-variables-to-translate: 2, lingui/no-expression-in-message: 2, lingui/no-single-tag-to-translate: 2, lingui/no-trans-inside-trans: 2, lingui/no-unnamed-tag-placeholders: 2 } }这里的2等价于error1为warn0为关闭。三种数值写法在 ESLint 中语义完全一致可按团队习惯选择。用法三在 Oxlint 中直接复用插件可以不加任何修改地作为 Oxlint 的 JS 插件使用。在.oxlintrc.json的jsPlugins中声明并显式开启所需规则{ jsPlugins: [eslint-plugin-lingui], rules: { lingui/t-call-in-function: error, lingui/no-single-tag-to-translate: warn, lingui/no-single-variables-to-translate: warn, lingui/no-trans-inside-trans: warn, lingui/no-expression-in-message: warn } }有两个要点值得注意Oxlint 不读取插件的configs所以“推荐规则”必须在这里逐条显式列出不能依赖flat/recommended或plugin:lingui/recommended兼容性有 CI 背书文档明确说明插件的 Oxlint 兼容性在每一次变更时都会经过 CI 验证。目前已知的唯一限制是no-unlocalized-strings规则的useTsTypes选项——它需要typescript-eslint/parser提供的类型信息而 Oxlint 无法提供因此在 Oxlint 下不要开启该选项。规则速查每条规则在拦截什么插件规则的作用场景散布在仓库的多份文档中。下表把参考文档中出现的规则与仓库内对应的场景说明汇总到一起方便速查规则拦截的问题是否属于 recommended仓库内佐证文档no-unlocalized-strings未经过翻译宏处理的裸字符串最全面的扫描型规则见插件仓库规则文档本文档提及useTsTypes选项依赖类型信息t-call-in-function在模块顶层使用t宏导致字符串无法响应语言切换—宏参考no-single-variables-to-translatet${value}与Trans{value}/Trans这种只翻译一个变量的写法✅Translator-friendly Messagesno-single-tag-to-translateTransb{value}/b/Trans整条消息只有一个标签包裹的变量✅同上no-trans-inside-trans一句话被拆成嵌套的多个Trans✅同上no-expression-in-message消息中的成员表达式与函数调用会产生{0}占位符✅Translator-friendly Messages、React 教程no-unnamed-tag-placeholdersTrans内部会被提取成数字标签0的元素❌需自行启用Translator-friendly Messagesrequire-comment消息缺少翻译注释也接受lingui-set comment...指令严格规则建议新代码启用宏参考require-directive-resetlingui-set未用lingui-reset关闭作用域泄漏到后续消息严格规则宏参考注表格中“是否属于 recommended”一列以仓库现有文档明确写出的结论为准未标注的规则建议结合插件自身的规则文档按需启用。表格里引用的规则详细文档维护在插件独立仓库中本文不再外链你可以在 Lingui 宏参考 与 Translator-friendly Messages 指南 中找到对应的使用场景。重点规则解析t-call-in-function拦住模块顶层的t宏这是最容易踩的坑。宏参考 中专门有一段示例说明t宏返回的是字符串一旦在模块顶层赋值它就不会再响应 locale 变化// ❌ Bad! 模块顶层使用 t 宏字符串不会随语言切换更新 const colors [tRed, tOrange, tYellow, tGreen]; // ✅ Good! 每次函数执行都会重新执行宏返回正确的翻译 function getColors() { return [tRed, tOrange, tYellow, tGreen]; }t-call-in-function就是用来检查这种误用的专用规则配套的更优方案是 Lazy Translations 模式。no-expression-in-message消灭{0}占位符React 教程 与 Solid 教程 都提醒过消息中复杂的表达式在提取阶段会被替换成{0}这种位置占位符译者完全看不出里面是什么。正确做法是用ph宏命名import { t, ph } from lingui/core/macro; tHello ${ph({ name: user.name })}; // 提取为 Hello {name}该规则允许纯标识符、ph()以及嵌套的plural、select、selectOrdinal调用其余成员表达式和函数调用都会被报告。no-unnamed-tag-placeholders强制Trans内使用命名标签Trans内部的行内元素默认按索引编号0、1译者无法判断哪个是链接、哪个是强调而且代码中调整元素顺序会悄悄改变消息。该规则会报告任何最终仍会被提取为数字标签的元素。它不在推荐配置中需要在项目完成命名配置之后再启用在 lingui.config 中通过macro.jsxPlaceholderAttribute默认属性名如_t和macro.jsxPlaceholderDefaults如把a映射为link、strong映射为bold配置语义化标签名在 TypeScript 项目中声明该属性以通过类型检查示例见 Translator-friendly Messages 指南。require-comment与require-directive-reset把“面向译者的信息”变成规则comment和context是给翻译人员的两条关键信息。仓库 宏参考 引入了lingui-set/lingui-reset注释指令让同文件内的后续宏统一携带context、comment甚至idPrefix。与之配套require-comment要求每条消息都带注释——直接写在宏上或来自lingui-set comment...指令这是tSave这类标签模板唯一能带注释的方式require-directive-reset要求每个lingui-set必须用lingui-reset关闭防止上下文泄漏到之后新增的消息。这两条规则都偏严格适合新代码或配合白名单例外使用。在项目中落地的推荐路径结合参考文档与仓库内指南推荐按以下顺序接入插件避免一次性开启所有严格规则造成告警刷屏先启用 recommended通过pluginLingui.configs[flat/recommended]Flat Config或plugin:lingui/recommendedLegacy拿到no-single-variables-to-translate、no-single-tag-to-translate、no-trans-inside-trans、no-expression-in-message等核心规则优先解决“拆句子、数字占位符”这两类影响翻译质量最大的问题再启用no-unnamed-tag-placeholders前提是先按 配置参考 配置好macro.jsxPlaceholderAttribute与macro.jsxPlaceholderDefaults否则Trans内的标签会大量报错新代码启用require-comment/require-directive-reset配合lingui-set/lingui-reset指令统一维护文件的context与commentOxlint 场景在.oxlintrc.json的jsPlugins中声明插件并逐条列出规则且不要使用no-unlocalized-strings的useTsTypes选项。Translator-friendly Messages 指南 末尾给出的自检清单本质上就是上述规则的“理想状态”一句话一条消息、命名占位符、命名标签、短消息必带注释、相同文本用 context 区分、指令成对闭合、目录保留来源引用origins选项默认开启。小结eslint-plugin-lingui把 Lingui 多年来沉淀的 i18n 最佳实践变成了一组可配置、可扩展、可复用的 lint 规则同时支持 Flat Config、Legacy Config 与 Oxlint 三种运行环境。对于团队项目把它接入 CI 是保障翻译质量最低成本的投入之一对于个人项目至少启用推荐配置就能在写代码的当下拦住{0}占位符、嵌套Trans和顶层t宏这些高频问题。更深入的使用场景可以继续阅读仓库内的 宏参考、Translator-friendly Messages 指南 与 配置参考。赞分享开发工具前端【免费下载链接】js-lingui A readable, automated, and optimized (2 kb) internationalization for JavaScript项目地址https://gitcode.com/gh_mirrors/js/js-lingui点击查看免费下载相关推荐nodebestpractices 安全实践用 ESLint/TSLint 安全规则在编码阶段拦截 Node.js 漏洞nodebestpractices 安全实践用 ESLint/TSLint 安全规则在编码阶段拦截 Node.js 漏洞 导读 本篇指南基于开源仓库 node文档教程后端ComfyUI API 接入你的服务从生图自动化到自定义节点的完整路径ComfyUI API 接入你的服务从生图自动化到自定义节点的完整路径 你想把一套在 ComfyUI 界面里手工拖出来的工作流搬进自己的后端服务让订单进来、人工智能大模型媒体生成本地部署Node.js 安全实践用 Linter 安全规则在编码阶段拦截漏洞Node.js 安全实践用 Linter 安全规则在编码阶段拦截漏洞 导读 本文基于 nodebestpractices 仓库“安全最佳实践”章节第 6.1文档教程后端上一篇chromium-web-store完全指南在ungoogled-chromium上安装Chrome扩展的终极解决方案下一篇Vue3DraggableResizable事件全解析从activated到resize-end的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考