Lovableアプリを正しく多言語対応するということは、UIに翻訳ウィジェットを後付けすることではなく、本物の翻訳カタログをリポジトリにコミットし、それを自動的に同期し続けることを意味します。globalize.nowは、ハードコードされた文字列を抽出し、POカタログをスキャフォールドし、Gitへのプッシュごとに更新するAI駆動のローカリゼーションインフラです。手軽なショートカットツールを使えば数分で多言語デモを作れます。しかしその代償として、翻訳はどんどんズレていき、読み込み時にレイアウトが崩れ、検索エンジンが読み取りにくいページが残ります。ここでは、リリース12回目でも通用するセットアップを紹介します。

Lovableアプリにとって「正しい多言語対応」とは、実際のところ何を意味するのでしょうか？

それは、翻訳がコードベースの中にコミットされたカタログとして存在し、初期マークアップの段階で配信され、アプリの変化に合わせて自動的に更新されることを意味します。

本格的な多言語アプリには3つの層があります。i18nランタイムライブラリは、アクティブなロケールに対応した文字列を配信します。翻訳カタログは実際の翻訳内容を保持します。そして、UIが進化してもそれらのカタログを最新の状態に保つ何かが必要です。多くのLovable向けガイドは最初の層について説明していますが、実際に破綻しやすい3番目の層については触れていません。

Lovableは、UIを素早く変更できるように作られています。すべてのプロンプトが、ユーザー向けのテキストを追加、変更、再構成する可能性があります。つまり、多言語対応で問われるべきなのは「アプリを一度どう翻訳するか」ではなく、「プロンプトを送り続ける間、すべてのロケールをどう完全な状態に保ち続けるか」です。これを誤ると、言語が混在したUIを出荷することになり、これは英語圏以外の市場で信頼を失う最も早い方法の一つです。

なぜ翻訳ウィジェットはLovableアプリに不十分なのでしょうか？

それらはページの読み込み後にコンテンツを翻訳するため、見えないメンテナンスの問題を、目に見えるパフォーマンスとSEOの問題に置き換えてしまうからです。

Weglot、Lovalingo、インジェクション型の翻訳ウィジェットといったランタイム翻訳ツールは、数分でインストールでき、ロケールファイルも不要なため、Lovableにおける最も一般的な最初の解決策になりがちです。しかし、そのコストは後になって表面化します。翻訳が切り替わる前に、ユーザーには一瞬だけ元の言語が表示されてしまう、いわゆる未翻訳コンテンツのフラッシュ（FOUC）が発生します。その切り替え時にレイアウトが動いてしまい、GoogleがCore Web Vitalsの一部として測定するCumulative Layout Shift（累積レイアウトシフト）が増加します。

より根深い問題は、検索エンジンからの発見しやすさ（ディスカバラビリティ）です。翻訳後のテキストがクライアントサイドのJavaScript実行後にしか存在しない場合、実質的には1つの実ページとブラウザ側での翻訳しか存在しないことになります。ロケールごとのURLが弱いか、そもそも存在しないため、あなたのスペイン語版やドイツ語版のページは、きちんとローカライズされたサイトのようには検索順位が上がりません。社内ツールや使い捨てのデモであれば、ウィジェットは正しい選択かもしれません。しかし、他の市場で見つけてもらいたいアプリにとっては、間違った土台です。

一度きりのi18nセットアップで、Lovableアプリの翻訳は維持されるのでしょうか？

いいえ。きれいな抽出処理は、次にプロンプトを送るまでは機能しますが、その瞬間からズレが始まります。

Lovable、Cursor、またはClaude Codeに、適切なi18nライブラリを組み込み、すべての文字列を翻訳カタログに取り込むよう依頼することはできます。それは、実行した時点のビルドに対しては確かに機能します。問題は、抽出作業が「完了した」と言える自然な区切りが存在しないことです。次の料金セクション、次の空状態表示、次のボタンラベルなどが、新たなハードコードされた文字列として次々と登場し、あなたのカタログは気づかないうちに後れを取っていきます。

もう一つの手動対応策、つまり変更のたびにLovableにすべてのカタログを更新させるやり方は、規律正しく聞こえますが実際には破綻します。すべての文字列について、すべての言語にわたって、すべてのプロンプトのたびに覚えておかなければなりません。それが4つのロケール分あると考えると、UIの変更が起こるたびに調整作業が発生することになります。その摩擦こそが、Lovableを使う価値そのものであったスピード感を殺してしまうのです。

Lovableアプリを多言語対応にするには、具体的にどのような手順を踏めばよいのでしょうか？

始める前に：Lovableプロジェクトを（チャット入力欄の「+」メニューから「GitHub」→「Connect project」で）GitHubに接続し、globalize.nowのアカウントを作成（無料登録、5ユーロ分の初期クレジット付き、カード登録不要）し、ワークスペースに一度だけスキルを追加できるよう、Lovableでワークスペースのオーナーまたは管理者になっていることを確認してください。

