SaaSの多言語オンボーディングは、最初の画面のテキストを翻訳するだけではありません。ユーザーが各ステップを理解し、回答を保持したまま、言語を切り替えたり後から再開したりしても登録を完了できる必要があります。そのためには、言語設定と業務データを分離し、検証可能な状態を持つプロセスとしてフローを扱うことが重要です。
このガイドでは、組織の登録に焦点を当て、アカウント作成前に何を提示するか、処理中に何を保存するか、障害を見つけるために何をテストするかを説明します。アプリケーション全体の国際化戦略を定義するものではありません。
UI言語、コンテンツ、登録データを分離する
フォームには次の3種類の情報が同時に表示されることがありますが、同じ方法で保存したり翻訳したりしてはいけません。
- UI言語: ラベル、説明、バリデーション、システムメッセージを決めます。
esやfrのような、ユーザー体験に関する設定です。 - プロダクトコンテンツ: プランの説明、カテゴリ、ウェルカムテンプレートなど、ビジネスが管理するテキストです。独自の翻訳を持つ場合があり、個別に判断する必要があります。
- ユーザー入力データ: 組織名、ドメイン、説明などです。UI言語を変えても翻訳せず、ユーザーが入力したとおりに保持します。
データモデルでは、異なる概念を表す曖昧な単一フィールドlanguageの使用を避けます。UI言語の設定にはpreferred_localeなどの名前を付けられます。管理対象コンテンツの言語は、該当する場合、そのコンテンツに紐付けます。一方、組織名はUIを切り替えても別の値にはなりません。
この分離により、セレクターの扱いも明確になります。翻訳された選択肢からユーザーが業種を選ぶ場合、表示ラベルではなく安定したIDを保存します。そうすれば、業務データを変更したり、ラベルが常に同一であることに依存したりせずに、別の言語で選択肢を表示できます。
アカウント作成前に言語を選ぶ
登録は、ユーザーが認証され、プロフィールに設定が保存される前に始まることがよくあります。そのため、システムには明示的な初期ルールが必要です。選択メニューを表示する、ブラウザーの言語を候補として使う、または両方を組み合わせる方法があります。自動検出は選択の助けとし、ユーザーが別の言語を選べないようにしてはいけません。
複数の手掛かりがある場合、どの値を優先するかを定義します。たとえば、登録中に明示的に選んだ言語は、その後の自動検出より優先されるべきです。選択した言語はセッションまたは登録プロセスのレコードに一時保存し、アカウント作成時にユーザー設定へコピーできます。組織に別個の言語設定がある場合は、個人の設定と混同しないでください。
招待リンクからアクセスした場合、別のデバイスでセッションを再開した場合、または有効期限後に戻った場合の動作も決めておきます。優先順位のルールを文書化し、ステートレスなリクエストによって有効な選択が消えないようにします。別のデバイスから再開する可能性がある場合、設定をブラウザーだけに保存せず、適切にオンボーディングの永続化された状態に紐付けます。
登録の切り替え・再開に対応する状態を設計する
オンボーディングは独立したページの集合ではなく、状態の連続として表現します。レコードには、現在のステップ、回答済みの項目、選択した言語と、保留中・完了・期限切れなどの状態を含められます。一貫して永続化すれば、画面を再読み込みするたびに組織を作成することなく、プロセスを復元できます。
PHPアプリケーションでは、フローの状態と受信した各データをサーバー側で検証します。画面上でナビゲーションを制御しても、ステップ完了の判断を画面だけに委ねてはいけません。ステップと選択肢には安定したIDを使い、再試行でリソースが重複しないよう更新を処理します。たとえば、組織作成リクエストが重複して届いた場合、新たな登録を開始するのではなく、既存のプロセスを認識する必要があります。
言語を切り替えたらラベルやメッセージを再表示しつつ、有効な回答は保持します。市場間のルールに実際の違いがあり、回答が無効になった場合は、その理由を説明して修正を求めます。黙って削除してはいけません。また、言語の選択によってプロセスIDを変えたり、進捗をリセットしたりしてはいけません。
ラベル、バリデーション、エラーの一貫性を保つ
翻訳の対象は見出しだけでなく、フロー全体です。ラベル、ヘルプテキスト、ボタン、読み込み状態、確認メッセージ、バリデーションメッセージ、復旧可能なエラーを含めます。フィールドが機能していても画面に複数の言語が混在すると、ユーザーが次の操作を誤解する可能性が高まります。
バリデーションルールはクライアントとサーバーで一貫させます。たとえば必須フィールドが空でないことのように、ルールは共通の条件として定義し、それぞれのUIで選択された言語のメッセージを表示します。翻訳した文の断片をつなぎ合わせてメッセージを作るのは避けてください。語順や文法が言語によって異なるためです。安定したエラーキーに対応する完成したメッセージを使います。
内部エラーコードとユーザーに表示するテキストを分けます。たとえば、アプリケーションはorganization_name_requiredのようなキーを返し、UI向けの適切なメッセージに解決できます。技術ログにはコードとプロセスIDを含められますが、不要な個人データを露出したり、内部例外をブラウザーに返したりしてはいけません。
ネットワーク障害や一時的に応答できない場合は、回答が保持されたかどうかを示し、安全に続行または再試行できる操作を提示します。サーバーが確認していない情報を保存したと約束せず、理解しやすいメッセージにします。
翻訳だけでなく一連のフローをテストする
テストでは利用手順と状態の変化を網羅します。実用的なテストケースは次のとおりです。
- 利用可能な言語で登録を開始し、複数の項目を入力して、ラベルとメッセージがその言語で表示されることを確認する。
- 処理の途中で言語を切り替え、回答が保持され、選択肢が翻訳され、リソースが重複作成されないことを確認する。
- 無効なデータを含むフォームを送信し、エラーが明確で、選択した言語で表示され、正しいフィールドに対応することを確認する。
- 復旧可能な障害を発生させて再試行し、どの回答が保持され、プロセスが一度だけ進行したことを確認する。
- 登録を中断して再開し、有効期限後や新しいセッションからの場合も含め、設定の永続化ルールを確認する。
- 言語切り替えの前後で、ユーザー入力値と選択したIDを確認する。
重要な不変条件を自動テストします。言語を変えても組織名は変わらないこと、プロセスを再開してもアカウントが重複しないこと、バリデーションに失敗しても有効な項目が消えないことを確認します。テキストが表示され、翻訳キーがそのまま露出しないことを確かめるUIテストも追加します。分かりにくいメッセージや、デザインに収まらなくなった説明を見つけるには、手動テストも引き続き有効です。
別の言語を有効にする前のチェックリスト
- UI言語を表すフィールドと、変更できる人が明確か。
- アカウント作成前やプロセス再開時にも選択が保持されるか。
- 言語を切り替えても入力データと選択肢のIDがそのまま保たれるか。
- フロー全体のラベル、ヘルプ、バリデーション、確認メッセージ、エラーを網羅しているか。
- 再試行や重複リクエストが安全に処理され、登録が重複しないか。
- 開始、言語切り替え、再開、復旧可能な障害をテストしているか。
信頼できる多言語登録は、各データの役割を明確に定め、一般的な操作を経ても状態が保持されることを確認することで実現できます。新しい言語を有効にする前に、最初の選択から確認までのフローを見直してください。各画面は、データの意味を変えたり進捗を失わせたりすることなく、ユーザーを適切に案内する必要があります。
