WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Build localization-friendly layouts using Xcode

Build localization-friendly layouts using Xcode

WWDC 2020XcodeLocalizationAuto Layout
元の動画を見る

ハイライト

Xcode 12 は、擬似言語プレビュー、ランタイム言語選択、自動レイアウト ローカリゼーション警告、グリッド ビュー/スタック ビュー修復プロセスを文字列化して、開発者が翻訳が完了する前に長いテキスト、ダイナミック フォント、右から左へ記述する言語によって引き起こされるレイアウトの問題を発見できるようにします。

主要内容

多くのチームが初めてローカリゼーションを行うとき、最初に扱うのは文字列ファイルです。多くの場合、インターフェースのレイアウトはそのまま残されます。問題は、翻訳者がアプリに入ると、最初に配置されていたボタンが切り取られ、元の固定幅の入力ボックスがウィンドウをバーストし、アラビア語インターフェイスでも左から右へのみ設計された一連の制約が表示される可能性があることです。

このセッションは早い時点から開始されます。UI をチェックする前に翻訳が完了するのを待たないでください。 Paul Borokhov は、開発者が倍長擬似言語を使用して最初に各コントロール内のテキストを長くし、次にアラビア語などのランタイム言語を使用してインターフェイスが反転されているかどうかを確認できることを Xcode で実証しました。このように、問題は翻訳者やテスト チームに納品した後ではなく、開発段階で発生します。

Apple が提供する解決策は、言語ごとにレイアウトを手動で調整することではありません。主なアプローチは、コントロールをコンテンツの自然なサイズに依存させ、テキストの折り返しを許可し、固定幅を最小幅に変更し、コントロールのグループをスタック ビューまたはグリッド ビューの管理に引き渡すことです。 Xcode 12 のプレビュー、スキーム オプション、自動レイアウト修正、埋め込み操作が連携して動作するため、開発者は同じ設計プロセスでこれらの問題を修正できます。

これは、ローカリゼーションが最も過小評価されている場所でもあります。これは翻訳の問題のように見えますが、実際には UI の柔軟性の問題です。テキストの幅、間隔、または 1 行が英語のインターフェイスにハードコーディングされている限り、新しい言語は隠れたレイアウトの前提条件を明らかにするだけです。

詳細

最初に固定幅を削除し、テキストが独自のスペースを決定できるようにします。

(00:39) セッションは、クロスプラットフォーム ルールをリストすることから始まります。テキストを含むコントロールには固定幅または固定フレームを使用しないでください。手書きレイアウトを呼び出すことを忘れないでくださいsizeToFit, 自動レイアウトはテキスト コントロールに固定幅の制約を追加すべきではありません。また、SwiftUI はテキスト ビューの明示的なフレームをハードコーディングすべきではありません。

文本控件布局检查
  -> manual layout: 调用 sizeToFit
  -> Auto Layout: 删除固定 width，或改成 greater than or equal
  -> SwiftUI: 不给文字视图设置只适合英文的 explicit frame
  -> UILabel: 将 number of lines 设为 0，允许翻译后换行

キーポイント:

  • sizeToFitトランスクリプトの手動レイアウト提案に対応して、コンテンツはコントロール サイズの計算に使用されます。 -number of linesiOS デモでは 0 に設定すると、UILabel はデフォルトで 1 行になり、2 倍の長さの擬似言語ではテキストが切り詰められます。
  • 固定幅の制約を削除したり、「以上」の最小幅に変更したりできます。
  • SwiftUI シナリオでも同じ原則: テキスト コントロールを英語のみに適した明示的な幅にロックしないでください。

(01:17) 固定間隔によって問題が発生する場合もあります。デモでは、[公開] ボタンと [キャンセル] ボタンの間に大きな空白があります。英語は正常に見えますが、ギリシャ語の翻訳が長くなると、ウィンドウ全体が引き伸ばされます。翻訳に伴ってウィンドウ サイズが大きくなるのではなく、ボタンが空白を消費するようにする方が良いでしょう。

