イベントメールの多言語化チェックリスト

必要なメールを洗い出す

編集可能な言語別プレビュー表をダウンロード（Markdown・英語）

登録確認、決済や申請の状態、チケット送付、来場案内、日程や会場の変更、アクセシビリティ情報、開催中止を列挙します。参加に必要な連絡と任意の宣伝は分けます。送信条件、責任者、言語選択の情報源、送信システム、リンク先を記録します。サイトが翻訳されていても、チケット事業者が同じ言語に対応するとは限りません。[1][2][3][4]

確認済みの事実を言語に合わせて表示する

イベントの回、会場、住所、開始時刻、タイムゾーン、チケット状態、規約へのリンクは承認済みの記録から取得します。日付や金額は構造化した値として渡し、英語の表示文字列をそのまま全言語に貼り付けないでください。Unicode CLDRには地域ごとの日付表示形式がありますが、実際の開催時点は同じです。長短の氏名、空の任意項目、価格、数量を確認します。遠方からの参加者にはタイムゾーンを明示します。[1][2][3][4]

本文以外も確認する

件名、プレビュー文、挨拶、状態説明、ボタン、テキスト版、画像の代替テキスト、フッター、返信先、リンク先を点検します。HTMLメールでは、利用する仕組みが対応する範囲で内容の言語と異言語部分を指定します。本人が選んだ言語の承認済み翻訳があれば使い、なければ代替言語と表示内容を明確にします。外部の決済画面や添付チケットまで翻訳済みだと決めつけないでください。[1][2][3][4]

状態別プレビューと事業者の境界を確認する

イベントで使う状態だけを安全に再現します。登録確定、支払い待ち、キャンセル待ち、不承認、中止などについて、状態文、チケットリンク、氏名、日付、通貨、問い合わせ先を照合します。試験送信先は承認済みのテストアドレスに限定し、実際の参加者には送らないでください。パソコン、携帯端末、テキスト版を確認します。差し込み値の欠落でメールが生成されない場合もあるため、APIの成功応答だけでなく事業者の生成・配送記録を確認します。[1][2][3][4]

翻訳を承認し、変更時に再点検する

各言語を理解する担当者が、意味、語調、入場や規約に関する重要な表現を文脈の中で確認します。原文と翻訳の版、確認者、プレビュー証拠、事業者側の制約、承認日を残します。会場、時刻、チケット規則、連絡先が変わったら、影響するメールと全言語を特定し、次の送信前に状態別プレビューをやり直します。翻訳の承認は送信自体の承認とは別です。[1][2][3][4]