リポジトリを接続し、lovable-i18nスキルを一度だけ追加すれば、あとはプッシュのたびに同期が自動で走ります。以下が全体の流れです。

  1. LovableプロジェクトをGitHubに接続する。 チャット入力欄の「+」メニューから「GitHub」を選び、「Connect project」を実行します。Lovableはプロジェクトを実際のリポジトリに同期させ、これによって初めて持続可能なi18nが可能になります。以下の作業はすべて、ブラックボックスの中ではなく、このリポジトリ上で行われます。
  2. lovable-i18nスキルをワークスペースに追加する。 Lovableは再利用可能なスキルに対応しています。Lovableのワークスペースで「Skills」を開き、「Add」→「Import from GitHub」を選び、https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18nを貼り付けて確認します。これはワークスペースごとに一度だけ必要な作業です（ワークスペースのオーナーまたは管理者権限が必要）。スキルの追加自体は無料で、クレジットも消費しません。CursorやClaude Codeで開発している場合は、接続済みのリポジトリで代わりにnpx skills add globalize-now/globalize-skillsを実行してください。
  3. Lovableにセットアップを依頼する。 LovableのチャットにSet up i18n for my project using the lovable-i18n skill.を貼り付けます。Lovableはあなたのスタック（Vite SPAかTanStack Startか）を検出し、1つだけ質問（ソース言語、対象言語、URLにロケールを含めるかどうか、GitHub Actionを追加するか）をしてくるので、デフォルト設定でよければgoと返信します。すると、Lingui（@lingui/core、@lingui/react、Viteプラグイン）がインストールされ、プロバイダが配線され、ロケールごとに1つのPOカタログがsrc/locales/{locale}/messages.poにスキャフォールドされ、文字列が<Trans>マクロでラップされ、言語切り替えスイッチャーが追加されます。
  4. レビューしてマージする。 Lovableの変更がGitHubに同期されるので、差分をレビューし、デフォルトブランチにマージします。
  5. リポジトリをglobalize.nowに接続する。 サインインし、「Connect repository」を選び、GitHubアプリを認可し、Lovableのリポジトリとデフォルトブランチを選択し、言語（50以上、RTL言語も含む）を選びます。
  6. Lovableでの開発を続ける。 プッシュのたびに、globalize.nowは更新されたPOカタログを含む翻訳PRを開きます。それをマージするだけです。あなたのアプリは翻訳済みの状態で出荷されます。リリースの合間、あなたに必要な作業は他に何もありません。

重要なポイントは、手順3から6にあります。セットアップは一度きりで済み、その後の継続的な同期にはコマンドもダッシュボードもレビューキューも必要ありません。統合の全手順については、Lovable統合ページをご覧ください。

Lovableアプリではどのi18nライブラリを使うべきでしょうか？

lovable-i18nスキルはLinguiをインストールします。これは、LovableアプリがVite SPAまたはTanStack StartベースのReactプロジェクトであり、Linguiがそのスタックに適しているからです。

このスキルは@lingui/core、@lingui/react、Viteプラグインを配線し、src/locales/{locale}/messages.poにPOカタログをスキャフォールドし、文字列を<Trans>マクロでラップします。react-i18nextやnext-intlは、それぞれ他のReactやNext.jsのセットアップに適した選択肢ですが、このスキルではインストールされません。

独自の翻訳コンテキストを一から作ったり、言語マップをハードコードしたりするのは避けましょう。初日は身軽に感じられても、30日目には結局取り除くことになるものです。globalize.nowの開発者向けページでは、抽出処理が各ライブラリにどう対応しているかを解説しているので、手探りで選ぶ必要はありません。

Lovableへのプロンプトを送り続けながら、翻訳を同期し続けるにはどうすればよいでしょうか？

同期をGitのワークフローに組み込むことで、うっかり忘れることをなくします。

手動でのi18n運用がうまくいかない理由は、速いビルドサイクルの中で人が作業を覚えていることに依存してしまうからです。インフラはそのループから人の手を取り除きます。差分検出と翻訳の処理がプッシュのたびに実行される場合、Lovableのプロンプトによって作られた新しい文字列は、そのプッシュの時点で捕捉され、翻訳され、ブランチがマージされる前にPRとして返されます。POカタログが気づかないうちに遅れをとったままリリースされることはありません。スキップできる手動の工程がそもそも存在しないからです。

これが、単なる「セットアップ」と「インフラ」の違いです。セットアップとは、一度到達すればよい状態です。インフラとは、周囲のすべてが変化する中でも保たれ続ける性質のことです。Lovableで編集を続けるアプリにとって求められているのは、状態ではなく、この性質のほうです。AIによるアプリ構築のワークフローについてはバイブコーダー向けページで詳しく解説しています。また、ツール選定で迷っている場合は、比較ガイドで各ツールの位置づけを確認できます。

Lovableアプリを多言語対応にすることは、始めるのは簡単ですが、維持するのは大変です。globalize.nowはその「維持」の部分を担います。Lovableでは、「Open Skills」から「Add」、「Import from GitHub」と進み、globalize-now/lovable-i18nを指定してlovable-i18nスキルを追加してください。CursorやClaude Codeではnpx skills add globalize-now/globalize-skillsを実行してください。詳しくはLovable統合ガイドまたはglobalize.nowをご覧ください。

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

globalize.nowを無料で試す