翻訳で文章が長くなることを考えてデザインする方法

もとの文言が決まった面積に収まる前提の画面では、翻訳によるテキストの伸長がレイアウトの問題になります。短い英語のボタンは収まっても、長い翻訳は切れる。整っていたタブが窮屈になる。カードは伸びても、操作は古い位置に固定されたままになる。

この硬直性の確認に、すべての翻訳を待つ必要はありません。意図的に長いテキストで案に負荷をかけ、その後に本物の翻訳で繰り返せます。最初の段階は構造の弱点を探し、次の段階は実際の言語と意味で使えるかを確かめます。

一つの伸長率では足りない理由

すべての言語に対応できる、単一の余裕の割合はありません。短いラベル、長い文、複合語、異なる文字体系は、それぞれ違う負担を作ります。文字数を数えても、描画に必要な面積は正確には分かりません。

W3Cの翻訳時のテキストサイズに関する解説は、短い原文が大きく伸びる理由と、字幅、単語の構造、行高の重要性を説明しています。例は有用な注意喚起ですが、自分の画面の計算機ではありません。準備ができたと扱う前に、実際の内容とフォントの組み合わせを確認します。

「View details」というボタンのある、架空のイベント管理画面を考えます。長いラベルには、より広いボタンや二行目が必要かもしれません。同時にイベント名も、二行から三行になるかもしれません。違う変更であり、影響も違います。すべてに同じ割合の余裕を取っても、どちらの振る舞いも決まりません。

まず、言葉が伝える必要のある意味を特定します。予約の閲覧と変更を区別するラベルなら、その違いを残す必要があります。取り消せない操作の警告は、元のカード高を守るために意味を縮めてはいけません。レイアウトはメッセージを運ぶためにあります。

弱い部品を、小さな一覧にする

場所が厳しく制御される箇所から始めます。ナビゲーション、タブ、ボタン、バッジ、入力ラベル、表見出し、小さなカードは、広い本文列より情報が得られやすい対象です。アイコン、価格、状態、別の操作の横に文字がある例を探します。

部品ごとに、四つの振る舞いを記します。

1. 折り返し： ラベルを次の行にしてよいか。
2. 伸び方： コンテナは一緒に高く、または広くなるか。
3. 隣との関係： アイコンや隣の操作は安全に動くか。
4. 制限： 行数を制限するなら、全文をどこで読めるか。

答えのない問いは、まだ決める必要があるデザインの判断です。短い英語が隠していただけかもしれません。

次に、失敗の負担を記します。装飾的なタグが高くなることと、ラベルで支払い額が隠れることは違います。判断、条件、操作を担う部品を優先します。大切な操作が読めないまま、無害な差の仕上げに最初の一時間を使わずに済みます。

翻訳が届く前にShopifyが学んだこと

Shopifyの国際化の取り組みでは、英語のプレビューで見落としやすい問題が説明されています。抽出した文字列が、コードに直接書いた文字列と同じに見えたのです。チームは、見分けられる文字に置き換え、母音を二倍にする疑似翻訳を導入しました。変えた文字により、翻訳処理を通った場所が分かり、長い単語で画面を確認できました。

疑似翻訳は、翻訳システムに入らない文字、短い言葉に依存する操作、伸びないコンテナといった種類の問題を早く見つけます。ただし、フランス語の指示が自然か、アラビア語の読む順序が正しいかは分かりません。

画像では、何が認識可能なままかにも注目します。珍しい文字があっても、テスト担当者は画面を理解できます。普段の作業をし、その途中で崩れを見つけやすくなります。全欄をランダムな文字列で埋めても負荷はかけられますが、操作と説明の関係を判断する能力まで失われます。

Shopifyの方法を、四つの確認に分けて使えます。

• 対象の網羅： 印の付いた疑似テキストにより、変換されなかった文字列が分かります。
• 収まる余裕： 長い文言で、操作とコンテナが伸びるかを試します。
• 描画： 対象の文字体系と代替フォントで、欠けた字形や切れる行ボックスを探します。
• 言語： 承認済みの翻訳を使い、その言語に堪能な人が意味と表現を判断します。

