用語集、ルールセット、ブランドボイスが組織レベルのアセットとして使えるようになり、エンジンに紐づけられるようになりました。
これまでは、それぞれが1つのエンジンに紐づいていました。たとえば、1つの用語集を3つのエンジンで使い回したい場合でも、3回作成する必要があり、コピーごとに少しずつ内容がずれていっていました。これからは、これらを組織アセットとして管理できます。用語集、言語ルールをまとめたルールセット、またはブランドボイスを一度作成すれば、必要なエンジンに紐づけるだけで使えます。共有アセットを編集すると、それが紐づいているすべてのエンジンに更新が反映されます。新しいエンジンを作るときも、空の設定から始める必要はありません。すでにあるアセットを紐づければ、その設定をそのまま引き継げます。
外部レビュー待ちの翻訳を社内で引き継ぎ#
human review ステージでは、翻訳を外部のプロ翻訳者に回せますが、その翻訳者から返答があるまでジョブは待機したままになります。今後は、権限を持つ社内メンバーが途中から対応できます。ダッシュボードで保留中のレビューを開いて判断を送信すれば、外部との往復を待たずにジョブはすぐに再開します。社内にその言語を扱える人がいて、より早くレビューを完了できるときに便利です。
CLI でフレームワークに合った出力パスを自動設定#
CLI は、各翻訳をフレームワークが実際に読み込むパスへ書き出せるようになりました。ロケールが独立したフォルダではなくファイル名の末尾につくレイアウトにも対応しています。たとえば Rails config/locales（新しい yaml-root-key 形式）や、Android、Xcode、Flutter（res/values-de/、app_de.arb、values-pt-rBR/ のような Android 修飾子）です。以前は、これらのファイルはフレームワークが参照しない場所に出力されていたため、翻訳ファイルが存在していても、アプリはソース言語のまま動いていました。
各フレームワークごとに、設定と翻訳をコミット済みの、そのまま動かせるサンプルリポジトリを用意しています。iOS、Android、Flutter、React + Vite、Next.js、Rails、Laravel、Markdown、Markdoc、OpenAPI、そして TypeScript modules です。1 つクローンして、lingo link を実行し、そのままプッシュするだけ。同じ設定を GitHub App でも変更なしで使えます。