Publish button  >= flexible space >=  Cancel button
Fixed width     -> greater than or equal minimum width
Fixed gap       -> Stack View or flexible constraint

キーポイント:

  • レイアウトを維持するために、リモコン間の固定空白スペースに依存しないでください。 -greater than or equal制約は最小サイズを維持しながら、より長い翻訳の拡張を許可します。
  • スタック ビューは、コントロールのグループ間の柔軟な分散を管理できます。
  • このタイプの修正はビジネス ロジックを変更するものではなく、レイアウト レベルで英語の長さの仮定を削除するだけです。

擬似言語プレビューを使用して、翻訳なしでストレス テストを作成する

(03:07) 最初の iOS デモでは、ドキュメント プレビューが開き、Double Length Pseudolang が選択されます。タイトルと通常のタグを使用すると、改行を許可する必要があるという問題がすぐに明らかになります。ラベルを修正した後もボタンが切り取られたままだったので、レイアウトが水平方向のボタンのグループから、十分なスペースがない場合に垂直方向に切り替わるスタック ビューに変更されました。

Document Preview
  -> English
  -> Double Length Pseudolanguage
  -> inspect labels and buttons before real translations exist

キーポイント:

  • ドキュメント プレビューはビルドして実行する必要がなく、ストーリーボードや XIB の視覚的な変更を迅速に確認するのに適しています。
  • Double Length Pseudolang は、コントロールとラベルのテキストを長くして、より冗長な言語をシミュレートします。
  • ラベルを修正するときは、改行を許可することに重点を置きます。ボタン グループを修正するときは、幅が狭い場合に代替レイアウトを提供することに重点を置きます。
  • 講演者は、翻訳者が文字列の目的を理解できるように、Identity Inspector のローカライザー ヒントのタイトル テキストにコンテキストも追加します。

(04:03) ボタン グループを交互に配置するには、ランタイム コードが参加する必要があります。スピーカーはボタンを水平スタック ビューに配置し、そのレイアウトに適合するサイズをクエリします。十分なスペースがない場合は、向きを縦に変更してください。このカスタム クラスは作成されています。デモでは、ストーリーボードにクラスを設定し、スタック ビューの先頭の制約を接続するだけです。

Horizontal Stack View
  -> query layout fitting size
  -> if content no longer fits
  -> switch orientation to vertical

キーポイント:

  • ここには公式のコード スニペットはありません。セッションでは実装戦略が強調されています。 -layout fitting size現在のコンテンツが現在の幅に収まるかどうかを判断するために使用されます。
  • 方向の切り替えにより、倍長または狭い画面のデバイスで 4 つのボタンが同時に切断される問題が解決されます。
  • 大きなフォントと狭い画面でも同様の圧力がかかるため、このロジックはダイナミック タイプにも役立ちます。

実行時検証にスキーム、アクセシビリティ インスペクター、および環境オーバーライドを使用する

(04:59) プレビューでは問題の一部しかカバーできません。ボタン グループの方向切り替えはコードの動作であり、ビルドして実行する必要があります。 Xcode のスキーム エディターでは、オプションで倍長擬似言語を選択し、Command-Control-R を使用してビルドされたバージョンを再起動し、ランタイム レイアウトを確認できます。

Scheme Editor
  -> Run
  -> Options
  -> App Language
  -> Double Length Pseudolanguage

キーポイント:

  • Scheme オプションにより、ランタイムに疑似言語が導入され、コード駆動型のレイアウト変更のテストが可能になります。
  • Command-Control-R は、同じビルド製品を繰り返し検証するのに適した、既にビルドされたバージョンを再起動するために使用されます。
  • デモ内のラベルは正しく折り返され、スタック ビューは期待どおり垂直方向に切り替わります。
  • 同じインターフェイスは、第 1 世代の iPhone SE およびより大型のダイナミック タイプでも、より厳しいレイアウト条件をトリガーします。