一つの画面に使う、実用的な負荷テスト

見出し、タブ、状態バッジ、二つの操作、一つのエラーがあるページを選びます。値と移動先は固定し、確認するテキストだけを変えます。

不具合は、それを生んだ文字列と状態に結びつけておきます。「390pxで入力確認の後、フランス語の補助操作が主操作を覆う」なら、開発者は着手点が分かります。「フランス語はもっと場所が必要」では、ボタンの固定幅、硬い操作行、誤ったエラー位置を区別できません。

修正後は短い文も試し直します。幅いっぱいのボタンは最長のラベルを解決しても、大画面では切り離されたように見えるかもしれません。大きな固定高のカードは、一つの翻訳には対応しても、通常のレコードを追いにくくします。内容に応じた伸びと、決めた縦積みの振る舞いを優先し、固定容量は外部の埋め込み先など、本当の制約がある場合に使います。

言語の確認前に、翻訳者へ操作の移動先と周りの文を渡します。「Open」は状態にも命令にもなります。この曖昧さは、広いボタンでは直りません。どちらの担当にも判断できない仕事を保証させず、見た目と言語の確認が互いに情報を与えるようにします。

負荷テストの条件を揃える

長いイベント名、長い会場名、詳しい操作ラベルを使います。最初の比較では、日付と参加人数を固定します。 調べる変数を文字の長さに絞るためです。レイアウトが機能してから、別の確認で日付の現地表記を加えます。

長くした英語でレイアウトの負担を探し、その後に本物の翻訳で、自然な表現、意味、文字体系ごとの描画を確認します。

部品ごとに、対応を選ぶ

同じ長い文字列でも、どこでも同じ直し方にはなりません。ボタンは伸び、ナビゲーションは配置を変え、カードは一行増えるかもしれません。保つべき関係から始めます。

ボタン：伸ばす、折り返す、縦に積む

ボタンには、長いラベルへのルールが必要です。意図的に揃える群なら固定幅も有用ですが、ラベルよりその幅を優先すると、もろくなります。周囲の配置の中で操作を見てから、伸ばすか、折り返すか、移すかを決めます。

フォーム下の二つの操作なら、狭い画面で一行に押し込むより、縦に並べるほうが明確かもしれません。主な操作の目立ち方は、縦積み後も保ちます。もう存在しないデスクトップの並びから、重要度を推測させてはいけません。

ラベルの折り返し自体は、間違いではありません。 十分な高さ、均衡した余白、対象の内容との明確な関係があれば機能します。ただし小さな二行ボタンがいくつもあると追いにくくなります。複数の操作に長い説明が必要なら、全部を同じ小さな群に入れるべきか考え直します。

幅を節約するためだけに、意味のあるラベルを説明のないアイコンへ変えないようにします。文脈に合う、よく知られた操作なら適切な場合もありますが、新しい認識の問題が生まれます。翻訳を消す中立的な方法としてではなく、意識したトレードオフとして評価します。

具体的な寸法として、Albert Sansの32pxで三つの英語ラベルを測り、左右に20pxずつの余白を足しました。「View details」は全体で212px、「Review booking details」は368px、「Review your booking details」は440px必要です。固定幅220pxのボタンでは、ラベルに使えるのは180pxなので、最初は収まり、残りには配置の対応が必要です。これらは幅の負荷を分離する英語のテストラベルで、翻訳ではありません。棒の濃い部分が測定したテキスト、薄い部分が余白です。狭いページでは、伸ばす、折り返す、縦積みにする判断の前に、操作群が使える幅と比べます。

ナビゲーション：衝突する前に切り替える

多くのラベルが一行を奪い合うナビゲーションでは、長文化の問題が早く現れます。原文でぎりぎり収まるヘッダーには、長い言葉の余裕がありません。別の言語では早く切り替えるか、使える幅に適応する配置が必要かもしれません。

