Lovableで多言語対応を進めると、実際には何が起きるのか
あなたがLovableに新しい料金セクションの追加を指示すると、Lovableはコンポーネントを生成し、組み込み、デプロイします。英語版のUIは更新されます。しかしmessages.poカタログは以前のままです。フランス語ユーザーには古いテキストが表示され、ドイツ語ユーザーには英語が表示されます。実際のユーザーから報告が来るまで、誰も気づきません。
これはLovableのバグではなく、構造的なミスマッチです。Lovableは高速なUI実装を最適化していますが、i18nはあらゆる変更のたびに、すべてのロケールカタログにわたってユーザー向け文字列を追跡することを要求します。この2つの目標は本質的に相反しているのです。
文字列の抽出作業は一度きりでは終わらない、継続的な問題です。Lovableが実行するプロンプトのたびに新しい文字列が生まれ、あらゆるイテレーションが既存のコンテンツを変化させます。「抽出はこれで完了」と言える自然な区切りは存在しません。
よくある対策が根本解決にならない理由
一度きりの抽出作業で解決できるのか？
できません。Lovableでの初期構築後に文字列抽出を一度実行し、クリーンなPOカタログを作ることはできます。しかしそれが通用するのは次のプロンプトを実行するまでです。それ以降は、何十ものコンポーネントと何十ものカタログにまたがる差分を手作業で照合することになります。スペイン語のmessages.poカタログで文字列が一つでも漏れれば、翻訳済みページの真ん中に英語のテキストが混在する — いわゆる「混在言語UI」が発生し、これはユーザーの信頼を最も損ないやすい体験の一つです。
ランタイム翻訳ツールで十分なのか？
WeglotのようなランタイムトランスレーターやJavaScriptで挿入する翻訳ウィジェットは、まったく別の問題を解決するものです。これらはページ読み込み後にコンテンツを翻訳するため、翻訳が反映されるまでの一瞬、ユーザーには元言語の表示が見えてしまいます。ユーザー体験の悪化に加えて、これは測定可能なレイアウトシフト（CLS）を引き起こし、GoogleがランキングにCore Web Vitalsとして利用する指標に悪影響を及ぼします。目に見えない保守の問題を、目に見えるパフォーマンスの問題にすり替えているだけなのです。
Lovableにロケールファイルの更新をプロンプトで指示すればいいのでは？
確かにLovableは、指示すればPOカタログに書き込むことができます。しかし問題は、すべての文字列について、すべてのプロンプトで、すべてのロケールにわたって、毎回それを指示し忘れないようにする必要があるという点です。言語を追加するたびに、この認知的負荷は積み重なっていきます。4つのロケールがあれば、UIに関するプロンプト一つひとつが4段階の調整作業に変わってしまいます。これはまさに、Lovableの価値である開発速度を殺してしまう類の摩擦です。
Lovableのi18nサイクルは実際にどう破綻していくのか
このパターンは驚くほど一貫しており、はっきりとした型を描きます。
- 初期セットアップ — 多言語対応を追加します。うまく動きます。すべて翻訳済みです。気分は上々です。
- 最初の数回のリリース — POカタログを手作業で更新することを忘れずにいられます。面倒ですが、まだ何とかなります。
- 開発速度が上がる段階 — リリースのペースが速くなります。POカタログの更新が追いつかなくなり始めます。「あとで追いつけばいい」と自分に言い聞かせます。
- 本番環境での言語混在 — 英語圏以外のユーザーが、部分的に英語のままの画面を目にし始めます。サポートチケットが届き始めます。1回分のリリースサイクルを丸ごと、文字列探しだけに費やすことになります。
- リファクタリング税 — 英語オンリー版には存在しなかった隠れたi18nコストが、新機能ごとに発生するようになります。リリース速度は落ちていきます。
このリファクタリング税こそ、「Lovableで多言語対応する方法」的なガイドが決して語らない部分です。ガイドが示すのは初期セットアップだけで、12回目のリリースで何が起きるかは示してくれません。
解決策 — i18nをGitのプッシュサイクルに組み込む
アーキテクチャとして正しい答えは、手作業のステップを完全に排除することです。プッシュのたびに翻訳が自動的に更新されれば、保守の問題は消滅します。抽出処理が自動実行されるなら、それを実行し忘れることもありません。
ワークフローは次のようになります。
- LovableプロジェクトをGitHubに接続する。 チャット入力欄の「+」メニューからGitHubを選び、続いて「Connect project」を選択します。
- lovable-i18nスキルをワークスペースに追加する。 Lovableワークスペースの「Skills」を開き、「Add」、次に「Import from GitHub」を選び、
https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18nを貼り付けて確定します。これはワークスペースごとに一度だけ行います（実行にはワークスペースのオーナーまたは管理者権限が必要です）。 - Lovableにセットアップを依頼する。 Lovableのチャットに
Set up i18n for my project using the lovable-i18n skill.を貼り付けます。Lovableはあなたのスタック（Vite SPAかTanStack Start）を検出し、一つだけ質問（ソース言語、対象言語、URLにロケールを含めるかどうか、GitHub Actionを追加するか）してくるので、デフォルト設定でよければgoと返信します。すると、Linguiがインストールされ、src/locales/{locale}/messages.poにPOカタログの雛形が作成され、文字列が<Trans>マクロでラップされ、言語切り替えUIも追加されます。 - レビューしてマージする。 Lovableの変更がGitHubに同期されるので、差分をレビューし、デフォルトブランチにマージします。
- リポジトリをglobalize.nowに接続する。 サインインし、リポジトリを接続、GitHubアプリを承認し、Lovableのリポジトリとデフォルトブランチを選択、対応言語（50以上、RTL言語も含む）を選びます。
- Lovableでの開発を続ける。 プッシュのたびにglobalize.nowが起動し、更新されたPOカタログを含む翻訳用プルリクエストを開きます。それをマージすれば、アプリは翻訳済みの状態でリリースされます。
重要なポイント — 接続と同期のステップは、初期セットアップ後は一切あなたの手を必要としません。コマンドを実行することも、ダッシュボードを確認することも、翻訳キューを承認することもありません。Lovableが生成したコンポーネント内の新しい文字列は、プッシュ時に検出・翻訳され、ブランチをマージし終える前にプルリクエストとして戻ってきます。段階的なセットアップ手順はLovable連携ページに掲載されています。
これがLovableでの開発フローに意味すること
Lovableの利用をやめる必要はありません。このアーキテクチャは、あなたのUIが変化し続けることを前提に設計されています — それこそが本来の狙いです。Lovableがlovable-i18nスキルを使ってUIを生成し、globalize.nowが同期を担当します。
i18nが必要な場面ではLovableがコンポーネントを生成し、スキルを適用します。globalize.nowはプッシュのたびに出力を監視します。どれだけ速くリリースしても、ユーザーには常に完全に翻訳されたUIが届きます。
globalize.nowのvibe codersページでは、AIで構築されたアプリ向けにこのセットアップがどう機能するか、より詳しく解説しています。すでにLovableで構築したNext.jsやReactアプリを運用している場合は、開発者向けページに技術的な連携手順が掲載されています。
すでに複数のLovableプロジェクトを管理しているチームにとって、globalize.nowのワークスペース単位の料金体系は、言語数や文字列抽出数に応じた課金ではないことを意味します — アプリが成長しても、同期にかかるコストは一定のままです。
保守の負担は現実に存在し、放っておけば積み重なっていきます。Lovableでlovable-i18nスキルを追加しましょう（ワークスペースで「Skills」を開き、「Add」、続いて「Import from GitHub」）。詳しくはLovable連携ガイドまたはglobalize.nowをご覧ください。
globalize.nowは、ハードコードされたアプリ内テキストを翻訳可能なロケールファイルに変換し、リリースのたびに自動で最新の状態を保ちます。
globalize.nowを無料で試す