Lovalingoは2026年8月31日にサービスを終了します。アプリの翻訳をランタイムサービス経由で行っている以上、移行しない限り、あなたの多言語サイトもサービス終了とともに機能を停止します。その解決策として、Lovalingoの終了ガイダンス自体が推奨しているのが「プロジェクト所有型」の国際化対応です。globalize.nowは、Lovableアプリ向けにまさにそれを実現するAI駆動のローカライゼーション基盤です。UI文字列をLingui POカタログとして抽出してリポジトリにコミットし、Gitへのプッシュごとに翻訳PRを同期させます。だからこそ、どのベンダーのサービス終了があっても——今回のケースも含めて——言語対応が失われることはありません。そして、この移行はあなたが望んで選んだものではないため、Lovalingoからの移行者には最初の3か月分の利用料を無料でご提供しています。以下では、何が壊れるのか、何を保存すべきか、移行の手順そのもの、そして多くのガイドが省略している削除手順までを解説します。

Lovalingoは何を発表したのか？

Lovalingoは2026年8月31日23:59（中央欧州時間）にサービスを終了することを発表し、新規プロジェクトおよび新規契約の受付はすでに停止しています。この告知はlovalingo.comのサイト全体に表示されるバナーと、サービス終了専用ページで案内されています。運営元はTempo AI LLCです。

移行手順は整理されています。有効な契約に対する課金は停止され、サービスへのアクセスは終了日まで継続します。また、プロジェクト設定、ルート、翻訳バンドル、上書き設定を含む保存用エクスポートが準備されています。移行サポートは[email protected]まで行われます。

特に重要な点が2つあります。まず、後継サービスは指定されておらず、ユーザーが別のベンダーへそのまま引き継がれるわけではありません。次に、公式の移行ガイダンスでは、Lovalingoを削除する前に、それと並行してプロジェクト所有型の国際化対応を実装するよう案内しています。これは具体的なアーキテクチャ上の指示であり、ランタイム翻訳ウィジェットを別のランタイム翻訳ウィジェットに置き換えるという選択肢は排除されているということです。

Lovalingoが終了すると、あなたのアプリはどうなるのか？

Your app reverts to its source language. Lovalingo works as a runtime layer: you install @lovalingo/lovalingo, wrap your app in its provider, and translations are served through their infrastructure. No locale files exist in your repository. When the service stops responding, your build still compiles and deploys, but every page renders untranslated.

さらに深刻な障害パターンもあります。Lovalingoが推奨するサイトマップ設定では、LovalingoのCDNからサイトマップをダウンロードするプレビルドスクリプトが追加され、そのダウンロードが失敗するとビルド自体を失敗させる仕組みになっています。CDNがオフラインになった時点で、そのスクリプトを使っているプロジェクトはビルドが完全にできなくなります。package.json内にcdn.lovalingo.comから取得するprebuildのエントリがあるか確認してください。もしあれば、その削除は単なる後片付けではなく、デプロイを継続するために欠かせない作業です。

より緩やかに効いてくるダメージがSEOです。LovalingoはロケールURLとhreflangタグをランタイムで生成していました。サービス終了後、それらの翻訳済みページは存在しなくなり、検索エンジンはクロールできなくなったページをインデックスから除外します。私たちは6月に公開したLovalingoとWeglot、globalize.nowの比較記事で、この構造的な問題を指摘していました。どのランタイム翻訳サービスを使っていても、多言語サイトはベンダーが存続している間だけ存在するものだ、と。当時はまだ仮説の話でしたが、今は具体的な日付が付いています。

2026年8月31日までに何をすべきか？

今すぐデータを確保し、移行先を構築している間もLovalingoは動かし続けましょう。8月下旬まで待ってはいけません——[email protected]のサポート窓口は最終週に最も混み合いますし、本番環境での確認が失敗した場合に備えて余裕を持っておく必要があります。目安としては、8月24日までに移行を完了させ、1週間の余裕を持たせるのが健全な目標です。

Lovalingoの終了案内ページ自体が、正しい手順として次の流れを示しています。

  1. プロジェクトのエクスポートと現在のソースリポジトリを保存してください。エクスポートがまだ届いていない場合は、今日中に[email protected]に依頼しましょう。
  2. 現在の言語リストとロケールURL構成を確認しておいてください。これらはLovalingoProviderの設定とエクスポート内に記載されています。両方を移行先で再現します。
  3. Lovalingoと並行して、プロジェクト所有型の国際化対応を実装してください。この段階では何も削除しないでください。
  4. 移行先で、直接のロケールURL、ページのリロード、キー欠落時の挙動、フォールバックの動作をテストしてください。
  5. 移行先が本番環境の確認をすべて通過した後にのみ、Lovalingoを削除してください（削除手順の全体は下記を参照）。

手順3が求めている内容に注目してください。「プロジェクト所有」とは、翻訳が別ベンダーのランタイム内ではなく、自分たちが管理するファイルとしてリポジトリ内に存在することを意味します。Lovalingoから別のランタイムウィジェットへ移行しただけでは、次にそのサービスが終了した時にまた同じ移行作業をやり直すことになります。Lovalingo比較ページでは、この2つのアーキテクチャを並べて詳しく解説しています。

LovalingoからGlobalize.nowへの移行方法は？

