概要

gt-next 6.2.0 では、SWC プラグイン によって、処理をランタイムからビルド時へと移行する大きな一歩を踏み出しました。 このアプローチにより、コンパイル時ハッシュ、事前レンダリングされた翻訳、より厳密なバリデーションといった新しい機能を、ランタイムのオーバーヘッドを増やすことなく実現できます。

ポイントを明確にするため、まずは次の 3 つの主要な改善に絞って導入しました。

• コンパイル時ハッシュ
• オンデマンド翻訳
• ビルド時の lint ルール

コンパイル時のハッシュ計算

比較的小さな最適化ではありますが、ハッシュ計算を実行時ではなくビルド時に行うようにしました。
これにより、getGT() やサーバーサイドでの <T> などの関数は、呼び出しのたびにハッシュを計算してキャッシュする必要がなくなり、パフォーマンスがより安定します。

オンデマンド翻訳

開発中にリアルタイムで文字列の変更を確認するたびにページをリロードしなければならないことは、これまで開発者にとって大きな課題の1つでした。

getGT() と useGT() は、おなじみの i18n パターンに従います。

export default function Page() {
  const t = useGT()
  // const t = await getGT(); サーバーサイドの場合

  return (
    <>
      {t('翻訳するコンテンツ')}
      {t('翻訳する他のコンテンツ')}
    </>
  )
}

他の i18n ライブラリとそろえるために、あえて t() を同期処理のままにしていました。 そのデメリットとして、two-step translation process（二段階の翻訳プロセス）が必要でした。

1. テキストを API に登録する。
2. 翻訳済みの結果を表示するために、2 回目のレンダーを待つ。

現在は、コンパイラのおかげで翻訳対象のコンテンツが事前にスキャンされ、コンパイル時に直接 useGT() または getGT() に渡されます。 これにより、実行時には翻訳がその場で利用可能になり、ページのリフレッシュは不要です。

ビルド時のLint

これまでは、<T> コンポーネントの誤った使用を検出するには、カスタムリンターを使って gtx-cli を実行する必要がありました。 その結果、開発環境と本番環境での動作に不整合が生じていました。

バージョン 6.2.0 からは、Lint ルールが SWC プラグイン内で直接適用されます。 翻訳対象のコンテンツが <T> コンポーネントでラップされていない場合は、ビルド時エラーとなり、問題を早期に検出できるようになります。

なぜ（現時点では）SWCなのか？

ランタイムからビルド時への移行は、まだ始まったばかりの段階です。 まずは Next.js から対応を開始していますが、近いうちに他のフレームワークもサポートする予定です。 同等の機能を提供する Babel プラグインも、すでにロードマップに含まれています。

gt-next 6.2.0 は、より高速で信頼性の高い翻訳ワークフローの土台を築きます。 ロジックをビルド時に移行することで、ランタイムの複雑さを抑えつつ、翻訳をより即時性が高く、予測しやすいものにしています。