どの言語を追加してもLovableアプリが英語のまま表示される場合、原因はスタックの変更にあります。2026年5月中旬以降、新しいLovableプロジェクトは従来のReact + Vite製シングルページアプリではなく、サーバーサイドレンダリング対応のTanStack Startをベースに構築されるようになりました。globalize.nowはAIを活用したローカライゼーション基盤で、文字列をコミット済みのLingui POカタログとして抽出することでこの新しいスタックに対応し、ブラウザで言語を差し替えるのではなく、サーバー側で正しい言語をレンダリングできるようにします。解決策は別のウィジェットを追加することではありません。翻訳をリポジトリの中に移すことで、サーバーがそれをレンダリングし、検索エンジンがそれをインデックスできるようにすることです。

なぜLovableアプリのローカライズが急に難しくなったのか？

従来のアドバイスの前提となる状況が変わってしまったからです。「Lovableアプリを翻訳する」ためのガイドの多くは、クライアントレンダリングのシングルページアプリを前提としており、ウィジェットが読み込み後にDOMを書き換えても誰も気づかないという想定に基づいています。しかし新しいプロジェクトではその前提はもはや成り立ちません。

Lovableは新しいプロジェクトをSSR対応のTanStack Startに切り替え、クローラーが最初のリクエストで完全にレンダリング済みのHTMLを受け取れるようにしました。JavaScriptの実行は不要です。これはSEO上大きな利点ですが、翻訳の仕組みを根本から逆転させるものでもあります。最初のレスポンスがすでにレンダリングされている以上、あとからブラウザ側で翻訳しても手遅れなのです。

この数ヶ月のうちにアプリを構築し、ランタイム型の翻訳ウィジェットを組み込んだ方は、まさにその症状を目にしているはずです。一瞬英語が表示され、その後翻訳に切り替わるというものです。globalize.nowのLovable連携は、まさにこの問題を本来あるべき層で解決するために存在します。

LovableのTanStack Startへの切り替えで実際に何が変わったのか？

レンダリングの仕組みがクライアントサイドからサーバーサイドへと変わりました。以前のLovableはReactとViteで構築されたシングルページアプリを生成し、静的ファイルとしてデプロイし、すべてブラウザ側でレンダリングしていました。現在はTanStack Startがベースとなっており、これはルートごとにSSR・SSG・CSRを使い分けられるフルスタックReactフレームワークで、コンポーネントと同じ場所にサーバー関数を配置できます。

ローカライゼーションの観点で重要な点は3つあります。第一に、HTMLはブラウザに届く前にサーバー側で生成されるため、言語はサーバー側で決定されます。第二に、ルーティングは今やロケールごとの実際のURLをサポートしています。第三に、言語選択をブラウザ専用APIに依存させている仕組みは、サーバーがすでに言語を確定させた後に動作することになります。

この3番目のポイントこそ、多くの実装が壊れている原因です。localStorageに保存されたロケールはサーバーからは見えないため、サーバーはデフォルト言語をレンダリングし、少し遅れてクライアント側がそれを修正することになります。

なぜランタイム型の翻訳ウィジェットはSSRで一瞬英語を表示してしまうのか？

サーバーがすでに英語を送信した後で翻訳を行っているからです。新しいスタックでは処理の流れはこうなります。サーバーがデフォルト言語でHTMLをレンダリングし、ブラウザがそれを描画し、その後ウィジェットのJavaScriptが読み込まれてテキストを書き換えます。描画と書き換えの間のこのギャップが一瞬の英語表示の原因であり、これはもはや調整の問題ではなく、構造的な問題です。

SEOへの悪影響は、この一瞬の表示よりも深刻です。クローラーは最初のレスポンスを読み取ったら先に進みます。翻訳されたテキストがクライアント側のJavaScript実行後にしか現れない場合、クローラーはすべてのロケールに対して英語をインデックスしてしまい、ランク付けされる言語別ページが一切存在しないことになります。Lovableがインデックス可能なHTMLを得るためにSSRへ移行した本来の目的が、ブラウザ内での翻訳によって台無しになってしまうのです。

コミット済みのカタログは、そもそもこの問題が起きない設計になっています。翻訳文字列がリポジトリ内に存在する場合、TanStack Startはリクエストされたロケールをサーバー側でレンダリングするため、最初のレスポンスからすでに正しい内容になっています。これは、コードベースに組み込まれたインフラと、その上で動くだけのウィジェットとの間にある本質的な違いであり、Weglotのようなランタイムツールが新しいスタックよりも旧来のSPAモデルに適している理由でもあります。同期の問題についてより詳しく知りたい方は、プッシュのたびにLovableの翻訳が壊れる理由をご覧ください。

