Lovableアプリに最適なWeglotの代替ツールは何か

Lovableアプリに最適なWeglotの代替ツールとは、翻訳をベンダーの実行環境ではなく、自分自身のリポジトリに置けるものです。globalize.nowは、AI駆動のローカライズインフラとして、ハードコードされた文字列を抽出し、Lingui形式のPOカタログを生成してリポジトリにコミットし、Gitへのプッシュのたびに同期を保ちます。Weglotは優れたノーコードウィジェットですが、Lovableアプリではクライアント側で翻訳を行う形になり、料金体系は追加する言語ごとに膨らんでいきます。本ガイドでは、インデックス可能なページと予測可能なコストを求める開発者向けに、両者を比較します。

WeglotはLovableアプリ上でどのように動作するのか

Weglotは、ビルド済みのサイトにJavaScriptスニペットを埋め込むことで、Lovableアプリを実行時に翻訳します。LovableはReactアプリケーションを生成するため、このスニペットが読み込まれ、訪問者の言語を検出し、ページのレンダリング後に表示テキストを差し替えます。セットアップは数分で完了し、Lovableプロジェクト内のコード変更は不要です。

この手軽さは確かに魅力です。ただしそれは、翻訳されたコンテンツがブラウザ上で生成されるものであり、あなたのコードベースには保存されないことを意味します。あなたのLovableリポジトリには依然として英語の文字列しか含まれず、他の言語はWeglotのサービス側に存在し、アプリを読み込むたびにその上に重ねて適用される形になります。

Weglotには、SEOをより良くするために、翻訳済みページをプロキシ経由で配信するサブドメイン方式・サブディレクトリ方式も用意されています。ただしこれらの方式にはDNSの変更が必要で、トラフィックは自分自身のビルドからレンダリングされるのではなく、Weglotのインフラを経由します。

なぜWeglotの実行時翻訳方式は、LovableアプリのSEOにとって不利なのか

クライアント側での翻訳は、検索エンジンにとってインデックスしづらいものです。なぜなら、翻訳済みのテキストはJavaScriptが実行された後にしか存在しないからです。Weglot自身のガイダンスでも、通常のJavaScript連携ではSEO上のメリットは得られないとされています。これは、翻訳がブラウザ上でレンダリングされ、クロール不可能であるためです。インデックス可能な多言語URLを得るには、サブドメイン方式またはサブディレクトリ方式に移行する必要があり、これらはプロキシを介してサーバー側で翻訳を配信します。

オーガニック流入の拡大を狙うLovableアプリにとって、これは重要なポイントです。ランディングページのフランス語版やドイツ語版を上位表示させたいのであれば、クローラーが目にするバージョンには、受け取るHTML自体に翻訳済みのコンテンツが含まれている必要があります。

globalize.nowは、この課題にソース側からアプローチします。コミットされたロケールファイルを生成し、それをLovableのビルドが本物のロケール別ページとしてコンパイルします。翻訳済みのコンテンツは自分自身のバンドル内に含まれる形で配信されるため、プロキシが稼働し続けていることにも、クローラーがウィジェットを実行してくれることにも依存しません。この議論をさらに掘り下げた内容は、Lovableアプリの翻訳がプッシュのたびに壊れる理由についてのノートでご覧いただけます。

Weglotは言語ごとに課金されるのか

その通りです。Weglotの料金は、プロジェクト内の単語数と翻訳先言語数という2つの変数に同時に依存します。各プランには追加できる言語数の上限があり、更新されない固定の単語割り当てが設定されているため、どちらの軸で成長しても上位プランへの移行を迫られる可能性があります。公開プランは月額約15ユーロから始まり、単語数と言語数が増えるにつれて料金も上がっていきます。

このモデルは、2つか3つの言語を扱うマーケティングサイトであれば問題ありません。しかし、市場を次々と追加していくアプリにとっては割高になりがちです。新しい言語を追加するたびに、言語数の上限と共有の単語予算の両方を消費してしまうためです。