ブランド、言語切り替え、アカウント操作、販促リンクを含む、ヘッダー全体を見ます。ナビゲーションのラベルだけでは、本当の衝突を見逃します。少し長くなったアカウントのラベルが、ほかを押し込む要素かもしれません。

等幅を守るためだけに、ラベルを個別に短くしないでください。意味を保つために、翻訳者は異なる言葉を選びます。見た目が対称でなくても、群全体が理解でき、使えるなら、一つの項目が多くの幅を使ってかまいません。

タブでは、折り返しが曖昧さを生まないか考えます。二段のタブは、選択中の項目と内容の対応を分かりにくくすることがあります。タスクによっては、別の操作や意図したスクロールが適切です。単に全文が見えるかではなく、選択状態と移動先の内容を一緒に確認します。

カード：識別と操作を保つ

繰り返すカードには、すべて同じ高さにしたい圧力があります。追いやすさに役立ちますが、方法が重要です。意味のある文字を切って格子を守ると、揃えやすく、選びにくくなります。

イベント画面で、ある名前は三行、別の名前は一行だとします。適切に領域を配分すれば、操作を予測しやすい位置に保てます。タイトルの領域は伸ばせるようにし、タイトル、日付、操作の関係を明確にします。

何を省略してよく、全文へどう到達するかを決めます。長い説明のプレビューと、イベントを識別する名前は違います。省略後に二つを見分けられないなら、選択に必要な情報を失っています。三点リーダーは、失われた違いを説明しません。

バッジとステータスは別に確認します。長い状態が、名前を覆ったり、日付をカード外へ押したりしてはいけません。文字を縮めるより、バッジを独立の行へ移すほうがよい場合もあります。変更後は短いラベルのカードも見て、すべてに過剰な空白が生じないようにします。

フォーム：ラベル、ヒント、エラーを一緒に試す

同じ入力欄の周りに複数の種類の内容があるフォームは、長さにとくに敏感です。ラベルは欄を識別し、ヒントは入力内容を説明し、エラーは修正を示します。別の言語ですべて長くなるかもしれません。

ほかの内容もある状態で、各状態を確認します。ラベルだけならよくても、翻訳したヒントとエラーが下に現れると分かりにくくなることがあります。どの情報がどの欄に属し、修正後にどこへ進むかが、分かる必要があります。

横並びのラベルと操作は、ラベルが長いと縦積みが必要かもしれません。翻訳が悪いのではなく、構造の選択です。横並びを保つなら、両方に役割を果たす幅を与えます。ラベルが広くても、入力欄が使えないほど細いなら改善ではありません。

エラーの違いを保ちます。「必須」「長すぎる」「保存できない」は、異なる問題です。エラー領域の高さが固定だからと、短い共通の言葉に圧縮してはいけません。具体的な問題を伝え、メッセージに応じて領域を伸ばします。

数字、単位、名前を、文脈の中に置く

長くなるのは文だけではありません。日付、通貨、名前、単位も、必要な幅や順序を変えます。記憶からデザイナーが即興で作る値ではなく、対象ロケールで確認する内容の例として扱います。

価格の行は、通貨付きの金額、請求期間、条件を組み合わせるかもしれません。条件が折り返すなら、その価格に属すると明確かを見ます。イベントの日付範囲は、単日より場所が必要かもしれません。カード全体を一行短くするより、ラベルと値を一緒に保つほうが重要な場合があります。

短い単語が一定個数並ぶ名前を想定せず、実際の利用者が入力する代表的な名前を使います。「Alex Lee」でしか成立しないレイアウトは、長い名前が読める証拠にはなりません。全文が必要な場所と、タスク上、短い表示でもよい場所を考えます。

原文の語順が普遍的であるかのように、断片をつなげる指定は避けます。数、名詞、短い接尾辞から組み立てた文は、翻訳では別の構成が必要かもしれません。切り離した部品を手がかりなく並べ替えさせず、まとまったメッセージを作れるよう、意図した意味と文脈を渡します。

