概览

作者在国际机票项目长期受制于低效、混乱的 i18n 管理方式，借酒店新项目机会，设计并落地了一套可复用的、自动化的 i18n 方案。核心目标是统一 key 规则、自动生成 JSON、用一条命令完成更新，并在生成阶段检测缺失翻译。

痛点

• Key 命名混乱：大小写、驼峰不统一，难以模块化。
• 不支持模块化：数千条 key 分散在 Excel，查找与维护成本高。
• 更新流程繁琐：导出 Excel、手动跑脚本、手动拷贝至项目，易出错且低效。
• 翻译来源不稳定：大量使用机翻，后续修订频繁，维护压力大。
• 旧项目历史包袱重：短期无法大改，只能在新项目中试点优化。

新方案目标与做法

• 统一 key 规则：模块.内容 的层级结构，内容间用下划线；示例 flight.order_submit。
• 自动化生成：新增 scripts 目录与 excel-to-json.js，从 Excel 读取后按语言输出多份 JSON。
• 一条命令更新：在 package.json 添加 i18n:excel-to-json，pnpm 一次执行完成读取、清空、生成、写入。
• 缺失翻译检测：遍历语言列，记录空白项并在控制台输出，便于补齐。
• 输出目录内聚：统一写入 src/i18n/locales，避免手动复制。

核心脚本要点

• 使用 XLSX 读取表格，按第一张 sheet 转换为 JSON 行数据。
• languageMap 将 Excel 表头（如 English、简中、French）映射至标准语言码（如 en、zh-CN、fr）。
• 通过 key 的点分层级构建嵌套对象，按语言聚合写出 en.json、zh-CN.json 等。
• 清空输出目录或初始化创建，确保生成文件与目录状态一致。
• 控制台日志对生成、清理与缺失翻译进行明确反馈。

成果与对比

• 脚本运行：旧流程需手动定位脚本；新流程 pnpm i18n:excel-to-json 一步到位。
• 文件投放：旧流程需手动拷贝；新流程自动输出到项目指定目录。
• 翻译完整性：旧流程无机制；新流程自动检测并提示缺失项。
• key 管理：旧流程无统一规则；新流程模块化层级明确、可维护。

迁移与复用视角

• 适合在新项目先行落地，通过统一约定与自动化减小维护摩擦。
• 未来旧项目如进入重构窗口，可平滑迁移：沿用 key 规范、脚本结构与语言映射。
• 若不希望自建，可评估文末提到的开箱即用的 JavaScript 国际化自动翻译方案，作为替代或补充工具链。

文章主题

作者讨论“HTML优先、框架次之”的前端开发趋势，提出这既是对过去“JavaScript优先/SPA中心化”的反思，也是对渐进增强与可访问性回归的一次系统性调整。核心观点：JavaScript并未被抛弃，而是从“无处不在的渲染”转向“在必要处增强”，体现生态的成熟。

背景与问题

长期的SPA与框架驱动导致：构建链路复杂（webpack、打包、Tree Shaking、水合策略）、性能退化、可访问性受损（空白屏、依赖JS可用性、爬虫/屏幕阅读器受阻）、开发者工作重心转向“运维式前端”。这类复杂性在很多场景并非源于业务需求，而是技术栈默认选择造成的负担。

HTML优先工具与方法

• Astro：默认不注入JS，按需客户端水合，主战场在HTML/CSS，追求性能与可维护性。
• HTMX：通过属性声明交互，以网络传输HTML为核心，轻量实现动态行为。
• Enhance、MarkoJS、Qwik：强调渐进增强与平台原生能力（Web Components、DOM），支持懒加载、水合与动态更新，但避免“全有或全无”的框架模式。 这些工具体现了一种文化转向：让HTML重新成为“一等公民”，以速度、可访问性和简单性为首要目标。

JavaScript的角色变化

SSR在Next.js、SvelteKit等推动下回归；React Server Components、Remix的服务器强调、Vue生态的轻量化共同表明对“客户端膨胀”的控制诉求。结合边缘计算与安全考量（如DDoS面向的攻击面缩减），JS更多用于关键交互与增强，而非承担全部渲染。

为什么重要

• 用户体验：更快的加载、更好的降级行为、与SEO和辅助技术更兼容。
• 评估标准：与Core Web Vitals及移动性能预算更契合，功能不仅要实现，还要以高效方式实现。
• 人才培养：降低入门门槛，避免新手被构建工具与框架语法牵制，回到Web基础能力。

可扩展性与实践

大规模团队（如Google、Netlify、Shopify）探索HTML优先与“岛屿架构”，以驯服不断增长的前端代码库。复杂性仍在，但变得更模块化、更依赖平台原生行为，而非绑定单一框架生命周期或状态模型。

对开发者的具体要求

• 语义化与可访问性：用结构清晰的HTML直达浏览器与辅助技术的意图表达。
• HTTP动词与服务器响应：围绕GET/POST与SSR进行状态转换，不把所有状态管理下放到客户端。
• CSS优先：用过渡、媒体查询、容器查询等满足交互与适配需求，在原生方案足够时避免JS。
• 基于表单与可导航URL设计交互：保证回退能力、分享性与前端复杂度可控，不依赖封闭式shadow DOM或过度API路由。