(05:23) ダイナミック タイプは、ローカライズされたレイアウトに対するプレッシャーの原因でもあります。スピーカーは、第 1 世代の iPhone SE を使用して、アクセシビリティ不可の最大フォント サイズを増やすテストを行ったところ、英語のテキストでもボタン グループが縦方向に切り替わりました。次に、アクセシビリティ インスペクターと Xcode の環境オーバーライドを使用して、デフォルトのフォント サイズに戻し、レイアウトを水平に戻します。

Accessibility Inspector / Environment Overrides
  -> change Dynamic Type
  -> verify stack view orientation and text wrapping

キーポイント:

  • フォントが大きく、翻訳が長いと、テキストが占めるスペースが大きくなります。
  • 画面の小さいデバイスでは、ボタン グループ、フォーム、ナビゲーション バーの混雑の問題が事前に明らかになる可能性があります。
  • Accessibility Inspector は、デバイスの接続時に動的タイプを迅速に調整するのに適しています。
  • 環境オーバーライドは、これらの環境変更を Xcode デバッグ プロセスに組み込みます。

自動レイアウト修正とグリッド ビューで macOS フォームを修正する

(07:21) 2 番目のデモは、自動レイアウト制約のない macOS XIB です。 Xcode はドキュメントのサイドバーにローカリゼーションの問題を表示します。 Double Length Pseudolang をオンにすると、コントロールは長いテキストで拡大されなくなります。アラビア語を実行した後、UI が反転しません。

Resolve Auto Layout Issues
  -> Add Missing Constraints for all views in the window
  -> Remove Constraint for unnecessary fixed width
  -> Set Constraint to Greater Than Or Equal To A Minimum Width
  -> Fixed Leading and Resizing Trailing Constraints

キーポイント:

  • 不足している制約の追加では、最初に基本的な制約のセットを追加できますが、完全にローカライズされたレイアウトが自動的に取得されるわけではありません。
  • [公開] ボタンの固定幅を保持する必要はなく、修正して直接削除できます。
  • [OK] ボタンには最小幅が必要です。これは 70 に固定するのではなく、それ以上に変更する必要があります。
  • 2 つのボタンが重ならないように、右側のスペースを公開とキャンセルの間で柔軟に変更できるようにする必要があります。

(09:38) フォームの上部はスプレッドシートのように見えます。左側にラベル、右側にテキストフィールドとチェックボックスがあります。講演者は単一の制約をスタックし続けるのではなく、テキスト フィールドとチェックボックスを選択し、[埋め込み] をクリックして、[グリッド ビュー] を選択しました。グリッド ビューは内部レイアウトを引き継ぎ、外側のレイヤーはグリッド ビューをウィンドウ コンテンツ ビューに制限するだけで済みます。

Embed In
  -> Grid View
  -> constrain Grid View top / leading / trailing / bottom
  -> merge first-row cells
  -> move checkbox to second column

キーポイント:

  • グリッド ビューは、行と列が明確な macOS フォームに適しています。
  • 内部コントロールをグリッド ビューに配置した後、各コントロールの外部制約を手書きする必要はなくなりました。
  • 上部のヘッダーは、セルの結合を介して 2 つの列にまたがることができます。
  • チェックボックスをターゲットセルに直接ドラッグして、実際の視覚的な関係を構造に反映させることができます。

(11:50) グリッド ビューでもプロパティを設定する必要があります。テキストが含まれる場合、行の配置は最初のベースラインに設定されます。 xPlacement は Fill に設定されます。 spacing は、行間隔 12 と列間隔 8 に対応する標準間隔を使用します。次に、名前ラベルと説明ラベルの水平方向の優先順位を 749 に設定し、最初の列が必要な幅のみを占めるようにします。

Grid View attributes
  row alignment: First Baseline
  xPlacement: Fill
  row spacing: 12
  column spacing: 8

Labels
  horizontal hugging priority: 749

Grid View
  vertical content hugging priority: 600