W3Cの国際化クイックヒントには、言語宣言、内容と表現の分離、組み立てる文字列への注意など、関連する基礎がまとまっています。

横だけでなく、縦の余裕も作る

幅を増やし、高さを全部固定したままにする修正はよくあります。一つのラベルには効いても、別のラベルは行数が増えると切れるかもしれません。長いタイトルが副題、操作群、次のセクションを押すなど、全体の縦の流れを見ます。

タスクが許す場所では、その伸びをページに吸収させます。大切な句が消えるより、カードが高くなるほうが害は少ないことが多いでしょう。高さを制限する必要があるなら、識別情報を残し、補足を別表示へ移すなど、代わりの動作を明示します。

実際に描画した文字の上端と下端を見ます。言葉が収まる大きさでも、アクセントや字形の一部を切る場合があります。フォント、文字体系、太さの変更で露わになります。原文のフォントのスクリーンショットでは、別の文字体系の証拠として不十分です。

すべての言語に、原文の正確な行数をまねさせないでください。保つのは階層、関係、使いやすさです。同じ意味を異なる文字で伝える結果として、セクション高や折り返しが多少変わるのは妥当です。

ローカライズと画面幅の確認を組み合わせる

デスクトップで機能する翻訳も、スマートフォンでは失敗することがあります。弱い部品を、狭い、中間、広い表示で試し、配置が変わる幅も確認します。同じ言語のまま一連のタスクを実行すれば、独立した画像では見逃す関係に気づけます。

観察は、言語とレイアウトの問題に分けます。不自然な文には言語の確認が必要です。正しいラベルが隣の操作とぶつかるなら、配置の作業が必要です。両方の場合もありますが、分類するとデザイナーと翻訳者が繰り返し差し戻し合うのを防げます。

表現と意味の最終判断には、その言語を理解する人を入れます。 話せない人でも、文字の欠け、重なり、字形の欠落は見つけられます。しかし短くしたラベルが正しい操作を伝えるかは、確実には判断できません。収まりを翻訳の承認とせず、その限界を確認記録に残します。

右から左へ読むレイアウトには、別に方向性の確認が必要です。左から右への文を長くするだけの試験では、順序、方向が混じる内容、方向を持つ操作の正しさは分かりません。すべての言語に合格したという曖昧な言い方に含めず、別の作業として明らかにします。

OpenDesignで、配置を確認して直す

OpenDesignは、HTMLプレビュー、デスクトップ、タブレット、モバイルの表示、焦点を絞った修正で、この作業を支援できます。承認済みの文を文脈として渡し、結果を見て、コメントやチャットで衝突を示せます。対応するテキストとスタイルの手動編集は、局所的な調整を試すのに役立ちます。

例えば、イベント名は行が増えてよく、日付は全文を見せ、主な操作はカードに結びつける、と指定します。配置の修正中は文を変えません。長い文字列が出るたびに全体を作り直すよう求めるより、結果を判断しやすくなります。

最終レイアウトの判断には、承認済みの翻訳を渡します。まだ必要な配置の修理が、文言の変更で隠れないようにするためです。

局所的に直したら、原文と長い内容を再び比べます。最長の例に効くルールが、短いラベルを不必要に不自然にする場合があります。よい柔軟さは、普通の文字も整い、長い文字も使え、例外処理の理由も明確な範囲を支えます。

「翻訳を受け入れる準備ができた」を定義する

役立つ引き継ぎには、弱い部品の振る舞い、試した負荷条件、確認した実際の言語を記録します。ラベル幅が固定の外部ウィジェット、まだ翻訳版が必要な画像内の文字など、未解決の制約も含めます。

曖昧な文字列には、翻訳者へ文脈を渡します。ボタンの移動先、周囲にある説明、似た操作の違いは、どれも重要です。どうしても文字数制限が必要なら、理由と、変更を判断できる担当者を示します。現在のコンテナ幅を、黙ってすべて言語側の制約にしてはいけません。