TanStack Start上のLovableアプリを多言語化するにはどうすればよいか？

翻訳をサーバー側に移し、カタログをリポジトリ内で管理することです。具体的には、新しいスタックでは4つのステップで実現でき、ロケールファイルを手作業で編集する必要は一切ありません。

  1. lovable-i18nスキルを追加し、Lovableにi18nを組み込ませる。 Lovableのワークスペースでlovable-i18nスキルを追加し、Lovableに国際化のセットアップを指示します。これによりLinguiがインストールされ、ハードコードされたUI文字列がメッセージカタログに抽出され、プロバイダーが設定されます。エディター外でも同じセットアップをnpx skills add globalize-now/globalize-skillsでインストールできます（すべてのエージェント向けにインストールするには--allを追加します）。
  2. TanStackのオプションパスパラメータでロケールをルーティングする。 TanStack Routerはオプションのパスパラメータに{-$locale}を使用します。そのため/{-$locale}/aboutと定義されたルートは、デフォルト言語では/aboutに、スペイン語では/es/aboutにマッチします。これにより、ブラウザ内でテキストが書き換わる単一URLではなく、各言語ごとにクロール可能な固有のURLを持つことができます。
  3. ロケールはlocalStorageではなくサーバー側で解決する。 アクティブな言語はcookieに保存し、SSRハンドラーがリクエストから読み取れるようにします。Linguiでは、サーバーはルーターを作成する前にsetupLocaleFromRequest()を呼び出し、クライアントのハイドレーションはレンダリング前にサーバー側から渡されたロケールでdynamicActivate()を呼び出します。両側で同じ値を使うことで、ハイドレーションの不一致や一瞬の表示切り替えを防げます。
  4. カタログをリポジトリ内で管理し、プッシュのたびに同期する。 POカタログはベンダーのランタイムではなく、コミットされたファイルです。Lovableでの開発を続ける中で新しい文字列が現れるたびに、それらを再度抽出・翻訳する必要があり、これこそ手作業では管理が崩れやすい部分です。globalize.nowはこの作業を自動的に行ってくれるので、手動でのエクスポート作業なしにカタログを最新の状態に保てます。
// server: resolve locale before the router exists
const locale = getLocaleFromCookie(request) ?? "en";
await setupLocaleFromRequest(locale);

// client: activate the SAME locale before first render
await dynamicActivate(serverLocale);

これは実際に手順化された、成果物がコミットされる正式なプロセスであるため、通常のバージョン管理されたコードと同じように扱えます。プルリクエストでレビューでき、差分を確認でき、将来Lovableから移行する場合でも持ち運び可能です。

TanStack Startのi18nスタックの中でglobalize.nowはどこに位置するのか？

ランタイムライブラリの一段下、翻訳エンジンの一段上に位置します。TanStack StartとLinguiは実行時に翻訳を提供する役割を担い、DeepLやLLMは翻訳そのものを生成する役割を担います。globalize.nowはその中間にあるインフラです。キーとPOカタログを生成し、それらの同期を維持することで、ランタイム側には常に正しくレンダリングできる内容が用意されている状態を保ちます。

Lovableで開発する立場から見た実際的な効果は、ロケールファイルの世話をしなくて済むようになることです。スキルをインストールし、一度Lovableに指示を出せば、それ以降のプッシュのたびに新しい文字列が抽出され、カタログが埋められ、その変更が通常のプルリクエストとして開かれます。ダッシュボードを行き来する必要も、再エクスポートも不要で、アプリの表示内容とカタログの内容がずれることもありません。

料金プランは1つだけです。ワークスペースごとに月額20ユーロで、月20ユーロ分の翻訳クレジット（約20万語相当）が含まれ、それを超えた分は同じ文字単価でのトークン従量課金となります。シート数課金も言語数課金もなく、サインアップ時には5ユーロ分のクレジットが付与され、クレジットカードの登録も不要です。一般的なLovableアプリが5言語に展開する場合でも、この範囲内で十分に収まります。開発者向けの詳細を知りたい方は開発者向けglobalize.nowやバイブコーダー向けのページを、スタック全体について知りたい方はプロダクト概要をご覧ください。

Lovableアプリが英語のままなのは、翻訳が本来あるべきでない場所、つまりサーバーがすでに言語を確定させた後のブラウザで行われているからです。翻訳をリポジトリの中に移せば、サーバーが最初のリクエストから正しい言語をレンダリングできるようになります。globalize.nowが抽出と同期を担ってくれるので、一度セットアップすれば、プッシュのたびに自動的に最新の状態が保たれます。

globalize.nowは、ハードコードされたアプリ内テキストを翻訳可能なロケールファイルに変換し、リリースのたびに自動で最新の状態を保ちます。

globalize.nowを無料で試す