GitHubから追加します。「Settings」を開き、「Skills」、「Add」、「Import from GitHub」の順に進み、Lovableにglobalize-now/lovable-i18nリポジトリを指定します。Lovableがそれをダウンロード・検証し、ワークスペースに公開すれば、すべてのプロジェクトで利用可能になります。globalize.nowはAIを活用したローカリゼーションインフラであり、キーとロケールファイルを生成し、あなたのアプリ内のランタイムライブラリがそれらを参照します。このスキルこそが、Lovableのエディタから離れることなく、しかもダッシュボードを一切経由せずにそれを実現する仕組みなのです。

Lovableのスキルとは、正確には何なのか？

スキルとは、ワークスペースレベルで一度だけ保存する、短く名前の付いたプレイブックです。3つの要素で構成されます。恒久的な小文字の名前、Lovableがいつそれを読み込むべきかを示す説明文、そして適用時にLovableが従うMarkdown形式の指示です。

重要なのは、スキルが必要に応じて読み込まれるという性質です。これはワークスペースの知識とは異なります。ワークスペースの知識は常にコンテキストに含まれており、コーディング規約やブランドルールなどはそこに置くべきものです。一方スキルは、リクエストがその説明文に合致したときにだけ会話に読み込まれるため、一つのワークスペースに多数の専用スキルを持たせても、関係のない作業の負荷にはなりません。

チャット入力欄に/と入力して選択すれば意図的に呼び出せますし、プロンプトが合致すればLovableが自動的に適用することもできます。スキルを「どうやるか（how）」、プロンプトを「何をするか（what）」と考えるとわかりやすいでしょう。

また、スキルには可搬性もあります。LovableはAnthropicのAgent Skills規約と同じSKILL.md形式を採用しているため、一方のツール向けに書かれたスキルを、変換なしでもう一方にそのままインポートできます。これはローカリゼーションにとって小さな話ではありません。Lovable内でi18nの雛形を作るのと同じ指示を、後でClaude CodeやCursorで開くリポジトリに持ち込めるということです。

なぜLovableのアプリは英語版しか出力されないのか？

生成されるコードにロケールレイヤーが存在せず、英語以外を出力する仕組みがそもそもないからです。料金ページをLovableにプロンプトで依頼すると、見出しはプロンプトに使った言語のリテラル文字列として、コンポーネントに直接書き込まれます。ボタン、空状態の表示、トースト通知、バリデーションメッセージも、すべて同じように埋め込まれます。

後から「アプリを翻訳して」とエージェントに依頼しても、結果は中途半端なものになりがちです。たまたま検査対象になった画面だけが差し替わり、次に構築する機能はまた英語のまま届きます。この繰り返し発生する現象についてはLovableの翻訳がずれていく理由で詳しく解説しており、その仕組み自体は今も変わっていません — エージェントは目の前のプロンプトを解決しているだけで、その背後にあるアーキテクチャの問題までは解決していないのです。

解決策は構造的かつ一度きりのものです。文字列にキーを付与し、翻訳をファイルに格納し、ランタイムがそのファイルを読み込むようにする。スキルがこの作業の受け皿として適しているのは、まさにそれが固定されたプレイブックであり、毎回正確に言い回しを考えなければならないプロンプトではないからです。

lovable-i18n スキルは何をインストールしますか？

Lingui v6を導入し、src/locales/[locale]/messages.poにPOカタログを配置、抽出用のTransマクロ、言語切り替えコンポーネント、そしてGitHub Actionまで一式そろえます。プロジェクトが使用しているスタックを検出したうえで雛形を作成します — Vite SPAかTanStack Startか、どちらもLovableが生成し得るスタックです。

このスタック検出は、見た目以上に重要です。Lovableのデフォルトで生成されるスタックはサーバーレンダリング対応のTanStack Startへと移行しており、クライアントレンダリングのSPAとサーバーレンダリングのアプリとでは、正しいi18nの配線方法が異なります。サーバーレンダリングのケースについてはTanStack Startガイドで別途詳しく解説しています。このスキルは自動的に正しい経路を選ぶので、自分がどちらの構成になっているかを把握しておく必要はありません。

このスキルがインストールしないもの、それは私たちへのランタイム依存です。カタログはあなたのリポジトリ内のファイルです。仮に明日globalize.nowを取り除いたとしても、POファイルがコミット済みのLinguiアプリは、すでに持っているすべての言語をそのままレンダリングし続けます。

スキルはどうやってインポートするのか？

手順は4つ、ワークスペースごとに一度だけです。

  1. LovableプロジェクトをGitHubに接続する。 チャット入力欄の+メニューでGitHubを選び、続けて「Connect project」を選択します。カタログを置くには実体のあるリポジトリが必要です。
  2. スキルをインポートする。 「Settings」、「Skills」、「Add」、「Import from GitHub」の順に進み、https://github.com/globalize-now/lovable-i18nを指定します。SKILL.mdはリポジトリのルートに配置されており、これはリポジトリ全体のURLを指定した際にLovableが想定するレイアウトです。より大きなスキル集リポジトリ内のサブディレクトリでも、treeまたはblob形式のURLを使えば同様に機能します。
  3. globalize MCPを追加する。 「Connectors」を開き、「Custom MCP」を選んでhttps://api.globalize.now/mcpを追加します。サインインが必要になった段階で、スキルがその手順を案内してくれます。
  4. Lovableにプロンプトを送る。 lovable-i18nスキルとglobalize MCPを使ってi18nをセットアップし、アプリを翻訳するよう依頼してください。