一般的なLovableアプリの場合、この移行は作業時間1回分で済み、作り直しは不要です。しかも、Lovableエディタから離れる必要もありません。

  1. スキルを追加する。 Lovableのワークスペースでlovable-i18nを追加するか、ターミナルから次を実行します：npx skills add globalize-now/globalize-skills。詳しい流れはLovable統合ページに記載されています。
  2. Lovableにi18nのセットアップを指示する。 「lovable-i18nスキルを使ってこのアプリのi18nをセットアップして」といった簡単な指示で十分です。このスキルがLinguiを組み込み、ハードコードされた文字列を抽出し、リポジトリにコミットされる普通のファイルであるPOカタログを作成します。
  3. Lovalingoの設定と一致させる。 Lovalingoで使用していたのと同じ対象言語と同じロケールパス構成（/de/...、/fr/...）を設定し、既にインデックスされているURLをそのまま生かします。パスの変更が必要な場合は301リダイレクトを追加してください。
  4. プッシュする。 globalize.nowがカタログを検知し、対象言語をカバーする翻訳PRを開きます。マージすれば、今度はリポジトリ内のファイルとして言語対応が復活します。
  5. Lovalingoを導入したままテストする。 公式チェックリストに従い、直接のロケールURL、リロード、キー欠落時の挙動、フォールバック、ロケール別メタデータを確認しましょう。新しいLovableプロジェクトはSSR対応のTanStack Startで構築されるため、ロケールルートはサーバーレンダリングされたHTMLとして届きます。従来のクライアントレンダリング型Reactプロジェクトでも問題ありません。カタログはレンダリング方式に関わらずリポジトリ内に存在するためです。

実際にやる前に、まず導入の様子を見てみたい方へ。スキルの追加から翻訳PRのマージまで、全体の流れはわずか3分です。

How to Make Your Lovable App Multilingual (i18n in Minutes)

それ以降は、一度セットアップするだけで、Gitへのプッシュごとに自動同期され、手動での作業は不要になります。料金はワークスペースごとに月20ユーロで、プロジェクト数・言語数は無制限、月20ユーロ分の翻訳クレジット（約20万語相当）が含まれ、登録時にはカード登録不要で5ユーロ分のクレジットが付与されます。

Lovalingoからの移行者にはさらに特別なオファーがあります。最初の3か月間の利用料が無料になります。この移行はあなたが選んだものではないため、最初の期間は費用がかからないようにしています。利用するには、登録後にLovalingoのプロジェクトについて触れたメールを[email protected]宛てに送ってください。ワークスペースに適用いたします。

Lovalingoをきれいに削除する方法は？

Lovalingoはルーターやビルドプロセスに深く組み込まれているため、削除はパッケージのアンインストールだけでは済みません。移行先が正常にテストを通過したら、このチェックリストに沿って作業を進めてください。各項目は、該当する設定を使っている場合のみ対象となります。

  1. ルーターを元に戻す。 パスモードでは、LovalingoのLangRouterがBrowserRouterを置き換えています。削除時には元のルーターに戻さないと、アプリが正しく表示されません。
  2. 内部リンクを修正する。 コード内でLangLinkやuseLangNavigateといったLovalingoのヘルパー関数を使用している場合は、ルーター自体のLinkやナビゲーション機能に置き換えてください。パッケージを削除した瞬間に、これらのインポートは動作しなくなります。
  3. プロバイダーとパッケージを削除する。 アプリのシェルからLovalingoProvider（とLangRouter）を削除し、その後@lovalingo/lovalingoをアンインストールしてください。
  4. マニフェストファイルを削除する。 publicディレクトリ、またはそれを生成しているエンドポイントから/.well-known/lovalingo.jsonを削除してください。
  5. サイトマップのプレビルド手順を削除する。 package.json内にscripts/fetch-lovalingo-sitemap.mjsとprebuildのエントリが存在する場合は、両方削除してください。これはCDNが停止した瞬間にビルドを失敗させるスクリプトです。代わりに自前のサイトマップを配信しましょう。ロケールルートがコミットされていれば、コードベースから生成できます。
  6. 再デプロイして再送信する。 クリーンなビルドをデプロイし、ロケールURLが翻訳済みで表示されることを確認したら、Google Search Consoleでサイトマップを再送信し、再構築されたページを再クロールさせましょう。

わずか10分の後片付けで、終了を控えたサービスへのランタイム依存が完全になくなります。

既存のLovalingoの翻訳データはそのまま使えますか？

エクスポートは保存しておいてください。ただし、そのままインポートして使うためのものではなく、参考資料として役立てるものです。globalize.nowはソース文字列から翻訳を生成し、その結果をリポジトリにコミットするため、プッシュ1回で言語対応が復活します。特定のフレーズや製品用語について、Lovalingoで手動調整した上書き設定があった場合は、それらをglobalize.nowのグロッサリーや手動編集に反映させることで、こだわった訳文を移行後も維持できます。

正直に言うと、これはベンダー独自のバンドル形式をそのまま移植するのではなく、翻訳を再生成する作業です。その代わりに得られるのは、これがこの種の移行の最後になるという保証です。出力されるのはリポジトリ内のPOファイルであり、そもそも定義上、どこにでも持ち出せる形式です。

Lovableで構築されていないアプリの場合はどうすればいいですか？

同じ移行手順がそのまま使えます。Lovalingoは、React、Next.js、v0、Bolt、そしてClaude Codeのプロジェクトにも対応していましたが、globalize.nowも同じスキルパッケージでこれらをカバーします。お使いのエージェント用にインストールし、文字列をLinguiカタログとして抽出させ、プッシュしてPRをマージするだけです。開発者やバイブコーダー向けの流れは、Lovableエディタを使わない点を除けば、Lovableでの手順とまったく同じです。上記の削除チェックリストもそのまま適用できますし、3か月無料の移行オファーも同様に対象となります。

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

globalize.nowを無料で試す