未来的架构取向

前端将走向“分层而非堆叠”：HTML提供结构，CSS负责呈现，JavaScript在必要处增强。框架继续存在，但作为增强层而非基础层。这意味着对“何时使用JS”的更精确判断与更克制的架构决策，标志着生态的成熟。

结论性洞见

“HTML优先”的回归不是怀旧，而是对Web平台原生能力的重新信任与利用。通过让浏览器做擅长的事，再在确需处引入框架和JS增强，可以同时获得性能、可访问性、可扩展性与开发体验的平衡。

Preact 11 Beta 概览

Preact 发布 11 Beta，重点在 Hydration、Ref 处理与打包格式的现代化，并移除部分遗留特性以简化核心与提升一致性。

关键更新

• Hydration 2.0：组件在服务端渲染后回到客户端时，异步边界不再限制为单一 DOM 节点，允许返回零个或多个节点。举例：一个在加载数据时“suspend”的列表组件，可以在不同分区逐步插入多个子节点，而不是被强制挂在一个占位节点上。这为复杂布局与分段渲染提供更高自由度，并贴近现代渲染模式。
• 默认 ref 转发：函数组件可直接接收 ref，无需显式 forwardRef。示例： function MyComponent({ ref }) { return

  Hello, world!

  ; } ; 这减少样板代码，并提升与 React 生态库的兼容性。
• Hook 依赖比较使用 Object.is：依赖数组采用 Object.is，解决 NaN 等边界值比较问题，使 useEffect 与 useState 的依赖判断更可靠。
• ESM 包改用 .mjs：统一输出为 .mjs，替换旧的 .module.js。同时保留 CommonJS 与 UMD，以兼容不同打包环境。
• 移除与迁移的特性：
  • 自动 CSS px 后缀移除；
  • defaultProps 移至 preact/compat；
  • 完全移除 component.base、SuspenseList、replaceNode。
• 基线要求提升：不再支持 IE11，要求 TypeScript ≥ 5.1。这解锁更完善的 JSX 类型能力，也减轻旧浏览器适配成本。

性能与稳定性

维护者提到内部包含内存修复、更好的错误边界、优化的渲染路径等改进。一位用户反馈升级后与 Zustand 5 配合，bundle 减少约 4KB。

迁移与生态

团队提供 迁移指南，列出破坏性变更与替代方案。整体设计尽量降低升级阻力，同时推动生态与现代模块约定对齐。

背景与定位

11 版本的推进可追溯至 2020 的 GitHub 议题。维护者明确在出现需要破坏性变更时才推进大版本。Preact 仍以小体积、与 React 高兼容性为核心定位，在 性能敏感场景、PWA、嵌入式 等保持吸引力。本次升级聚焦于 Hydration 现代化 与 API 人机工程，在不牺牲轻量特性的前提下提升开发体验。

摘要

GitHub 发布了新的 Copilot embedding model，用于提升 VS Code 中的代码检索与上下文获取。该模型专为代码与文档场景训练，现已用于 Copilot 的 chat、agent、edit、ask 模式。核心改进包括更高的检索准确率、更快的吞吐、更小的索引内存占用，从而使回答更可靠、响应更快、客户端资源消耗更低。

关键指标

• 检索质量提升：平均分由 0.362 提升至 0.498，相对提升 37.6%。在 VS Code 中，C# 与 Java 的代码接受率分别提升 110.7% 与 113.1%。
• 效率：嵌入吞吐约 2x；索引内存占用约 8x 缩小；降低 P50 延迟与内存位数。
• 效果示例：针对“单一 namespace 查找”查询，新的模型能准确检索到 findOne 方法，而旧模型更易检索到语义相近但不正确的 find 方法。

技术方法

• Contrastive learning + InfoNCE：通过对正负样本的区分优化语义检索能力。
• Matryoshka Representation Learning：同一语义在多种 embedding 尺寸下保持稳定表现，便于在不同资源约束下部署。
• Hard negatives：从大规模多样语料（公开 GitHub 与 Microsoft/GitHub 内部仓库）挖掘“看似正确但不满足意图”的代码片段，并借助 LLM 提供更具迷惑性的近似样本，强化模型对“近似错误”的识别能力。

训练与评估概况

• 数据语言分布：Python 36.7%、Java 19.0%、C++ 13.8%、JavaScript/TypeScript 8.9%、C# 4.6%、其他 17.0%。
• 评测维度：
  • NL → Code：自然语言查询到代码片段；
  • Code → NL：代码摘要；
  • Code → Code：相似函数检索（含重构/跨语言）；
  • Problems → Code：从问题表述到修复方案建议。

典型应用场景

• 在大型 monorepo 中定位测试函数。
• 跨多文件检索分散的 helper 方法。
• 调试定位错误处理入口，例如“这个 error string 在何处被处理”。

对开发者的实际意义与类比

