前端开发者工具插件系统【免费下载链接】scriptcatScriptCat, a browser extension that can execute userscript; 脚本猫一个可以执行用户脚本的浏览器扩展项目地址https://gitcode.com/gh_mirrors/sc/scriptcat点击查看免费下载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 条原则。这些原则界定了术语修正的边界使用简洁的美式英语 UI 文案直接陈述动作或状态保持User Script、Page Script、Background Script、Scheduled Script四种脚本类型的产品区分不可互相替换禁止仅凭拼写做全局替换——必须确认功能、UI 位置、周边文案以及该字符串是标签还是句子面向开发者的术语必须保持技术精确包括regular expression、cron expression、watch、storage和元数据标识符不得改动占位符、HTML/React 标签、i18next 插值、URL 或match、exclude、grant、connect等标识符en-US是回退语言与翻译模板含糊或不地道的英文应被刻意修正而不是传播到其他 locale下表列出的 key 记录的是当前实际用法或已知审查目标同一含义的未来字符串同样适用。从源码结构看这些原则与 docs/translation.md 中不要把某个界面文案的修正扩大成该词在所有上下文中的禁用规则的要求是相互呼应的——术语规范只约束明确的场景语境敏感项必须逐个核对。二、A 类产品与功能术语A 类术语解决ScriptCat 的能力和脚本类型该叫什么的问题。规范要求保留ScriptCat的产品大小写ScriptCat而非Scriptcat并严格区分四种脚本类型概念推荐措辞当前示例 key备注ScriptCat 浏览器扩展ScriptCat extensionwelcome_title、ext_update_notification保留ScriptCat产品大小写通用用户脚本能力user script/userscriptcreate_user_script、script_list_content、READMEUI 类型标签用User Script行文可统一用userscript普通用户脚本类型User Script当前类别标签Normal Scriptcreate_user_script、script_list.sidebar.normal_script不得与后台/定时脚本合并Tampermonkey 兼容Tampermonkey-compatible userscript/Tampermonkey scriptREADME.md、docs/architecture.md仅在讲兼容性时使用页面脚本Page Scriptscript_list_enable_content指在页面中运行的脚本概念勿静默替换普通脚本类别标签后台脚本Background Scriptcreate_background_script、background_script、enable_background.descriptionScriptCat 的脚本类型之一具备后台运行能力定时脚本Scheduled Scriptcreate_scheduled_script、scheduled_script、scheduled_script_description_title用产品术语不引入crontab script脚本同步Script Syncscript_sync、sync_status、setting_sync_title涉及删除时须说明同步的是删除状态还是内容脚本订阅Subscriptionsubscribe、subscribe_url、importpage.count_subscribesSubscribe仅作动词/控制动作对象用Subscription脚本市场Script Gallery/Script Marketscript_gallery、script_list_title与目标市场的产品标签保持一致勿擅自合并名称在源码中可以找到这些规则的直接证据。例如 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 类术语为控件、标签和状态消息提供首选措辞核心逻辑是动词直接用动词、状态用形容词、对象标签用名词概念推荐措辞当前示例 key备注创建Createcreate_script、create_background_script、create_success_note用于创建动作与确认保存/另存为Save/Save Assave、save_as、save_as_success作为标签时首字母大写行文中用句子大小写导入/导出Import/Exportimport、export、import_file、export_file标准数据/文件动作安装/更新Install/Updatescript、update_script、success需要消歧时补充对象名运行/运行时Run/Runtimerun、running、runtime、log_title执行日志用Runtime Logs启用/禁用Enable/Disable状态Enabled/Disabledenable、disable、updatepage.enabled、updatepage.disabled功能启停避免用open/close设置/配置Settings/Configurationsettings、script_setting、editor_configUI 选项是 settings配置数据或编辑器配置用 configuration连接/同步Connect/Syncconnect、connection_success、script_sync连接状态与数据同步分开恢复/重置Restore/Resetrestore、restore_default_values、reset按恢复已存/默认内容或重置设置区分加载/重新加载Loading/Reloadloading、loading_title、click_to_reload使用自然的进行时/动作形式目录Directoryopen_directory、open_backup_dir适合面向开发者的文件系统功能浏览器标签页Tabclose_current_tab、close_other_tabs不得把浏览器标签页叫tags例如 src/locales/en-US/common.json 中save、export、import、enable、disable、reset等动作词与规范一一对应而delete_successDelete Successful正是 E 类审查目标中标题式片段被用作消息的实例。这说明规范不是在描述理想状态而是针对仓库现状给出可执行的修正方向。四、C 类语境敏感措辞C 类术语的特殊之处在于最佳措辞取决于具体功能或 UI 表面不能机械全局替换规范为每项给出了决策规则概念候选措辞决策规则当前示例 key本地/云端Local/Cloud用于数据来源、目的地与存储位置对象不明确时加device或storagelocal、cloud、source_local_script、tools_backup_content面板/控制台panel/consoleScriptCat UI 控件用panel开发者工具输出用consolebackground_script_description、build_success_message来源Source、Install Source、Subscription Source命名来源所提供的内容订阅对象不是动词source、importpage.col_source、source_subscribe_link权限/授权Permission、Allow、Grant access能力记录用 permission决策用 allow/deny解释句用 grant accesspermission、duration_once、confirm_script_operation运行位置/应用Applies To、Run Status重写Apply To / Run Status前先验证列行为——它可能合并了两个独立概念apply_to_run_status、script_list_enable_title同步删除Sync Deletions/Sync Deletion Status先确认设置是传播墓碑标记还是立即执行删除sync_delete、sync_delete_desc、notification.script_sync_delete匹配/排除Match/ExcludeUI 编辑规则时保持match、exclude元数据标识符可见website_match、website_exclude、add_match、add_exclude其中同步删除在源码中有非常清晰的证据链src/locales/en-US/settings.json 的sync_delete_desc明确写道启用时脚本被删除会标记删除状态、其他设备检测到该状态后相应删除禁用时则从本地和云端直接删除多设备使用时可能引发重复同步问题。这解释了为什么措辞必须区分Sync Deletions同步删除状态与立即删除——两种行为语义完全不同。五、D 类需要保留的技术术语D 类术语要求开发者面向的词汇保持技术精确不得为了通俗而稀释其含义概念用法当前示例 key原因正则表达式regular expression/ 紧凑标签regexsearch_regex标准开发者术语cron 表达式cron expressioncron_invalid_expr、error_cron_invalid精确标识所接受的调度语法表达式expressionvalue_export_expression、cookie_export_expression、expression_format_error保留输入或求值的表达式的技术含义监视文件变化Watch File/Stop Watchingwatch_file_description、watch_file、stop_watch_filewatch描述开发者工具中持续的文件变化监视元数据声明declarationerror_metadata_line_duplicated对应元数据语法而非普通重复值存储 / Storage APIstorage/Storage APIscript_storage、storage_api、script_operation_title功能与 API 术语产品/API 标识符保留ESLint、VSCode、Cookie、GM API、resource、requireenable_eslint、vscode_url、permission_cookie、script_resource_tooltip名称与元数据标识符必须保持可辨识、准确源码印证src/locales/en-US/editor.json 中watch_file_description详细说明了 watch 行为——监视文件变化并自动更新脚本保持脚本文件路径不变且监视期间不要关闭本页面error_metadata_line_duplicatedThere are duplicate declarations in the metadata.把重复声明与普通重复值区分开正是declaration术语的典型用例。而cron_invalid_exprInvalid cron expression与error_cron_invalidInvalid cron expression: {{expr}}都精确使用了cron expression而非笼统的condition。六、E 类文案审查目标规范强调建立这份规范本身并不会改变运行时的字符串下列条目需要在一次有范围scoped的英文文案审查中结合 UI 检查来修正。每个目标在src/locales/en-US/*.json中都能找到对应实例目标当前措辞或问题推荐方向当前示例 key订阅作名词对象标签用Subscribe如Subscribe URL、Install Subscribe对象值用Subscription URL、Install Subscription、Update Subscription复数用Subscriptionssubscribe_url、subscribe、update_subscribe、importpage.count_subscribes、notification.subscribe_update浏览器标签页全部标签页入口只有All而相邻条目明确写Normal tabs、Incognito tabs若这些值面向浏览器标签页用All Tabs、Normal Tabs、Incognito Tabsscript_run_env.all、script_run_env.normal-tabs、script_run_env.incognito-tabs定时脚本命名某状态字符串写crontab scripts而功能名是Scheduled Script统一用scheduled scriptsonly_background_scheduled_can_run、scheduled_script产品大小写Scriptcat extension updated与ScriptCat不一致保留ScriptCat大小写ext_update_notification标题式片段作消息许多成功/错误消息使用名词式形式如Delete Successful、Update Successful、Dump success saved通知类用自然结果消息如Deleted successfully、Updated successfully、Export successful标签大小写另计delete_success、update_success、export_success、success交互指引链接用tap或Click me部分说明文字语法不通用一致的桌面 UI 措辞如Click to learn how to enable it说明用完整句子develop_mode_guide、allow_user_script_guide、lower_version_browser_guide、blacklist_placeholder、link_import_placeholder浏览器专属后台行为后台运行文案要求用户退出Chrome但 ScriptCat 支持多浏览器确认实现行为后除非设置是 Chrome 专属否则用the browserenable_background.description以第一个目标为例源码中的证据非常典型src/locales/en-US/script.json 第 11 行subscribe_url确实是Subscribe URLsrc/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 避免的速查表推荐除非特定语境需要否则避免ScriptCatScriptcatUser Script、Page Script、Background Script、Scheduled Script用Normal Script或crontab script作为未经证实的替换类型对象用Subscription动作用Subscribe把Subscribe用作名词产品选项用Settings配置数据用Configuration无空间限制时在面向用户的文案中使用Config浏览器标签页用Tab用Tag指浏览器标签页regular expression/regex在接受 regex 语法时使用含糊的conditionStorage API改名后的 API 术语require、resource、match、exclude、grant、connect被翻译或拼错的元数据标识符这张表是日常写文案时的第一参考先看概念落在哪一行再决定用词遇到表外情况再回到 A-E 分类中按决策规则判断。八、AI 与贡献者的工作检查清单规范的最后一节是一份面向 AI 任务与人类贡献者的 7 步检查清单适用于新增或编辑英文文案的全部场景确认目标 locale 是en-US查阅本指南及相邻的既有 UI 字符串同一 ScriptCat 概念使用同一产品/功能术语不要因措辞相近而合并脚本类型对语境敏感术语先核对实际行为、控件类型与周边文本再修改保留技术术语、产品大小写、元数据标识符、标签、插值值与 URL将en-US视为其他 locale 的来源文案不引入别扭语法、名词/动词歧义或未翻译的类型区分只通过有范围的变更处理审查目标并同时检查相关通知、tooltip 与标签交付前搜索新编辑的英文文本检查脚本类型命名不一致、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 提交英文文案修正还是在自己的多语言项目中建立术语规范都可以直接复用这套结构——先定义什么不能动元数据标识符、插值、产品大小写再定义什么该怎么说动作动词化、对象名词化、类型不合并最后用有范围的审查与自动化检查收口。赞分享前端开发者工具插件系统【免费下载链接】scriptcatScriptCat, a browser extension that can execute userscript; 脚本猫一个可以执行用户脚本的浏览器扩展项目地址https://gitcode.com/gh_mirrors/sc/scriptcat点击查看免费下载相关推荐ScriptCat 土耳其语tr-TR界面术语规范一份可直接落地的本地化术语指南ScriptCat 土耳其语tr TR界面术语规范一份可直接落地的本地化术语指南 本篇技术指南围绕 ScriptCat 开源仓库中的土耳其语术语规范文档前端开发者工具插件系统Druid SQL 解析器 Feature Gate 命名规范化重构LexerFeature / ParserFeature 命名契约设计与实践Druid SQL 解析器 Feature Gate 命名规范化重构LexerFeature / ParserFeature 命名契约设计与实践 导读 本文基前端开发者工具插件系统12 分钟实测OpCore-Simplify 一键生成可启动的 OpenCore EFI12 分钟实测OpCore Simplify 一键生成可启动的 OpenCore EFI 上周我用它给一台 2018 年的老笔记本8 代 i5、UHD 62前端开发者工具插件系统上一篇TDengine PERFORMANCE_SCHEMA 性能监控视图完全指南从 PERF_APPS 到 PERF_TRANS 的字段解析与实战查询下一篇在 Snowpack 项目中使用 Jest官方预构建配置与集成实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考