Quetzal

Quetzalの核は、周囲まで読む翻訳だ。孤立した文字列をモデルに送るのではなく、各文言の周辺コード、近くのコンポーネントやprops、意図を説明するコメントを集める。この文脈が、モデルの手にあるのがボタンか、見出しか、エラーかを教える。機械翻訳がつまずくのはまさにここだ。限界は、周辺コードの質が効いてくる点にある。整った構造のリポジトリは材料が多く、絡まったものは少ない。

ブランド名、製品名詞、専門用語には用語集があり、Quetzalは推測せずにそれを適用する。既存の翻訳を読んでトーンと文体を推し量り、その声を言語ごと、リリースごとに一定に保つ。10言語でブランドの声を揃えたいチームにとって、これは誰も読まないスタイルガイドの代わりになる部分だ。既存の文言が学べるほど統一されているとき、最も効く。

Quetzalは翻訳するだけではない。他のツールが済ませた仕事を監査し、誤りを示して修正を提案できる。そして、ローカライズに入りそこねたユーザー向けテキストを洗い出す。後者の仕事は見た目より重い。べた書きの文字列こそ、完全にローカライズされたはずのアプリがダイアログで生の英語を出す原因だ。どちらの監査も同じ確認とマージの流れで走るので、作業手順に余計なものが足されない。

Quetzalは導入すべき新しい翻訳ライブラリではない。すでに動かしているスタックに差し込まれる。JavaScript、TypeScript、React、Next.js、Swift、Python、Kotlin、Java、HTML、XMLを一級でサポートし、どんなi18nフレームワークとも動く。つまり書き直しもパイプラインの移行も不要だ。難点は、それでも接続するリポジトリが要ること。読めるコードベースのないプロジェクトや、翻訳をバージョン管理の外に置くチームには向かない。

更新は開発者がすでに働いている場所に届く。Quetzalはプルリクエストを開くかコミットするので、翻訳はほかのコード変更と同じ確認、履歴、取り消しを通る。別に見るべきダッシュボードも、エクスポートとインポートの往復もない。gitで生きるチームにとって、これが売り込みのすべてだ。ローカライズは繰り返しの雑務ではなく、背後で回る工程になる。

リポジトリ内の静的な文言と、ユーザーが作る文章や実行時に生成される文章は別物だ。Quetzalは非静的コンテンツを翻訳するAPI（api.qtzl.aiでホストされ、キーで認証する）を用意する。本当に恩恵を受ける内容にAPIを合わせるため、まず文脈プロファイルについて話したいとしている。これはQuetzalをコード専用の道具から一歩押し出す部分だが、狙いはあくまで開発者であり、一般ユーザーではない。