概述

在 gt-next 6.2.0 中，我们借助一个 SWC 插件，朝着将处理从运行时迁移到构建时迈出了重要一步。 这种方式带来了编译时哈希、预渲染翻译和更严格的校验等新能力，同时不会增加运行时开销。

为保持内容聚焦，我们先从三个关键改进入手。

• 编译时哈希
• 按需翻译
• 构建时 lint 规则

编译时哈希

虽然这只是一个比较小的优化，但我们现在会在构建时计算哈希，而不是在运行时期间计算。 像 getGT() 和服务端 <T> 这样的函数不再需要在每次调用时都计算并缓存哈希，因此性能表现会更加稳定。

按需翻译

对开发者而言，开发时必须刷新页面才能看到字符串的实时更新，一直是最令人头疼的问题之一。

getGT() 和 useGT() 遵循常见的 i18n 模式：

export default function Page() {
  const gt = useGT()
  // const gt = await getGT(); 用于服务端

  return (
    <>
      {gt('some content to translate')}
      {gt('some other content to translate')}
    </>
  )
}

我们刻意将 gt() 设计为同步，以与其他 i18n 库保持一致。 缺点是需要经过一个两步翻译流程：

1. 向 API 注册文本。 2. 等待第二次渲染后才显示翻译结果。

现在，借助编译器，可翻译内容会预先扫描，并在编译时直接传入 useGT() 或 getGT()。 这意味着翻译在运行时即可立即使用——无需刷新页面。

构建时 Lint 检查

此前，要检测 <T> 组件的错误用法，需要运行带有自定义 linter 的 gtx-cli。 这会导致开发环境和生产环境的行为不一致。

从 6.2.0 起，lint 规则现已直接由 SWC 插件强制执行。 如果有任何可翻译内容未包裹在 <T> 组件中，你会收到构建时报错，从而确保问题能尽早发现。

为什么选择 SWC (目前) ？

我们从运行时迁移到构建时仍处于早期阶段。 我们先从 Next.js 开始，但很快也会支持其他框架。 具备相同功能的 Babel 插件也已列入路线图。

gt-next 6.2.0 为更快、更可靠的翻译工作流打下了基础。 通过将逻辑转移到构建时，我们在降低运行时复杂性的同时，也让翻译变得更即时、更可预测。