ダッシュボードなしでBase44アプリをローカライズするには？

Base44アプリをローカライズするには、Base44が提供する双方向同期でGitHubに接続し、翻訳カタログをそのリポジトリにコミット済みファイルとして保管します。Base44はエディタとリポジトリの間ですでにあらゆる変更をミラーしているため、ロケールファイルがmainブランチに着地した瞬間、それらはアプリの一部になります。globalize.nowはAI搭載のローカライゼーションインフラです——キーとロケールファイルを生成し、プロジェクト内のランタイムライブラリがそれらを提供します。実行経路上にダッシュボードは存在せず、ページ読み込み後に何かを翻訳することもありません。

なぜあなたのBase44アプリは英語専用なのか？

インターフェーステキストがコンポーネント内にリテラル文字列として存在しているからです。予約ページをBase44にプロンプトすると、それはカタログへの参照ではなく、<h2>Your bookings</h2>をReactコンポーネントに書き込みます。見出し、ボタンのラベル、空状態の表示、トースト通知、検証メッセージ——そのすべてが、あなたがプロンプトした言語のままJSXに直接入り込みます。

これはBase44の欠陥ではありません。プロンプト駆動のビルダーがすべてそうするのであり、Cursor keeps adding hardcoded stringsで記録したのと同じパターンです。モデルはあなたのリクエストに対して最短で正しいコードを書くだけで、あなたはロケール層を求めていなかったのです。

Base44に「アプリをドイツ語に翻訳して」と頼んでも解決しません。得られるのは、モデルが調べた画面のドイツ語版か、その場ででっち上げた小さな文字列オブジェクトです。次のプロンプトでは、また英語で新しいテキストが書かれます。プロジェクト内に、テキストはカタログを経由すべきだという取り決めが何もないからです。

Base44は実際には何を生成するのか？

Viteで構築された標準的なReactプロジェクトです。Base44自身のプロジェクト構造ドキュメントには、Codeタブと接続済みリポジトリで得られるレイアウトが示されています——src/pagesにはルートごとに1ファイルが格納され、Home.jsxは/に、Settings.jsxは/settingsになります。src/componentsには再利用可能なパーツと、あらかじめ用意されたコンポーネントのui/フォルダが入っています。src/api、src/hooks、src/lib、src/utilsにはSDKクライアント、フック、ヘルパーが格納されています。

ローカライゼーションにおいて他より重要なディレクトリが二つあります。functions/にはバックエンドロジックが格納され、関数ごとに1つのTypeScriptファイルがあり、これらのファイルはエラーレスポンス、メール、生成される文書など、ユーザーが読むテキストを整形します。entities/にはデータモデルがJSONスキーマファイルとして格納されていますが、双方向同期のもとではエンティティはリポジトリではなくBase44内で管理されます。

つまりBase44アプリには、カタログがカバーできる文字列面——Reactクライアントとバックエンド関数——が二つあり、カバーできないもの——エンティティ内のデータ——が一つあります。この最後の点については後ほどまた触れます。

Base44アプリをどうやってリポジトリに入れるのか？

Base44がその接続機能を提供しています。エディタでDashboardを開き、GitHubアイコンをクリックして接続します。GitHubアカウントまたは組織でBase44 Builderアプリを承認し、アクセスを許可するリポジトリを選び、そのアプリ用の新しいリポジトリを作成します。以降、リポジトリとエディタは双方向で同期された状態を保ちます。

Base44のドキュメントにある二つのルールが、その後すべてを形作ります。まず、同期は自動です——プロンプトからAIが行った変更を含め、Base44で行った変更はプッシュ操作なしにリポジトリへコミットされ、手動でプッシュするボタンはありません。次に、戻る経路はmainブランチです。mainにマージされたものはBase44アプリ上で見えるようになり、masterやその他のデフォルトブランチ名はサポートされていません。マージ後は、Publishをクリックして新しいバージョンをユーザーに公開します。

双方向同期にはBuilderプラン以上が必要で、初回の接続はアプリのオーナーしか行えません。あなたのアカウントが以前の一方向の「GitHubへのエクスポート」連携を設定していた場合、GitHubパネルにそれを切断して双方向同期で再接続するリンクがあります。一方向の経路ではエディタに何も戻ってこず、それはまさにローカライゼーションが必要とする方向と逆です。

ローカルで作業するには、リポジトリをクローンし、npm installを実行してBase44のCLIをインストールし、次にbase44 loginとbase44 linkでそのクローンを対応するアプリに紐づけます。base44 devはローカルのバックエンドに対してフロントエンドを実行します。ローカルブランチをmainにマージすることで、変更が同期されて戻ります。

Base44アプリにおける「ダッシュボード不要」とはどういう意味か？

それは、翻訳された文字列があなたのアプリが呼び出さなければならない、またはエクスポートしなければならないホスト型サービスの中に一切存在しないということです。それらはsrc/pages/Home.jsxの隣のsrc/locales/de.jsonに存在し、同じコミットでバージョン管理され、同じプルリクエストでレビューされ、同じPublishクリックでデプロイされます。

代替案にはそれぞれ、Base44特有のコストがかかります。ブラウザ上でページを翻訳するランタイムウィジェットはソースコードに手を加えないため、リポジトリ上ではアプリが英語のままだと表示され続け、訪問者は毎回読み込み時に翻訳の遅延を負担します。独自エディタを持つホスト型翻訳ツールは、正しい情報をリポジトリの外に保持するため、Base44が構築した双方向同期は、言語を含まないコードベースを同期し続けることになります。どちらも、あなたがすでに所有しているファイル内のテキストとの間に、第二のシステムを割り込ませてしまいます。

