症状： SwiftUIの画面に書いた文言がコードに散らばり、もう一方の言語を追加しにくい状態です。
最短の解決策： 画面の文言をXcodeのString Catalogで管理し、言語を切り替えて長い文や動的な表示まで確認します。授業のプロジェクトを構築・実行する段階では、利用できるMacとXcodeが必要です。
これから最初の画面を作る学生、既存コードの文字列を整理したい初学者、翻訳を分担するチーム向けです。
プロジェクト全体を一度に翻訳する必要はありません。まず、課題で見せる画面の文言から始めましょう。
最終確認：2026年9月26日。Xcode 27.2はベータ版のリリース情報として扱い、安定版で使える機能とは区別しています。詳しくは公式のString Catalog資料とXcode 27.2のリリースノートを確認してください。
まず提出する画面を決め、翻訳範囲を絞る
iOS 27アプリの中国語・英語対応は、課題で使う画面を選び、利用者に見える文言からString Catalogへ整理すると進めやすくなります。String Catalogは、アプリ内の翻訳対象と各言語の文言をまとめて管理する仕組みです。設定画面や説明文まで含め、初めからすべて翻訳しようとしなくてかまいません。
たとえば、授業で提出する「読書記録アプリ」なら、一覧の見出し、追加ボタン、入力欄の説明、保存後のメッセージから着手できます。データベースの内部名やログまで翻訳するのではなく、アプリを使う人が画面で読む文字を優先します。
| 学習者の状態 | 先に行うこと | 後回しにできること |
|---|---|---|
| 新しくSwiftUI画面を作る | 画面上の見出し、ボタン、案内文をCatalogで管理する | 課題に出ない画面や内部処理 |
| 文字列がコードに点在している | 利用者に見える固定文言を洗い出して置き換える | 変数名、デバッグ用ログ |
| チームで翻訳を分担する | 文言に画面・用途・状況の説明を添える | 文脈のない一括翻訳 |
「SwiftUIのローカライズはどう始める？」への答えは、まず表示文言を見つけ、言語ごとの翻訳をCatalogにそろえることです。複数言語への対応方法では、アプリの言語設定や翻訳リソースを含む基本的な考え方が案内されています。
既存のコードから画面の文言を拾い出す
SwiftUIでは、通常の画面表示に使うテキストがローカライズ対象として抽出される場合があります。ただし、コード内のあらゆる文字列が自動で翻訳一覧に入るわけではありません。表示方法や文字列の組み立て方によって、対象として認識されないことがあります。抽出の条件はXcodeのString Catalogガイドで確認してください。
Xcodeに入らない文言があったら、まずコード上の場所と使われ方を確認します。ユーザー向けの固定文言なら、ローカライズ可能なテキストとして扱われているかを見直します。アプリのデータ値、変数、開発者向けのログを、表示文言と同じ扱いで置き換える必要はありません。
手作業で異なる言語の文をつなぐ方法は避けましょう。語順や助詞の位置が言語によって異なるためです。たとえば「こんにちは」と名前を別々に翻訳して結合するのではなく、文全体をCatalog側で管理します。文言の準備と翻訳対象の整理については、翻訳用テキストを準備する公式資料も参考になります。
数量や動的な値を文の単位で扱う
「保存した項目数」のように、表示する値が変わる文は、固定の見出しより確認が必要です。数値と単語をコードで別々に用意してつなぐと、言語ごとに必要な語順や単数・複数の形を表現しにくくなります。文脈を含めた単位でローカライズし、Xcodeが提供するCatalogの形式に合わせて管理してください。
| 表示する内容 | 避けたい方法 | 確認のしかた |
|---|---|---|
| 数量を含む文 | 数字と翻訳済みの単語をコードで連結する | 異なる数量を表示し、文章全体が自然か確認する |
| 名前などの動的な値 | 文字列の一部を場当たり的に置き換える | 値が長い場合も文全体とレイアウトを見る |
| 固定のボタン名 | コード内の文字列をそのまま放置する | 各言語のCatalog項目と実際の表示を照合する |
動的な値が入る場合は、値が空のときや長いときも試してください。翻訳がそろっているように見えても、実行時の表示が画面からはみ出すことがあります。見た目の確認には、アプリ実行時のローカライズテスト資料を使えます。
注意：Catalogに翻訳項目があることは、アプリの言語切替が正しく動く証明ではありません。実際にアプリを実行し、別の言語で画面を確認してください。
翻訳を分担し、受け渡し前に情報を添える
グループ課題では、翻訳する文字だけを渡すと、同じ文でも画面によって意味が違う場合に判断できません。「追加」はボタンなのか、説明文の一部なのか、といった用途を一緒に伝えます。画面名、表示場所、文字列の目的を短く記録しておくと、翻訳担当者が文脈を把握しやすくなります。
Xcodeにはローカライズをエクスポートする手順が用意されています。作業前に対象言語と共有ファイルを確認し、翻訳を戻した後はCatalogに反映された内容と実際の画面を見比べましょう。操作の概要はローカライズを書き出す公式資料で確認できます。機械翻訳の文章は下書きには使えても、意味や画面上での自然さまで保証するものではありません。
Macがあるかどうかで練習の進め方を選ぶ
「手元にMacがない場合でもSwiftUIの多言語学習はできる？」学習の一部は進められますが、XcodeでiOSアプリを構築し、実行して表示を確認する作業には、対応するMac環境が必要です。Xcodeの利用条件は更新されることがあるため、作業前に公式のシステム要件を確認してください。
Macが使えない間は、翻訳対象の洗い出し、画面ごとの文言表づくり、複数言語での文章の見直しを進められます。実際の抽出、ビルド、言語切替後の表示確認は、Xcodeを使える環境に移ってから行います。
- 授業や学校で使えるMacがあり、課題のビルドまで行える場合は、学校の利用ルールとXcodeの要件を確認して使います。
- Macはないものの、オンラインで開発環境を利用でき、ネット接続中に作業できる場合は、遠隔のMacを検討します。
- すぐにXcodeを使えない場合は、翻訳する文言と画面の説明を先に整え、実行確認はMacが使える時点まで保留します。
- Xcodeの要件を満たすMacをすでに持ち、継続的に重い作業をする場合は、自分の環境を使うほうが都合のよいこともあります。
オンラインのMacは手元に機器を用意せずに試せる一方、通信が切れれば作業を中断することがあります。入力の遅れやファイルの受け渡し、学校のアカウントやデータを扱う際のルールも確認しましょう。購入して使う方法と費用や利用条件を比べるなら、Mac miniを用意する場合の案内も参照できます。MACCOMEの利用を検討する場合は、利用環境の案内で内容を確認し、課題の期間や必要な作業に合うか判断してください。
提出前に言語を切り替えて画面を確認する
最後は、翻訳リソースの有無ではなく、動作中の画面で確認します。次の順番で進めると、文字が欠ける問題や翻訳漏れを見つけやすくなります。
- 画面に表示する固定文言をCatalogで確認し、翻訳が空の項目を整理します。
- アプリの基本言語で起動し、見出し、ボタン、入力欄、完了メッセージを確認します。
- 別の対応言語に切り替えて再実行し、翻訳が反映されているかを見ます。
- 長い説明文や、名前・数量などを含む動的な表示を確認します。
- 文字の切れ、重なり、ボタンからのはみ出しがあれば、文言や画面レイアウトを調整します。
- チーム作業なら、翻訳ファイルの受け渡し後にも同じ画面を再確認し、未反映の項目を記録します。
提出前の判断はシンプルです。両方の言語で画面が実際に表示され、長文と動的な表示も読めるなら提出候補にできます。どちらかの言語で未翻訳の文言やレイアウト崩れが残る場合は、Catalogの存在だけで合格と見なさず、該当箇所を直して再実行してください。
使う環境を課題の条件に合わせる
学校のWindows端末だけで学ぶ場合、コードの読み書きや翻訳文の準備は進められます。しかし、Xcodeを使う工程を後回しにすると、文字列の抽出漏れや実際の画面崩れを提出直前まで発見できないおそれがあります。課題にビルドや実行確認が含まれるなら、締切より前にMacを使える時間を確保しましょう。
すでに継続してMacを使え、長期間の学習や重い作業が中心なら、自分で環境を用意するほうが合う場合があります。一方、授業作品を短期間だけ構築・確認したいのにMacがない場合は、学校の貸出環境や遠隔のMacを比較できます。学校のPCは追加ソフトを入れられないことがあり、個人所有の環境は購入費や管理の負担が生じます。遠隔利用にも通信や入力の制約があるため、作業内容と利用期間で選んでください。
SwiftUIの文言をString Catalogで管理し、言語を切り替えて長文と動的な表示を確認するのが、課題を仕上げる基本です。手元にMacがなく、授業で実際のビルドと確認が必要なら、まずMACCOMEの遠隔Mac利用案内を確認し、課題期間に合う場合だけ選択肢に加えてください。