始める前に知っておくべき制約が2つあります。カスタムワークスペーススキルの作成・編集・削除・インポートはワークスペースのオーナーおよび管理者のみに制限されています——編集者は全てのスキルを閲覧・実行できますが、追加はできません。また、設定画面からスキルを追加すること自体はクレジットを消費しません。クレジットが発生するのは、そのスキルを使用するメッセージが送られたときで、これは他のビルドメッセージと同じ課金体系です。

具体的なURLを含めた手順の詳細はLovable連携ページに記載しています。

このMCPは何であり、何ではないのか？

ここが紛らわしいポイントで、逆に理解すると半日を無駄にします。

Lovableには、正反対の方向を向いた2種類のMCPインターフェースがあります。mcp.lovable.devにあるLovable MCPサーバーは、ChatGPT・Claude・Cursor・VS Codeといった外部エージェントが、別の場所からあなたのLovableプロジェクトを作成・編集できるようにするものです。一方、Connectors画面でカスタムMCPとして追加するチャットコネクタはその逆で、あなたが開発している最中にLovableのエージェントが外部ツールにアクセスできるようにするものです。

globalize MCPは後者のタイプです。Lovableのエージェントに、ローカライゼーションプロジェクトの作成、カタログの翻訳、リポジトリの接続を任せることができ、そのために別のプロダクトを開く必要はありません。Lovable自身のドキュメントもこの違いを明確に説明しており、それだけ多くの人が混同しやすいということでしょう。

実務上のポイントはこうです。ClaudeやCursorにURLを貼り付けてこれを動かそうとしているなら、それは間違ったインターフェースを使っています。ここで説明する作業はすべてLovableのエディタ内で完結します。

最初のセットアップの後は何が起きるのか？

スキルが雛形を生成し、その差分がGitHubに同期されます。Lingui設定、POカタログ、文字列をTransマクロでラップするコンポーネントの変更、言語切り替えスイッチャーなど、他の変更と同様にレビューしてから、デフォルトブランチへマージしてください。

それ以降、変換作業は完了です。これは一度きり、かつアプリ内で完結する作業です。リポジトリを接続することで、globalize.nowがコードベースを一度変換し、カタログを生成します。それ以降は、プッシュのたびにジョブが新しいカタログ単位を翻訳し、プルリクエストとして届けてくれるので、あとはマージするだけです。あなたはこれまで通りLovableにプロンプトを送り続ければよく、新しい文字列は未翻訳のまま溜まっていくのではなく、カタログに反映されていきます。

エクスポートの手順もインポートの手順もなく、誰かが文字列を一つずつ承認していくような画面もありません。それがなぜ重要なのか、より詳しい議論はダッシュボードなしでLovableアプリをローカライズする方法をご覧ください。

なぜ翻訳ウィジェットではなくスキルなのか？

ウィジェットとカタログでは、生成される成果物が異なり、そのうち自分のものになるのはどちらか一方だけだからです。

ランタイムウィジェット——Weglotのようなモデル——は、ページが読み込まれた後にブラウザ上でテキストを書き換えるJavaScriptを注入します。その結果、一瞬英語の表示がちらつき、文字列の長さが変わるたびにレイアウトが崩れ、インデックスには英語1ページのみが登録され、翻訳はクライアントサイドで行われるためクローラーが確実に認識できるとは限りません。どんなサイトにも導入できるのが本当の強みで、自分でコードを管理していないマーケティングページにとっては十分に合理的な選択肢です。

一方、コミットされたカタログはその正反対のトレードオフです。コードへのアクセス権が必要ですが、あなたにはそれがあります。その代わり、翻訳済みのマークアップは自分のリポジトリから生成され、言語ごとにインデックス可能な1ページが得られます。Lovalingoは、まさにLovable向けにランタイムモデルを採用していましたが、2026年8月31日にサービスを終了しました。移行を検討している場合は、移行ガイドに既存データのエクスポート方法がまとめられています。このサービス終了自体が、ファイルベースの形式を選ぶべき最も明快な理由でもあります。Gitの履歴に残るPOカタログは、企業が存続し続けることに依存しないからです。

仕組みではなく成果に焦点を当てたエンドツーエンドの解説が必要な場合は、Lovableアプリを多言語化するから始めてください。始める前に費用を知りたい場合は、料金ページに現行プランを掲載しています。

一度追加するだけ

インポートはワークスペースで一度だけ行うアクションで、無料です。それ以降、i18nは他の機能と同じようにチャット入力で依頼するだけのものになり、翻訳は自分の所有するファイルとして届きます。

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

globalize.nowを無料で試す