• 对话与代理更可靠：检索更精准意味着上下文注入更准确，减少“近似但错误”的参考对生成的负面影响。
• 性能与资源占用优化：吞吐提升与索引压缩有利于本地开发环境与服务器端扩展，尤其是 VS Code 中的内存占用下降。
• 简化认知负担：将“找对上下文”变成稳定的基础设施。例如，就像在设计系统中快速匹配正确的组件变体（按钮的 filled vs outline），embedding 能从语义上区分“看起来类似但用途不同”的实现细节（findOne vs find）。

后续规划

• 扩展训练与评测到更多语言与代码库。
• 精炼 hard negative 挖掘流程以进一步提升质量。
• 依托效率收益部署更大、更准确的模型。

Qwen3‑VL 概览

Qwen 团队发布新一代视觉‑语言系列 Qwen3‑VL，旗舰开源模型为 Qwen3‑VL‑235B‑A22B，提供 Instruct 与 Thinking 两个版本。焦点在跨模态的深度理解与推理，并扩展到长上下文与视频、空间与多图理解、智能代理操作等。

关键能力

• Visual Agent：识别 GUI、理解控件语义、调用工具，完成真实设备上的任务；在 OS World 等基准表现靠前。
• Text‑centric：文本与视觉早期联合预训练，纯文本任务性能接近 Qwen3‑235B‑A22B‑2507，降低“偏视觉/偏文本”的失衡。
• Visual Coding：从图片/视频生成代码（Draw.io、HTML/CSS/JS），实现基于视觉的 WYSIWYG 式开发辅助。
• Spatial Understanding：2D 相对坐标与 3D grounding，支持方位、视点、遮挡判断，为 embodied 场景打基础。
• Long Context & Video：原生 256K tokens，可扩展至 1M；视频“needle‑in‑a‑haystack”在 256K 下 100% 准确，1M 下 99.5%。
• Multimodal Reasoning (Thinking)：在 MathVision、MMMU、MathVista 等推理基准表现强，强调 STEM/数学的逐步分析与证据链。
• Perception & Recognition：更广泛的类别覆盖（人物、商品、地标、动植物等），强多语言 OCR（32 languages），复杂场景更稳健。

模型表现

• Instruct 版本：在多数视觉指标上优于同类开源与多款闭源模型（文中点名 Gemini 2.5 Pro、GPT‑5），通用性与复杂任务性能突出。
• Thinking 版本：在开源模型中多项刷新记录；与顶级闭源模型在跨学科、视觉推理、视频理解上仍有差距，但在代理、文档、2D/3D grounding 上具优势。
• 文本任务上，两版性能与 Qwen3‑235B‑A22B‑2507 接近。
• 工具增强：Instruct 支持“图像 + 工具调用”，在精细感知与 embodied 任务上稳定提升。
• 多语言 OCR 测试：自建 39 语言集，32 种语言准确率超过 70%。

架构与训练更新

• Interleaved‑MRoPE：将 t/h/w 交错分配到各频带，保留图像理解同时显著增强长视频时序建模。类比：把时间与空间信息“均匀撒到”频谱各处，避免某一维只落在高频。
• DeepStack：多层注入视觉 token，融合 ViT 多层特征并优化 tokenization，使低‑高层视觉信息都能被 LLM 捕获与对齐。类比：不再把整张图只塞到一层，而是分层喂给模型，细节与语义同步提升。
• Text‑timestamp alignment：以“timestamp‑frame”交错输入，原生支持秒与 HMS 输出，提升事件定位与动作边界的语义‑时间对齐。类比：在字幕时间线上逐帧贴标签，查询定位更精确。

能力演示（摘录）

• Visual Agent：移动端/桌面 UI 操作与流程执行。
• Think with Images：细粒度识别结合工具推理（如路标定位、局部人像识别）。
• Code Programming：草图到网页、UI 调试辅助。
• 2D/3D Grounding：密集目标框与三维框估计，坐标改为相对表达更鲁棒。
• Universal Recognition：动漫角色、品牌等多域实体识别。
• Creative Writing：基于图像生成文案与脚本。
• STEM Reasoning：逐步物理/数学推导与验证。
• Complex Doc Parsing：长/多页 PDF、超宽网页解析；新增 QwenVL Markdown 降低 token 成本并保留结构。
• Multilingual OCR & VQA：希腊语等多语种文本抽取。
• Multi‑Image Dialogue：跨图比较与多轮上下文保持。
• Video Understanding：长视频事件定位与结构化描述，游戏视频到代码生成。

API 使用

提供兼容 OpenAI 接口的示例（Aliyun DashScope base_url），模型名 qwen3‑vl‑235b‑a22b‑Instruct，并可在“更多示例”链接查看扩展用法。适用图文联合输入与标准对话式 completions。

总结与定位

Qwen3‑VL 聚焦“看懂‑推理‑执行”的闭环，强调文本与视觉的均衡能力，强化长序列与时序定位、空间理解、工具增强与代码生成。开源旗舰旨在作为社区探索的坚实基线，并面向真实世界事件与关系的可操作代理。