企业官网建设流程全解析

• 前端
• 开发者工具
• 插件系统

ScriptCat（脚本猫）是一个可执行用户脚本的浏览器扩展。为了让en-US（美式英语）界面与文档在产品概念、UI 动作和状态表述上保持一致，并防止后续翻译复制来源中的含糊措辞，仓库在 docs/references/terminology-en-US.md 中建立了一份术语与界面文案规范（Terminology and UI Copy Guidelines）。本文以该规范为主体，结合 src/locales 下的真实 JSON 字符串与 i18n 实现，系统讲解 ScriptCat 的英文文案治理原则、五类术语分类表、推荐词汇与审查清单。读完本文，你将掌握一套可直接套用的英文 UI 文案评审方法论，并能在修改任意 locale 的翻译时定位到对应的术语依据。

一、术语规范在 ScriptCat i18n 体系中的位置

1.1 为什么需要一份英文术语规范

ScriptCat 的国际化使用 i18next 实现（而非chrome.i18n，原因是后者不支持动态切换语言），语言文件位于src/locales/<locale>/目录下，按页面命名空间拆分为多个*.json文件，最终由 src/locales/locales.ts 合并导出。关键机制如下：

• en-US是运行时的回退语言（fallbackLng: "en-US"），也是新翻译的模板语言；
• 顶层NS数组（common、popup、script、editor、settings、install、agent、logs、guide、tools、permission、external_access）必须与en-US/下的命名空间文件集合完全一致；
• 为满足部分扩展市场要求，chrome.i18n语言文件另行维护在src/assets/_locales目录。

既然en-US同时承担"模板"与"回退"双重角色，其措辞就必须被刻意校准——含糊或不地道的英文一旦写入en-US，就会被复制到其他 locale。这份术语规范正是为了在文案源头把关而存在。

1.2 规范的适用边界

