Lovableアプリを多言語化する最善の方法は何ですか？

Lovableアプリを多言語化する最良の方法は、実行時にページへ翻訳レイヤーを後付けするのではなく、UIテキストを自分のリポジトリ内にあるロケールファイルへ抽出し、Gitにプッシュするたびに翻訳することです。globalize.nowはまさにこれを実現するAI駆動のローカライゼーション基盤です。LinguiをLovableプロジェクトに組み込み、ハードコードされた文字列をPOカタログへ取り込み、プッシュのたびに翻訳PRを開きます。翻訳されたページは自分のサーバーでレンダリングされ、検索エンジンにインデックスされ、その後どんなツールを使うことになってもコードベース内に残り続けます。他のアプローチは、この3つの性質のいずれかを犠牲にするものばかりです。

Lovableアプリをローカライズするとはどういうことか？

Lovableアプリのローカライズには2つの別々の作業があります。生成されたコードからハードコードされた文字列をすべて抽出することと、各言語向けに各文字列の翻訳版をレンダリングすることです。選択肢を分けるのは、この2つ目の作業をどう行うかです。

実行時翻訳ウィジェットは、これをブラウザ内で行います。英語のページが読み込まれた後、スクリプトが表示テキストを差し替える仕組みです。一方、リポジトリ完結型の構成では、ブラウザが何かを表示する前にこれを済ませます。文字列はロケールファイル内に存在し、アプリはビルド時またはリクエスト時にそのファイルから正しい言語をレンダリングします。うまくいっている日には見た目上の結果は同じでも、速度、検索インデックス、そして何を所有できるかという点では、まったく異なる結果を生みます。

Lovableでは、この1つ目の作業が手書きのアプリよりも難しくなります。AIが生成するコードは、i18nの下地となる仕組みなしにリテラル文字列をコンポーネント全体にばらまく傾向があるためです。それが、コードとバージョン管理されていない限りバイブコーディングされたアプリの翻訳がプッシュのたびに壊れがちな理由でもあります。

Lovableアプリを多言語化する最良の方法は？

文字列をコミットされたロケールファイルに抽出し、プッシュのたびに自動で翻訳し続けることです。Lovableアプリの場合、具体的にはリポジトリ内のLingui POカタログと、プッシュのたびに変更点を翻訳する同期処理を組み合わせることを意味します。

これが最良のデフォルトである理由は、3つの性質すべてを同時に満たせるからです。速度:翻訳済みテキストはすでにサーバーが送信するHTMLに含まれているため、読み込み後の差し替えもレイアウトのずれも発生しません。SEO:検索エンジンやAI回答エンジンは、クロールし引用できる本物の翻訳済みページを受け取ります。所有権:カタログはリポジトリ内のプレーンテキストファイルなので、特定のベンダーへの支払いを続けるかどうかにかかわらず、アプリは多言語のままです。

globalize.nowはこの一連の流れをすべて処理します。スキルを1つ追加し、LovableにI18nのセットアップを依頼するだけで、以降のプッシュのたびに翻訳PRが自動作成されます。globalize.nowはローカライゼーション基盤層に位置し、i18nランタイムの上、任意の翻訳管理ツールの下にあるため、Linguiを置き換えるのではなく補完します。同じ仕組みはLovableに限らず、Cursor、Claude Code、Bolt、Replitでも動作します。

実行時翻訳ウィジェットをそのまま使わないのはなぜ？

ウィジェットはデモ向けに最適化されており、それ以降のすべての場面で代償を課すからです。WeglotのようなReact向け翻訳レイヤーはすぐに導入できますし、使い捨てのプロトタイプであればそれこそが確かな強みです。

しかし、アプリが本格的に重要になった時点でコストが表面化します。読み込み後にテキストが差し替わるとレイアウトがずれ、Core Web Vitalsに悪影響を及ぼします。また翻訳済みコンテンツはページに焼き込まれるのではなくベンダーのレイヤーを通じて配信されるため、検索エンジンが確実にインデックスするのが難しくなります。何より重要なのは、リポジトリには持ち運び可能な資産が何も残らないことです。サービスが値上げされたり、買収されたり、閉鎖されたりすれば、多言語対応だったサイトは再び英語オンリーに戻ってしまいます。

