UGA Boxxx

つぶやきの延長のつもりで、知ったこと思ったこと書いてます

【i18n】LayerXさんのi18n対応

JSConf2024でLayerXさんの企業セッション「静的解析を活用したi18n対応」を聞いた

jsconf.jp

LayerX さんの i18n導入時に直面した課題とその解決方法について話されていた

課題は以下

  • 特定ページに限定してi18n対応を行う必要がある
  • 依存関係のあるコードベースにのみ翻訳漏れ検証を行う
  • 全コードベースを検証する既存のESlLintを適用できない

これに対する解決策として、まずはカスタムLint を使ったとのこと(これは以前のJSConfでの登壇での話)

この時の全体のアーキテクチャは以下

  1. jsonファイルに翻訳対象となるページを定義
    • vueのファイルパスをtargetPagesとしてjsonに定義する
  2. mtsで用意したスクリプトからESLintを実行
    • ts-nodeで実行可能なmtsファイルでスクリプトを用意し、カスタムESLintを実行
    • 再帰的な処理により、別ファイルへのアクセスをするが、エラーが全て元のファイルに対するエラーになってしまうので、そこを工夫した
    • chalk で出力結果の色付け
  3. 指定されたページから参照されるコードを再帰的に検索して、翻訳漏れを検知
    • vueファイルをASTに変換する
    • importがあれば、参照しているファイルを検証する
    • t関数で囲まれていなければエラーとする

ただ、このやり方では処理時間が長く、マージの度にやるには辛すぎたらしい

原因は以下を挙げていた

  • targetファイルごとに依存ファイルを再帰的に検査したため重複解析が発生
  • 各tagetファイルごとに管理していた訪問済みファイルが限界
  • ESLintの汎用性によるオーバーヘッド
    • 翻訳漏れ検知には不要なScope Analysisを実行している

この解決策として、ESLintを使わずに、静的解析スクリプトにして、targetファイル共通で1つの訪問済みファイルを共有するようにしたとのこと

これにより、約80%の時間短縮させたのはすごい

非エンジニア向けのUIチェック環境

話を聞いていた興味があったのは非エンジニア向けのスプレッドシートの話

私も以前の現場で、翻訳一覧をスプレッドシートで管理していて、全く同じ問題にぶつかった

その問題は以下のようなこと

  • 翻訳情報が更新された時に、どの画面に影響が出るかが不明
  • エンジニアが使用箇所をコードベースから検索する必要が発生

私の場合は、まだ小規模だったので解決に向けて取り組まなかったが、LayerXさんでは解決策として、以下のことを行なったとのこと

静的解析スクリプトを流用し、依存関係のあるコードベースの検証スクリプトを流用し、各翻訳キーの使用箇所を特定

  1. 指定されたページから再帰的にコードを辿り、翻訳関数で使われるキーを検出
  2. csvファイルに、キーに対して呼び出されている「コンポーネント」と「大元のページパス」を保持
    • マージが行われるたびにGHAで実行
  3. スプレッドシートとの接続を担っているツールを介して、csvファイルの内容をシートに転記
  4. 翻訳辞書シートにキーで突合してページパスからURLを生成して表示

i18nの取り込みを結構細かく教えてもらい学びの多いセッションだった