globalize.nowは異なる仕組みを採用しています。ワークスペースごとに月額20ユーロで、シート数や言語数による追加料金は一切ありません。プランには月あたり20ユーロ分の翻訳クレジット（約20万語相当）が含まれており、それを超えた分は同じ文字単価でのトークンベースの従量課金となります。10番目の言語を追加しても上位プランへの移行を強いられることはなく、単にその文字列に必要な文字数を消費するだけです。差別化のポイントは、市場最安値のうたい文句ではなく、シート課金も言語ごとの追加料金もない、透明性の高い従量課金という点にあります。

Lovableアプリにとって、globalize.nowはどう違うのか

globalize.nowは、翻訳ウィジェットの一段下のレイヤーに位置します。実行時に翻訳を適用するのではなく、ロケールファイル自体をコードベースの一部として管理するのです。

具体的には、Lovableアプリ内でハードコーディングされたUI文字列を抽出し、翻訳キーを生成して、リポジトリ内で管理されるLingui PO カタログを生成します。Gitへのプッシュごとに新規・変更された文字列を検知して翻訳アップデートを起票するので、手動でのエクスポートやレビュー待ちの行列なしにロケールファイルを常に最新の状態に保てます。これはLinguiのようなi18nランタイムが利用するキーとファイルを生成するレイヤーです。

Lovableでアプリを作る人にとっての実際的なメリットは「所有権」です。翻訳データはコードと一緒にバージョン管理され、プルリクエスト上で差分として確認でき、ツールを変更してもそのまま持ち出せます。ユーザーとあなたのテキストの間にベンダー独自のランタイムが介在することもありません。エンジニアリング面の全体像を知りたい方は、globalize.now developersページで抽出と同期のモデルを、vibe-coders overviewでAIツールワークフローの文脈での解説をご覧ください。

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

セットアップはLovableエディタ内で行い、その後はプッシュごとに自動で継続します。以下はWeglotで翻訳されたLovableアプリから、コミット済みのロケールファイルへ至る流れです。

1. Lovableワークスペース内にlovable-i18nスキルを追加します。
2. Lovableにi18nセットアップを指示するプロンプトを送ります。globalize.nowがハードコーディングされた文字列を抽出し、Lingui PO カタログを生成します。
3. 生成されたロケールファイルをリポジトリにコミットします。
4. ロケール別ページが正しく表示されることを確認したら、WeglotのJavaScriptスニペットを削除します。
5. Gitにプッシュします。新規・変更された文字列がプッシュごとに自動で同期されます。

Lovableエディタではなくコマンドラインから作業する場合は、以下でスキルをインストールしてください。

npx skills add globalize-now/globalize-skills

--allを追加すると、使用しているすべてのエージェント用にスキルがインストールされます。Lovable固有の詳しい手順はLovable integrationページに掲載しています。

それでもWeglotを使うべきなのはどんな場合？

コードを一切変更したくなく、完全にホスティングされたワークフローを望む場合は、Weglotの方が適しています。Lovableプロジェクトが小規模なマーケティングサイトで、対応言語が数言語程度で済み、リポジトリに触るよりダッシュボードから一括管理したい場合には、Weglotのスニペットは実際に導入がとても速いです。

アプリそのものがプロダクトであり、今後市場を拡大していく予定があり、検索エンジンにインデックスされ、バージョン管理され、言語ごとの追加費用が発生しない翻訳を求めている場合は、globalize.nowの方が適しています。この2つのツールは異なる優先事項に最適化されています。Weglotは手間のかからないシンプルさを、globalize.nowはリポジトリ起点で長く使える永続的なローカライゼーションを重視しています。あなたのLovableアプリが目指す方向性に合ったトレードオフを持つツールを選んでください。

globalize.nowはこの問題に対応します。Lovableワークスペース内で一度セットアップすれば、Gitへのプッシュごとに自動で同期されます。仕組みの詳細はglobalize.nowでご確認いただけます。