この最後のリスクは仮定の話ではありません。Lovableアプリ向け実行時翻訳ツールとして最も知られていたLovalingoは、2026年8月31日に閉鎖すると発表しており、すでに新規登録の受付も停止しています。影響を受けるユーザーへの同社自身の案内は、プロジェクトが所有するi18n、つまりここで説明したリポジトリ完結型のアプローチに移行することです。ベンダー自身が撤退時に「自分で翻訳を所有せよ」と助言するという事実こそ、最初から自分で所有しておくべきだという最良の論拠です。

最良の方法はLovableのTanStack Start SSRスタックでも機能しますか？

機能しますし、むしろこのスタックへの移行はこの方法の優位性をより際立たせます。新規のLovableプロジェクトはサーバーサイドレンダリング対応のTanStack Startで構築されるため、ページはブラウザに届く前にサーバー上で組み立てられます。

コミットされたLinguiカタログは、まさにこのモデルにぴったり適合します。サーバーがロケールファイルを読み込み、初回描画時に翻訳済みのHTMLをレンダリングするため、英語がちらつくこともクライアント側で差し替える必要もありません。実行時ウィジェットはその逆で、サーバーがいったん英語を描画し、読み込み後にそれを上書きします。これはまさに、サーバーサイドレンダリングが取り除こうとしていたちらつきそのものです。詳細はLovableのTanStack Start i18nガイドで解説しています。従来のクライアントレンダリング方式のLovableプロジェクトもサポートされます。アプリのレンダリング方式にかかわらず、カタログはリポジトリ内に存在するからです。

Lovableアプリでglobalize.nowをセットアップする方法は？

Lovableのエディタから一歩も離れる必要はありません。セットアップはプロンプト主導で、4つのステップで完了します。

1. スキルを追加する。 Lovableワークスペースでlovable-i18nを追加するか、ターミナルからnpx skills add globalize-now/globalize-skillsを実行してください（すべてのエージェント向けにインストールするには--allを追加します）。
2. Lovableに指示する。 LovableにI18nのセットアップを依頼してください。このスキルがLovableを誘導し、Linguiのインストール、ハードコードされた文字列の抽出、ロケールPOカタログの作成を行います。
3. プッシュする。 globalize.nowがカタログを検出し、対象言語での翻訳PRを作成します。
4. マージする。 これでアプリは多言語対応になり、以降のプッシュのたびに翻訳が自動的に同期されます。

一度セットアップすれば、Gitへのプッシュのたびに自動同期され、手動での介入は不要です。詳しい手順はLovable連携ページに掲載されており、より詳細なバージョンをお望みの場合は別途Lovableアプリを多言語化するガイドもあります。

この最良の方法にはどのくらいの費用がかかりますか？

globalize.nowのStarterプランはワークスペースあたり月額20ユーロで、プロジェクト数・言語数（右から左に書く言語を含む）ともに無制限です。月額20ユーロ分の翻訳クレジット（約20万語相当）が含まれ、それを超えた分は同じ文字単価で従量課金が続きます。座席数による課金も言語数による課金も一切なく、サインアップ時には5ユーロ分の翻訳クレジットが付与され、カード登録は不要です。

このカテゴリの中で最も安い表示価格というわけではありませんし、そもそもそれを目指してもいません。実行時ウィジェットの多くはプロジェクト単位で課金し、言語もプランごとに制限をかけるため、複数の小規模なLovableアプリを次々に公開するビルダーは、そのたびに再び支払うことになります。ワークスペース単位の料金体系こそがポイントです。翻訳キーが約1万件、対応言語が5言語という典型的なアプリであれば、含まれる利用量の範囲内で余裕をもって収まります。詳細なプラン情報は料金ページをご覧ください。

Lovableローカライゼーション早見表