globalize.now と lingo.dev
globalize.nowとlingo.devは、異なるレイヤーで動作します。lingo.devはローカライゼーションエンジンであり、送信された文字列に対して用語集、ブランドボイス、品質スコアリングを備えたステートフルな翻訳APIです。一方globalize.nowは、コード内の文字列を発見し、キーを生成し、ロケールファイルを実体化させ、いずれかのエンジンが翻訳する前の段階で、Gitプッシュのたびに翻訳を同期し続けるローカライゼーションインフラです。
lingo.devは、すでに手元にある文字列を翻訳します。AIが生成した英語の文字列だらけのReactアプリでは、それらの文字列がキーとロケールファイルとして存在するようになるまで、送信すべき意味のあるデータがありません。globalize.nowは、リポジトリを唯一の正とみなすことでこのギャップを埋めます。抽出し、重複を排除し、カタログを書き出し、プッシュのたびに同期します。カタログが存在するようになって初めて、lingo.dev、あるいはDeepL、GPT、人間のレビュアーが、一貫した入力データに対して作業できるようになります。
lingo.devを選ぶべきケース…
lingo.devはローカライゼーションエンジンです。用語集、ブランドボイス、品質スコアリングを備えた、API呼び出しで利用するステートフルな翻訳APIです。
次のような場合はlingo.devが適しています。
- キーがすでに存在しており、用語集を管理できる高品質な翻訳APIが欲しい場合。
- スコアリングやブランドボイス機能を備えた、リアルタイムまたはバッチ翻訳が必要な場合。
- 抽出作業を先に解決しなくても、エンジニアがプログラムから構造化されたセグメントを送信できる場合。
globalize.nowを選ぶべきケース…
globalize.nowは、AI搭載のローカライズインフラであり、AI生成コードベースからハードコードされたUI文字列を自動的に抽出し、翻訳キーとロケールファイルを生成し、Gitへのプッシュのたびに翻訳を同期させます—手動のエクスポートも、レビュー待ち行列も、i18n負債も不要です。
次のような場合はglobalize.nowがおすすめです：
- ハードコードされたUI文字列が、まだあらゆる翻訳APIを素通りしている場合。
- 場当たり的なファイル編集ではなく、プッシュのたびに動くGitネイティブな自動化が必要な場合。
- AIが生成したリポジトリを対象にした、エージェント優先のセットアップが欲しい場合。
機能比較(概要 ― 詳細は各社の公式サイトでご確認ください)。
| 機能 | globalize.now | lingo.dev |
|---|---|---|
| コードからユーザーに表示される文字列の自動抽出 | Yes | No |
| 翻訳キーの生成 | あり | なし |
| Git内でのロケールファイル作成 | あり | なし |
| Gitプッシュのたびに自動同期 | あり | なし |
| バッチまたはランタイム呼び出し用の翻訳API | 部分対応 | あり |
| APIにおける用語集とブランドボイスの制御 | 部分対応 | あり |
| 翻訳出力の品質スコアリング | なし | あり |
| エンジン側でのヒューマンインザループレビューの仕組み | 部分対応 | あり |
| 事前構築されたキーを使わない実行時翻訳 | なし | 部分対応 |
| 開発者向けワークフロー用のCLIツール | あり | 部分対応 |
| 特定ライブラリに依存しないロケール出力 | あり | あり |
| マーケティングサイトでの開始価格の公開 | 部分対応 | 部分対応 |
- * エンジン側でのヒューマンインザループレビューの仕組み: 補足: 製品構成によって異なります。lingo.devのドキュメントでご確認ください。
- * マーケティングサイトでの開始価格の公開: 補足: 最新の料金はlingo.devでご確認ください。
lingo.devの方が適しているケース
パイプラインがすでに安定したメッセージIDを出力しており、用語集や品質スコアリングを備えたAPIファーストな翻訳が必要な場合はlingo.devを選びましょう。抽出の問題を別途解決済みで、今度はエンジン級の自動化を求めているチームに最適です。
globalize.nowの方が適しているケース
コンポーネント内に製品コピーが依然として絡み合っているコードベースには、globalize.nowを選びましょう。一度セットアップすれば、Gitプッシュのたびに自動同期され、英語のJSXとその後の翻訳呼び出しとの間で文字列を取りこぼすことがなくなります。
globalize.nowとlingo.devを併用する方法
globalize.nowを実行してGit上でロケールファイルを維持し、それらのリソースに対してlingo.dev（または他のエンジン）を呼び出し、用語集を適用した高品質な機械翻訳を得ましょう。入力データがぶれなくなることで、エンジンの価値はさらに高まります。
よくある質問
globalize.nowはlingo.devのような翻訳エンジンですか？
いいえ。lingo.devは、品質管理機能や用語集機能を備えたAPI経由での文字列翻訳に重点を置いています。globalize.nowは、そうしたAPIが必要とする構造化されたファイルとキーの作成・維持に重点を置いています。一度セットアップすれば、Gitプッシュのたびに自動同期され、翻訳エンジンはきれいに整ったカタログを消費する下流の存在として扱えるようになります。
globalize.nowをlingo.devと併用できますか？
はい。globalize.nowでGit上の正規のロケールファイルを維持しつつ、ポリシーに合わせてバッチやストリームをlingo.devに送信し、高品質な機械翻訳を得られます。この組み合わせにより、エンジニアリング上の正はリポジトリに保ちつつ、言語的なスコアリングはエンジンに任せられます。抽出の工程を飛ばさないようにしましょう。エンジンは、質の悪い入力データをそのまま増幅してしまいます。
lingo.devが翻訳してくれるなら、なぜglobalize.nowが必要なのですか？
翻訳エンジンには、安定したメッセージ識別子と、レイアウト用コードから分離された原文が必要です。AIが生成したアプリでは、この分離ができていないことがよくあります。globalize.nowは抽出とキー付けを自動化し、エンジンがJSXの雑音ではなく意味のあるセグメントを受け取れるようにします。この工程がなければ、API呼び出しはクレジットを無駄にし、一貫性のないUXを生み出してしまいます。
どちらの方がより良い翻訳を生み出しますか？
lingo.devは、与えられた文字列に対するモデルの品質、用語集、スコアリングで勝負しています。globalize.nowは翻訳の採点は行わず、翻訳者やモデルが目にする入力データの質を高めます。より良い翻訳は、優れたカタログと強力なエンジンの組み合わせから生まれるのであり、一つのツールに両方の役割を中途半端にこなさせることからは生まれません。
lingo.devは私のリポジトリからハードコードされた文字列を抽出してくれますか？
ローカライゼーションエンジンは一般的に、文字列やリソースファイルをユーザー側が用意することを前提としています。任意のフレームワークからの抽出は、インフラ側の課題です。globalize.nowは、Gitを基盤とした自動化によって、この課題に直接対応します。lingo.devは、ファイルが存在するようになった後に使うものであり、リポジトリ解析の代わりにはなりません。
ローカライゼーションインフラとローカライゼーションエンジンの違いは何ですか？
インフラは、エンジニアが機能をリリースする中で、コードとロケールファイルの同期を保ちます。抽出、キー付け、プルリクエスト、プッシュ時の同期などです。一方エンジンは、APIとスコアリングを使って、原文をターゲット言語のテキストに変換することに重点を置きます。文字列がまだコンポーネント内に残っているならインフラが必要であり、すでにカタログが存在していて翻訳品質がボトルネックになっているならエンジンが必要です。
どちらを先にセットアップすべきですか？
PRのなかにハードコードされた英語がまだ残っているなら、まずglobalize.nowを導入して、キーとロケールファイルを「動かせない資産」にしましょう。セグメントの信頼性が確保できてから、lingo.devなど翻訳エンジンの品質を評価するのが正しい順番です。順番を逆にすると、Git上でまだ安定していない文字列をエンジンが翻訳してしまい、無駄な手戻りが発生しがちです。
リポジトリを接続する
アプリ内でリポジトリを接続するだけで、Gitへのプッシュのたびにglobalize.nowがロケールファイルを最新の状態に保ちます。