ダッシュボードなしでv0アプリをローカライズするにはどうすればいいですか?

v0アプリをローカライズするには、v0が既に書き込んでいるGitHubリポジトリを翻訳カタログの保管場所として扱い、コミットされたファイルとしてそこに保持し続けます。この一つの判断こそが、ダッシュボードを「選択肢の一つ」ではなく「不要なもの」にします。globalize.nowはAIを活用したローカライゼーション基盤で、キーとロケールファイルを生成し、それらは使用しているランタイムライブラリによって配信されます。v0はホスティングされた1枚のページではなく、完全なNext.jsコードベースを提供するため、リポジトリネイティブなアプローチは最初のプロンプトの時点から選択可能です。

なぜあなたのv0アプリは英語専用になっているのですか?

インターフェースのテキストが、コンポーネント内にリテラル文字列としてそのまま埋め込まれているからです。v0に価格セクションを依頼すると、カタログを参照するのではなく<h2>Simple pricing</h2>をそのまま書き込みます。見出し、ボタンのラベル、空状態の表示、トースト通知、フォームのエラーメッセージまで、すべてがプロンプトで使った言語のままTSXコード内に現れます。

これはv0の欠陥ではありません。プロンプト駆動型のビルダーはどれも同じことをしますし、Cursorがハードコードされた文字列を追加し続ける件で記録したのと同じパターンです。モデルは、依頼された内容に対して最短で正しく動くコードを書きます。あなたはロケール層を依頼しなかった、というだけのことです。

結果として、設定画面を編集するだけでは翻訳できないアプリになります。そもそも編集できる対象が存在しないのです。文字列にはキーがなく、ルートにはロケールを表す部分もありません。

v0は実際には何を生成しているのですか?

一般的なNext.jsプロジェクトです。これは朗報です。v0の標準スタックはNext.js、React、TypeScript、Tailwind CSS、shadcn/uiで、出力は単一のコンポーネントではなく、ルートとAPIハンドラを備えた完全なApp Routerアプリケーションです。ここでshadcn/uiが重要になる理由が一つあります。そのコンポーネントはパッケージからインポートされるのではなく、ソースコードとしてリポジトリにコピーされるため、そこに含まれる文字列は自分のものになります。

ローカライゼーションにおいて重要な事実はこのスタックだけであり、これはi18nの世界で最も充実したドキュメントが揃っている構成です。next-intlはApp Routerを前提に構築されており、LinguiとReact-intlもどちらも対応しています。v0には、ビルダー専用の翻訳製品を必要とする要素は何もありません。

別のビルダーでViteスタックを使ってアプリを構築した場合は、ダッシュボードなしでLovableアプリをローカライズする方法が、そちら側での同じ考え方を解説しています。

v0プロジェクトをリポジトリに取り込むにはどうすればいいですか?

多くの場合、既にリポジトリは存在しています。v0のチャットがGitHubに接続されている場合、v0はベースブランチから作業用ブランチを作成し、コードを変更するすべてのメッセージをそのブランチに自動コミットします。公開操作を行うと、プルリクエストが新規に開かれるか既存のものが再利用され、ベースブランチにマージされます。つまりリポジトリは最後に追加するステップではなく、v0が最初からずっとコードを置いてきた場所です。現行の流れについてはv0自身のGitHub関連ドキュメントが正式な参照先です。この部分の仕様は何度か変更されているため、実践する前に確認してください。

このブランチモデルは、ローカライゼーションにおいて特に有用です。カタログ、設定ファイル、ロケールルーティング用のミドルウェア変更、言語切替コンポーネント――これらはすべて追跡対象のファイルへの変更です。チャットパネル上で読むより、ブランチ上の差分としてレビューする方がはるかに簡単ですし、翻訳用のプルリクエストは、それが翻訳対象とする機能のプルリクエストと並べて置くことができます。

「ダッシュボードなし」とは実際どういう意味ですか?

翻訳済みの文字列がリポジトリ内のファイルとして存在し、Next.jsアプリが他の通常のコンテンツと同じ方法でサーバー上でそれらをレンダリングすることを意味します。scriptタグもなく、ページ読み込み時の外部フェッチもなく、訪問者と表示内容の間にベンダーのアカウントが介在することもありません。

その対照にあるのが、Weglotなどのツールが採用しているウィジェット方式で、ページの読み込み後に翻訳を行います。これには確かな便利さがあります――スニペットを貼るだけで、その日の午後には何かが動き出します。ただ、そのコストは後から現れ、しかも修正可能なものではなく構造的なものです。

• 最初の描画はソース言語のままなので、訪問者には切り替わる前の英語が一瞬見えてしまいます。
• 翻訳済みのテキストはサーバーレンダリングされたHTMLに含まれないため、検索エンジンがロケールごとにインデックスする内容が弱くなります。Next.jsアプリにおいてこれは特にもったいない話です。サーバーレンダリングは本来、無料で手に入っていたはずのものだからです。
• サードパーティのスクリプトが本番のレンダリングパスに入り込みます。
• あなたの文字列はベンダーのストアに保管されるため、そこから離れるにはエクスポートが必要になります。