规范明确说明其使用来源为src/locales/en-US/*.json、README.md与docs/architecture.md，并给出 7 条原则。这些原则界定了"术语修正"的边界：

1. 使用简洁的美式英语 UI 文案，直接陈述动作或状态；
2. 保持User Script、Page Script、Background Script、Scheduled Script四种脚本类型的产品区分，不可互相替换；
3. 禁止仅凭拼写做全局替换——必须确认功能、UI 位置、周边文案，以及该字符串是标签还是句子；
4. 面向开发者的术语必须保持技术精确，包括regular expression、cron expression、watch、storage和元数据标识符；
5. 不得改动占位符、HTML/React 标签、i18next 插值、URL 或@match、@exclude、@grant、@connect等标识符；
6. en-US是回退语言与翻译模板，含糊或不地道的英文应被刻意修正，而不是传播到其他 locale；
7. 下表列出的 key 记录的是当前实际用法或已知审查目标，同一含义的未来字符串同样适用。

从源码结构看，这些原则与 docs/translation.md 中"不要把某个界面文案的修正扩大成该词在所有上下文中的禁用规则"的要求是相互呼应的——术语规范只约束明确的场景，语境敏感项必须逐个核对。

二、A 类：产品与功能术语

A 类术语解决"ScriptCat 的能力和脚本类型该叫什么"的问题。规范要求保留ScriptCat的产品大小写（ScriptCat而非Scriptcat），并严格区分四种脚本类型：

在源码中可以找到这些规则的直接证据。例如 src/locales/en-US/script.json 中create_user_script为Create User Script、create_scheduled_script为Create Scheduled Script，且normal_script同时以User Script（第 44 行）与Normal Script（第 53 行）两种形式出现——这正是规范中"类别标签待统一"的真实写照；src/locales/en-US/install.json 中的scheduled_script_description_title明确定义了定时脚本的行为："一旦启用，它会在指定时间自动运行，并可在面板中手动控制"。

三、B 类：UI 动作与状态

B 类术语为控件、标签和状态消息提供首选措辞，核心逻辑是"动词直接用动词、状态用形容词、对象标签用名词"：

例如 src/locales/en-US/common.json 中save、export、import、enable、disable、reset等动作词与规范一一对应，而delete_success（Delete Successful）正是 E 类审查目标中"标题式片段被用作消息"的实例。这说明规范不是在描述理想状态，而是针对仓库现状给出可执行的修正方向。

四、C 类：语境敏感措辞

C 类术语的特殊之处在于：最佳措辞取决于具体功能或 UI 表面，不能机械全局替换，规范为每项给出了决策规则：

其中"同步删除"在源码中有非常清晰的证据链：src/locales/en-US/settings.json 的sync_delete_desc明确写道：启用时脚本被删除会标记删除状态、其他设备检测到该状态后相应删除；禁用时则从本地和云端直接删除，多设备使用时可能引发重复同步问题。这解释了为什么措辞必须区分Sync Deletions（同步删除状态）与立即删除——两种行为语义完全不同。

五、D 类：需要保留的技术术语

D 类术语要求开发者面向的词汇保持技术精确，不得为了"通俗"而稀释其含义：

源码印证：src/locales/en-US/editor.json 中watch_file_description详细说明了 watch 行为——"监视文件变化并自动更新脚本，保持脚本文件路径不变且监视期间不要关闭本页面"；error_metadata_line_duplicated（There are duplicate declarations in the metadata.）把"重复声明"与"普通重复值"区分开，正是declaration术语的典型用例。而cron_invalid_expr（Invalid cron expression）与error_cron_invalid（Invalid cron expression: {{expr}}）都精确使用了cron expression而非笼统的condition。

六、E 类：文案审查目标

规范强调：建立这份规范本身并不会改变运行时的字符串，下列条目需要在一次有范围（scoped）的英文文案审查中结合 UI 检查来修正。每个目标在src/locales/en-US/*.json中都能找到对应实例：

以第一个目标为例，源码中的证据非常典型：src/locales/en-US/script.json 第 11 行subscribe_url确实是Subscribe URL，src/locales/en-US/install.json 第 5 行update_subscribe是Update Subscribe、第 160 行count_subscribes是{{count}} subscriptions——名词对象混用动词的现象一目了然。横向对比其他 locale（如 src/locales/zh-CN/script.json 的订阅地址、src/locales/de-DE/script.json 的Abonnement-URL）也能看出，多数语言已按"名词对象"处理，en-US的修正不会造成语义断层。

浏览器标签页目标的证据同样直接：script_run_env.all为All，而script_run_env.normal-tabs为Normal tabs、script_run_env.incognito-tabs为Incognito tabs（见 src/locales/en-US/settings.json 第 98-103 行），三个同层级入口的大小写与词形不一致。

七、推荐词汇对照表

对于对应语境下的新en-US字符串，规范给出了一张"推荐 vs 避免"的速查表：

这张表是日常写文案时的第一参考：先看概念落在哪一行，再决定用词；遇到表外情况再回到 A-E 分类中按决策规则判断。

八、AI 与贡献者的工作检查清单

规范的最后一节是一份面向 AI 任务与人类贡献者的 7 步检查清单，适用于"新增或编辑英文文案"的全部场景：

1. 确认目标 locale 是en-US，查阅本指南及相邻的既有 UI 字符串；
2. 同一 ScriptCat 概念使用同一产品/功能术语，不要因措辞相近而合并脚本类型；
3. 对语境敏感术语，先核对实际行为、控件类型与周边文本再修改；
4. 保留技术术语、产品大小写、元数据标识符、标签、插值值与 URL；
5. 将en-US视为其他 locale 的来源文案：不引入别扭语法、名词/动词歧义或未翻译的类型区分；
6. 只通过有范围的变更处理审查目标，并同时检查相关通知、tooltip 与标签；
7. 交付前搜索新编辑的英文文本，检查脚本类型命名不一致、Subscribe用作名词、浏览器标签页被叫成 tags、标识符被修改等问题。

这套清单与 docs/translation.md 中的"完成前检查清单"（确认 locale、使用自然表达、保留插值与标识符、运行pnpm run check:i18n）形成双重保障：前者管措辞质量，后者管 key 完整性。

九、与机械检查的配合：规范管措辞，脚本管完整性

值得强调的是，术语规范并不取代自动化检查。scripts/check-i18n.mjs（通过pnpm run check:i18n运行，并随pnpm lint/pnpm lint:ci自动执行）能静态验证：

• 每个 locale 目录都在 src/locales/locales.ts 中注册，NS数组与en-US/命名空间文件集合一致；
• 每个 locale 的*.jsonkey 与en-US（模板/回退语言）一一对应，缺失或多出都会报错；
• 每个 locale 都存在对应的docs/references/terminology-<locale>.md，缺失即检查失败；
• 每个 locale 都有对应的src/assets/_locales/<chrome-locale>/messages.json与editorLangs条目。

但正如 docs/translation.md 所强调：脚本只能证明 key 存在与对齐，无法判断措辞是否准确、是否符合术语规范——这恰恰是本文所述的terminology-en-US.md的职责所在。而 src/locales/i18n-usage.test.ts 仅扫描src/pages与src/app/service/service_worker中的t()/i18n.t()调用并按zh-CNresources 校验 key 存在性，同样不涉及译文质量。因此，术语规范的执行依赖"人 + AI 审阅"这一环：修改任何 locale 的翻译前，先读 docs/translation.md，再读对应语言的terminology-<locale>.md，最后用机械检查兜底。

结语

ScriptCat 的 terminology-en-US.md 是一份"小而完整"的文案治理模板：七条原则划定边界，五类表格覆盖产品术语、动作状态、语境敏感词、技术保留词与现存缺陷，推荐词汇表提供即查即用的决策依据，7 步检查清单保证 AI 与人类贡献者按同一标准交付。无论你是要为 ScriptCat 提交英文文案修正，还是在自己的多语言项目中建立术语规范，都可以直接复用这套结构——先定义"什么不能动"（元数据标识符、插值、产品大小写），再定义"什么该怎么说"（动作动词化、对象名词化、类型不合并），最后用有范围的审查与自动化检查收口。

• 前端
• 开发者工具
• 插件系统