リポジトリ起点の形は、同期を設計通りに使います。カタログはファイルです。ファイルはコミットされます。コミットされたファイルはmainに到達します。mainはエディタに到達します。それがパイプラインのすべてであり、その中にローカライゼーション固有のものは何一つありません。

リポジトリ起点のセットアップはどう機能するのか？

アプリ内でリポジトリを接続し、変換を一度だけ実行します。この変換はコンポーネントとバックエンド関数内のリテラル文字列を見つけ出してキーを付与し、プロジェクトにi18nextやLinguiなどのランタイムライブラリがなければそれを組み込み、ソースカタログと最初のターゲット言語を添えて、あなたのリポジトリに対するプルリクエストを開きます。そのプルリクエストが受け渡しのすべてです。他の変更と同様にGitHub上でレビューし、mainにマージすれば、Base44がそれをエディタにミラーします。

ここから先は、プッシュジョブが新しいカタログユニットを翻訳します。Base44に新機能をプロンプトで指示し、同期がそれをコミットすると、ソースカタログ内の新しいキーが翻訳され、プルリクエストとして届きます。マージしてPublishをクリックすれば、その機能はすべての言語で公開されます。プロンプトの書き方を変える必要はなく、アプリが実行時に外部サービスを呼び出すこともありません。

同じ手法はLovable、Bolt、v0、Replitでも通用します。この4つはいずれも標準的なフロントエンドプロジェクトを渡してくれるため、仕組みはまったく同じです。Lovableの解説記事ではカタログ構成について最も詳しく扱っており、Boltガイドはネイティブ同期を持たないビルダー向けのエクスポート手順を、Lovableのクラシックスタック向けViteガイドはコードレベルでBase44のReact＋Vite出力に最も近い内容を扱っています。ビルダーを比較検討中で、まだ決めていない場合はバイブコーダー概要から読み始めるのがおすすめです。

バックエンド関数の中にある文字列とは？

サーバーサイドで生成され、ユーザーが目にするものすべてです。関数から返されるバリデーションエラー、送信されるメールの件名、生成されるPDFの本文、通知のテキストなどです。これらの文字列はJSXとして現れないため、フロントエンドのカタログには含まれず、ランタイムのウィジェットからも見えません。

パターンはクライアント側と同じです。受信リクエストからロケールを読み取り、そのロケール用のカタログを関数側でロードし、キーの名前空間をクライアントと共有することで、UIとAPIレスポンスでメッセージの意味を一致させます。functions/ディレクトリはリポジトリ内にあるため、変換処理はこれらのファイルを他のソースと同様に扱い、カタログはその隣に配置されます。

エンティティ内のコンテンツはどう扱う？

これはBase44特有の境界線です。エンティティはBase44内で管理されるデータモデルであり、双方向同期のもとではリポジトリの一部にはなりません。商品名、サービスの説明、ヘルプ記事といったレコードはインターフェーステキストではなくデータなので、カタログに含まれることは決してありません。

データコンテンツには、エンティティ自体に言語の次元を持たせる必要があります。ロケールフィールドを設けるか、言語ごとにフィールドを分け、訪問者のロケールを読み取るクエリを用意します。この構成はLovableアプリのデータベースコンテンツで説明しているものと同じで、これはローカライズツールの判断ではなく、Base44のエンティティエディタで行うデータモデルの判断です。既存レコードを持つエンティティに後から言語フィールドを追加するのは、新規エンティティに最初から用意するより手間がかかるため、早めに計画しておきましょう。

もしLovalingoを使っていたら？

Lovalingoは2026年8月末にサービスを終了しましたが、公開されていた活用事例にはLovable、v0、Boltと並んでBase44も含まれていました。これを使ってBase44アプリをローカライズしていた人は、その文字列の移行先を見つける必要があります。これは新規セットアップではなく移行作業です。まずエクスポートし、それから変換します。移行ガイドで手順を確認でき、比較ページでは翻訳がホスト型サービスからリポジトリへ移る際に何が変わるかを解説しています。

2つ目の言語を追加する前に確認すべきことは？

同期が双方向であり、旧式のエクスポートではないことを確認してください。Base44のGitHubパネルを開き、リポジトリが接続済みと表示されるかチェックします。「旧セットアップをお探しですか？」というリンクが表示される場合は、一方向の経路のままなので再接続が必要です。

デフォルトブランチがmainであることを確認してください。Base44はそのブランチのみをミラーリングするため、他のブランチにマージされたプルリクエストはエディタに反映されません。

ランタイムライブラリがすでに使われていないか確認してください。これまでにBase44へ多言語対応を依頼したことがあれば、いつの時点であれi18nextや自前のコンテキストが追加されている可能性があります。変換処理はそこにあるものをそのまま活かし、翻訳を供給します。

2つ目の言語でレコードを追加する前に、エンティティコンテンツの言語フィールドをどこに持たせるか決めておきましょう。この部分はカタログでは対応できません。

ルーティングを確認してください。Base44のページはファイルベースなので、URLにロケールプレフィックスを付けるかどうかは一度きりのルーティング判断になり、検索エンジンが各言語をどう認識するかを左右します。言語切り替えとhreflangのガイドで選択肢を解説していますが、その内容はそのまま活かせます。

どこから始めるか

Base44でまだ双方向のGitHub同期をオンにしていなければオンにし、ブランチがmainであることを確認したうえで、アプリ内でリポジトリを接続してください。最初のプルリクエストでコードベースが変換されます。それ以降はマージとPublishのクリック、そして必要な言語を指定するだけです。Lovable連携ページではエディタ内蔵の経路を持つビルダー向けに同じ流れを説明しており、その内容の大半はそのままBase44にも当てはまります。