キーポイント:

  • 最初のベースラインはベースラインに従ってテキスト行を配置し、フォームを読みやすくします。
  • Fill を使用すると、コンテンツが利用可能な水平方向のスペースを使用できるようになります。
  • 標準の間隔は、現在の言語にのみ適したハードコーディングされた値として間隔を書くことを避けるためのヒューマン インターフェイス ガイドラインに基づいています。
  • 749 は、ラベルのデフォルトの圧縮優先度 750 より低く、優先度 500 を保持するウィンドウより高いため、最初の列は最初にテキストを圧縮せずにラベルに貼り付けられます。

最後に、テストのために母国語ユーザーを見つける必要があります。

(13:32) 自動検査では、サイズ、切り詰め、反転などの機械的な問題のみが検出されます。セッションの最後では、ネイティブ テスターは別の種類の問題、つまり一貫性のないシステム用語、文脈から逸脱した翻訳、非ネイティブ開発者には分からない特定の切り捨てや切り取りなどの問題を見つけることになると強調しました。

Before release
  -> run pseudo language checks
  -> run right-to-left language checks
  -> test Dynamic Type and small devices
  -> ask native speakers to review real localizations

キーポイント: ・擬似言語はレイアウトを事前に修正するのに適しており、実際の翻訳の品質を保証するものではありません。

  • 右から左へ記述する言語では、制約、アイコンの方向、ウィンドウの配置を反転できることを確認するために、実際の実行時検証が必要です。
  • 新しい言語を追加したり、UI を全面的に見直したりする場合、母国語のテストが最も重要です。
  • ローカリゼーションは新しい市場のユーザーに第一印象を与え、レイアウトの品質は信頼に直接影響します。

重要ポイント

  • やるべきこと: すべての主要なストーリーボードと XIB の疑似言語チェックリストを作成します。 実行する価値がある理由: Xcode ドキュメント プレビューは、翻訳ファイルがない場合でも長いテキストをシミュレートし、固定幅と単一行のラベルを事前に公開できます。 開始方法: プレビューを開き、倍長擬似言語に切り替え、切り捨てコントロールを 1 つずつラップ可能、拡張可能、またはリフロー可能に変更します。

  • 対処方法: ボタン グループとツールバー用に狭いスペースを準備します。 実行する価値がある理由: セッション内の 4 つの水平ボタンは 2 倍の長さの小さな画面では切り取られ、スペースが不十分な場合はスタック ビューを垂直方向に切り取ることができます。 開始方法: まずスタック ビューに同様のボタンを配置し、次にレイアウト フィット サイズを使用してコンテンツが収まるかどうかを判断し、収まらない場合は軸を切り替えます。

  • 何をすべきか: macOS フォームをグリッド ビューに移行します。 実行する価値がある理由: 列形式で単一の制約を使用すると、維持コストがかかります。グリッド ビューでは、セル、ベースライン、間隔、列幅を管理できます。 開始方法: 関連する入力コントロールを選択し、[埋め込み] > [グリッド ビュー] を使用して、最初のベースライン、塗りつぶし、標準間隔、および適切なハグ優先順位を設定します。

  • やるべきこと: ローカライズされたレイアウト テストにダイナミック タイプを組み込みます。 価値がある理由: 大きなフォント サイズと長い翻訳は両方ともテキストの領域を拡大し、同じ種類の切り詰めを引き起こす可能性があります。 開始方法: アクセシビリティ インスペクターまたは環境オーバーライドを使用してフォントを変更し、小さな画面のシミュレーターを使用して同じインターフェイスを実行します。

  • 何をすべきか: 翻訳者にローカライザー ヒントを書きます。 実行する価値がある理由: デモのタイトル タグは、Identity Inspector を通じてコン​​テキストを追加し、翻訳者が文字列の目的を誤解する可能性を減らします。 開始方法: ボタン、タイトル、ステータスのコピーを確認し、意味が曖昧になりやすい文字列にローカライザー ヒントを追加します。

関連セッション

コメント

GitHub Issues · utterances