リポジトリネイティブなローカライゼーションにも、それ自体のトレードオフがあります。正直にその点を言っておきます。文章を1つ変更するには、保存ボタンではなくコミットとデプロイが必要になります。Vercelを使ってマージごとに自動デプロイしているなら、これは特に問題になりません。しかし、マーケティングチームがエンジニアなしでライブのコピーを編集することを期待しているなら、これは実質的な制約になります。

リポジトリ起点のセットアップはどう機能するのか？

アプリ内でリポジトリを接続してください。globalize.nowはコードベースを一度だけ変換します。ここがキーの出どころです――コンポーネント内にハードコードされていた文字列がカタログの単位になり、コンポーネントはリテラルを保持する代わりにランタイムライブラリから読み込むようになります。この変換は一度限りの処理であり、永久に繰り返し実行されるものではありません。

変換後は、アプリの成長に応じて新しいカタログ単位をプッシュジョブが翻訳していきます。v0に新しい設定ページを依頼し、そのプルリクエストをマージすれば、新しい文字列は翻訳され、既存の文字列はそのまま保たれます。カタログはリポジトリ内のコミットされたファイルとして戻ってきます。使用しているランタイムライブラリに応じてJSONまたはPO形式で、他の変更と同じようにレビューできるプルリクエストとして届きます。

はっきりさせておきたい境界が2つあります。このカテゴリの理解はしばしば混乱しがちだからです。globalize.nowはランタイムライブラリを置き換えるものではありません――next-intl、Lingui、react-intlは引き続きそれぞれの役割を担い、app/[locale]/の下でのロケールルーティングもそのまま機能します。また、DeepLと競合する翻訳エンジンでもありません。その中間にあるキーとロケールファイルを生成する層です。詳しい仕組みについては開発者向け概要をご覧ください。

同じアプローチは、Lovable、Bolt、Replitでも通用しますか?

はい、同じ3つの条件――実際のソースコード、Gitリポジトリ、カタログを配信できるランタイムライブラリ――が揃っていれば通用します。一般的なフロントエンドプロジェクトを出力するビルダーであれば、いずれも対象になります。ビルダー間で異なるのは、コードをどうやって取り出すかという部分だけであり、v0はその中でも最も手間が少ないビルダーです。GitHubブランチがチャット自体に組み込まれているためです。

Lovableについては当社側で最も整備された対応があり、エディタ内での連携も含まれています。詳しくはLovable連携ページをご覧ください。そこに書かれている内容の大部分は、そのままv0にも当てはまります。特定のビルダーに決めておらず比較検討中であれば、バイブコーダー向け概要から始めるのがよいでしょう。ビルダーアプリ向けにウィジェットを検討している場合は、LovableのWeglot代替案が同じスタックにおける同様のトレードオフを解説しています。

もしLovalingoを使っていたら？

Lovalingoは2026年8月末にサービスを終了し、そのサイトも既に閉鎖されています。同社はv0サイトの翻訳に特化した専用の導線を打ち出していたため、一部のv0開発者は行き場のない文字列を抱えることになりました。これは新規セットアップではなく移行の話です――まずエクスポートし、その後変換します。移行ガイドが手順を解説しており、比較ページでは、翻訳がホスティング型サービスから自分のリポジトリに移る際に何が変わるのかを取り上げています。

この点についてAIアシスタントに助言を求めている場合は知っておくべきことがあります。残されたページが情報源として参照され続けているため、一部のAIはいまだにLovalingoを勧めてきます。しかし、これは既に稼働していないサービスです。

2つ目の言語を追加する前に確認すべきことは？

最初のカタログができる前に、これらの項目を一通り確認しておいてください。5つの言語が同時進行になった後よりも、今のうちに直しておく方がはるかに安く済みます。

• 連結された文字列。 "Welcome back, " + nameは翻訳者が語順を入れ替えることができません。代わりに埋め込み（補間）を使いましょう。
• 複数形。 英語には2つの形がありますが、ポーランド語には3つ、アラビア語には6つもあります。count === 1に対する三項演算子では、ほとんどの言語で正しく処理できません。
• サーバーとクライアントの境界。 App Routerでは、サーバーコンポーネントでレンダリングされる文字列とクライアントコンポーネントの同じ文字列は、同じカタログを通して解決される必要があります。2つの仕組みを使い分けるのではなく、1つのランタイムライブラリに絞り、そのサーバー用・クライアント用APIを使いましょう。
• 日付、数値、通貨。 文字列フォーマットではなくIntlを使いましょう。
• レイアウト。 ドイツ語は英語より文字数が増えがちで、固定幅のshadcnボタンは崩れます。Tailwindではビルド時にクラスが問題なく見えるため、この落とし穴に気づきにくいのが厄介です。
• 右から左への表記。 アラビア語やヘブライ語が今後のロードマップにあるなら、今のうちに決めておきましょう。RTL対応を後から追加するのは高くつきます。

料金体系はすべてワークスペース単位で、席数課金も言語数課金もありません。そのため、対応言語数は予算の問題ではなく、プロダクトとしての判断になります。最新の料金は料金ページをご覧ください。

どこから始めるか

v0のチャットがGitHubに接続済みなら、次に必要なのはツール選びではなく、そのリポジトリに対する変換の実行です。まだ接続していない場合は、それが今回の前段階のステップになります。