flutterflow language【2026年版】多言語化と設定手順
はじめに
FlutterFlowでアプリを海外展開したい時に避けられないのが、language設定とローカライズです。単に英語の文言を日本語や別言語に置き換えるだけでは、実際の利用体験は安定しません。ボタンの幅、日付や数字の表示、通貨の見え方、権限メッセージ、エラー文、利用規約、通知文まで含めて確認する必要があります。
FlutterFlow公式Docsでは、アプリの多言語化、Google Translateを使った一括翻訳、手動修正、LanguageSelector、Set App Language、日付・数字・通貨のローカライズ、公開前テストが説明されています。つまり、FlutterFlowではアプリ側の多言語対応を進められますが、翻訳の品質確認や画面崩れのチェックは開発者側の責任として残ります。
この記事では、flutterflow languageを検討する人に向けて、Languages設定でできること、Translate Allと手動翻訳の使い分け、LanguageSelectorの注意点、料金プラン、公開前テストを整理します。MVPの段階から多言語化を意識しておくと、公開直前に大量の文言修正が発生するリスクを減らせます。
対象言語が1つ増えるだけでも、確認する画面数は大きく増えます。ログイン、オンボーディング、課金、通知、エラー、問い合わせ、退会まで一連の流れを言語ごとに確認する必要があるため、最初に翻訳対象の画面一覧を作ることが重要です。
FlutterFlowのlanguage設定でできること

FlutterFlow Localization Docsでは、Settings and IntegrationsのLanguagesから対応言語を追加し、Primary Languageを設定する流れが説明されています。flutterflow languageの基本は、アプリの表示テキストを言語ごとに管理し、必要に応じて自動翻訳と手動修正を組み合わせることです。
| 設定項目 | 確認すること |
|---|---|
| Languages | 対応言語とPrimary Language |
| Translate All | 一括翻訳後の手動確認 |
| Display Language | 実行前プレビューでの表示確認 |
| Predefined Messages | 権限や認証メッセージの翻訳 |
| Date/Number/Currency | 地域別表示の確認 |
特にPrimary Languageは重要です。公式Docsでは、翻訳後にPrimary Languageを変更すると他言語の既存翻訳が消える注意点が示されています。最初に基準言語を決めてから翻訳作業を始めることが、手戻りを防ぐ基本です。
Translate Allと手動翻訳の使い分け

Translate Allは初期翻訳を速く進めるには便利ですが、そのまま公開できるとは限りません。商品名、業界用語、ボタン文言、エラー文、課金画面、医療・金融・教育など慎重な表現が必要な箇所は、人が確認する必要があります。自動翻訳は下書き、手動翻訳は品質保証と考えると整理しやすくなります。
FlutterFlowでは、Language Settings上で文言を管理でき、個別のText widgetなどからも翻訳を追加できます。固定したい翻訳はFixedとして扱い、自動翻訳で上書きされないようにします。RichTextの静的テキストは翻訳対象になりますが、Combine Textで組み立てた文字列はTranslate Allに含まれないため、動的文言の扱いには注意します。
翻訳レビューでは、短い英語をそのまま直訳しないことも大切です。英語では自然な「Next」「Continue」「Submit」も、日本語や他言語では画面文脈に合わせた表現が必要です。多言語アプリでは、文言の長さが変わってもボタンやカードが崩れないよう、スマホ幅で必ず確認します。
LanguageSelectorと表示切替の注意点

LanguageSelector Widgetを使うと、ユーザーがアプリ内で言語を切り替えられます。公式Docsでは、LanguageSelectorが現在の言語を表示し、操作時に利用可能な言語一覧を出せることが説明されています。オンボーディングや設定画面に置くと、ユーザーが自分の言語を選びやすくなります。
ただし、初期状態では選択した言語が次回セッションに保持されない点に注意が必要です。言語選択を残したい場合は、Language SettingsでPersist Selectionを有効にするか確認します。LanguageSelectorは置くだけで終わりではなく、選択保持と初回表示言語までテストすることが重要です。
カスタムの言語選択画面を作る場合は、Set App Language Actionを使ってユーザーの選択を反映します。このActionはアプリの言語を切り替えるもので、端末のシステム言語自体を変更するものではありません。ユーザーが期待する動作と実際の仕様にズレが出ないよう、ヘルプ文や設定画面の説明も用意しておきます。
料金プランと公開前テスト

FlutterFlow Plan Comparisonでは、Free、Basic、Growth、Business、Enterpriseの各プランが掲載されています。月額目安はFreeが0ドル、Basicが39ドル、Growthが1席目80ドル・2席目55ドル、Businessが1席目150ドル・2-5席目85ドル、EnterpriseはCustomです。
| 見る項目 | 多言語化での意味 |
|---|---|
| Project Count | 検証用プロジェクトを分けられるか |
| API Endpoints | 翻訳APIや外部CMS連携の余地 |
| Editors | 翻訳担当や開発担当の同時編集 |
| Support | Email、In-App、Dedicated Liveの有無 |
公開前テストでは、端末の言語設定、アプリ内の言語切替、長文表示、日付、数字、通貨、権限メッセージ、ログイン後画面、エラー文を確認します。サポートが必要な案件では、Customer Support Policyにあるプラン別サポート範囲も確認します。FlutterFlowの基本機能と料金を広く見たい場合は、FlutterFlowとは?ノーコードアプリ開発の使い方・料金・注意点【2026年版】も参考になります。
公開直前には、翻訳担当者だけでなく実際の利用者に近い人にも触ってもらいます。言語切替の場所が分かるか、長い翻訳でも操作できるか、エラー時に次の行動が分かるかを確認すると、翻訳品質だけでは見つからない課題を拾えます。
まとめ
flutterflow languageを設定する時は、翻訳作業だけでなく、言語設計、Primary Language、Translate All、Fixed翻訳、LanguageSelector、Persist Selection、Set App Language、日付・数字・通貨、公開前テストまでを一連の流れとして考えます。自動翻訳は便利ですが、公開品質を担保するには、人によるレビューと端末別テストが欠かせません。
料金プランはFree、Basic、Growth、Business、Enterpriseで機能やサポートが変わります。多言語化だけならFreeで試せる範囲もありますが、API連携、複数人編集、本番運用、サポート速度が必要な場合は上位プランも検討します。特に納期がある案件では、サポート範囲と開発体制を先に確認しておくほうが安全です。
結論として、多言語化は文言の翻訳ではなく、ユーザー体験全体の設計です。Nocoderiでは、FlutterFlowの多言語アプリ設計、翻訳対象画面の整理、LanguageSelector設定、Firebase/API連携、公開前テストまで相談できます。すでにFlutterFlowで作り始めている場合でも、現在の画面一覧と翻訳したい言語を共有できれば、修正範囲を切り分けられます。
最初の相談では、対象国、対応言語、基準言語、翻訳対象画面、言語切替の場所、外部連携、公開予定日を整理しておくと進めやすくなります。グローバル展開を見据えるなら、MVP段階から翻訳しやすい画面構造にしておきましょう。

ビジネスの課題解決をサポートします
- システム開発を短期間でコストを抑えて作りたい
- システムのDX推進を進めていきたい
- 社内の業務効率化を進めたい


