各言語に対応したテキストの簡素化

App内のテキストをローカライズすると、世界各国のユーザがそのAppを利用しやすくなります。文字列の正確な書き方やフォーマットなど、ローカリゼーションのワークフローを構築するためのベストプラクティスを紹介し、Xcodeを使って異なる言語のローカリゼーション用に文字列を準備する方法を確認しましょう。

リソース

関連ビデオ

WWDC22

WWDC21

WWDC20

Formatters：データをヒューマンフレンドリーに

WWDC19

Xcode 11でローカライズされた高品質なAppを作成する

ダウンロード

♪ （各言語に対応したテキストの合理化）こんにちはWWDCへようこそ Appleのlocalizationチームのトーマスですそして今日はローカライズされた文字列を合理化する方法をお見せします多くの言語でAppを機能させる最も簡単な方法について解説しますまずUIコードを記述します次にターゲット内の文字列を整理する方法を説明しますその後 Xcodeに手間のかかる作業を任せます最後に高度な文字列の新しいテクニックを学びますこれで私たちはあなたの Appが素晴らしい翻訳の準備がされていると保証しますテキストは私たちの生活のいたるところにあり非常に重要ですテキストを使用して会話し現実の世界で情報を入手しますそれは明らかに私たちの接続されたデバイスのすべてのApp 通知そして私たちが毎日読む記事にさらに当てはまりますこれまで以上に正確でアクセスしやすいテキストを読むことができることが重要ですこの通りですっかり迷子になりすべての看板の中から小さな店を見つけようとしていると想像してみてください Appのユーザーも同じである可能性がありますテキストはそのようなコア機能ですそれはユーザーを導き親しみやすさをもたらしますこのようにAppをローカライズすることは特にApp Storeが提供するすべての市場で世界中のすべてのユーザーに手を差し伸べる良い機会です開発者としてあなたはすでにテキストに精通しています私たち開発者は物事に名前を付けるのを楽しんでいるのでテキストを「文字列」と呼びました文字列はいたるところにあります：タイトルボタンユーザーコンテンツオンラインコンテンツ検索クエリグラフィックアクセシビリティラベル等です App内のすべての文字列を映画の字幕と考えてくださいあなたが見ている映画では適切な言語で適切なタイミングで適切なコンテキストで全編を通してすべての字幕が必要ですこれはここでもまったく同じですあなたの文字列はユーザーがApp における通りをナビゲートできるようにあなたの視覚的コンテンツに意味を伝えます開発者の観点からローカリゼーションプロセスとは何かを見てみましょうユーザーインターフェイスはビューに文字列を表示しますそれらの文字列は独自のファイルに存在しますこれによりすべての言語に共通するビジュアルコンテンツと個別の翻訳とを分けて考えることができますその間にFoundation フレームワークとユーザーインターフェイスとすべての文字列をリンクしますこのセッションではこれらの各コンポーネントについて詳細を説明しますそれはたくさんのように見えますしかし私たちはすべてを段階的に明らかにしますユーザーインターフェイス文字列を定義することから始めましょう最新のAppleテクノロジーの組み合わせでローカライズされた文字列の表示は簡単です Appでこれらのテクニックを使用することをお勧めしますローカリゼーションについて二度と考える必要がないように！ UIで定義する文字列はすべてローカライズする必要があります表示される文字列には２つのタイプがあります１つはビューを作成するときに直接定義されますここではSwiftUIとStoryboardでラベルを定義しましたはい！どちらもローカライズ可能です簡単だと言いいましたよ！２番目のタイプの文字列はより一般的で SwiftUIのモデルコード AppKitやUIKitでも見つけることができます文字列を変数に格納したりまたは関数から返したりする必要があるかもしれませんこれらすべての場合で NSLocalizedStringを使用できます iOS 15とmacOS Montereyの新機能で Swiftの洗練されたメソッド String（localized :)を使用できます SwiftUIの最初の方法に少し焦点を当てましょうインターフェイスに表示するものはすべて実際にはビューですこれがテキストラベルかボタンかデフォルトではすべてローカライズ可能ですが将来の翻訳された文字列をホストする準備ができましたこれはデフォルトで有効になっているためプレビューなどのモックコンテンツがある場合は逐語的に使用しオプトアウトするようにしてくださいこれにより翻訳者の不要な作業を回避できますこの関連セッションではより多くのテクニックを学ぶことができます基本には言及したのでこの文字列をより動的にする方法を学びましょう現在ローカライズされたボタンを注文するために表示しています私がコンサートを愛していることを知らないかもしれませんアーティストが友達と一緒にいるのをもっと見るのが好きです！このAppでは私はすべての友達のために注文しているチケットの数は明らかではありませんそれでは選択したチケットの数を含めるためそのボタンを改善しましょう簡単でした私がSwiftで慣れているように文字列に変数を挿入しましたここではカウントは実行時に実際の数３に置き換えられます今私たちが見てきたすべのオプションの（format :)の文字列のよくある落とし穴を指摘したいと思います (format :)の文字列は素晴らしいですがローカライズされた文字列に使用するためのものではありませんアラビア語の例で理由を見てみましょうここでテキストの方向と数字は異なる場合があります良いニュースとしては String（localized :)を使用する場合両方とも自動的に管理されますボタンに今数字「３」はアラビア語でのユーザーの希望する数字に応じて正しく書かれています String（localized :)は複数形もサポートし文字列の各部分の分離つまり双方向テキストでは単語がシャッフルされません最後に変数を使いすぎないように注意してください文字列を接着するのは便利ですが翻訳の問題につながる可能性がありますここで"オーダー"という言葉は今注文するのか後で注文するのかある言語では異なる書き方をします２つの別々の文字列を使用する方が安全ですいいでしょう私たちが見るべき１つの主要な最後の側面がありますそれは私が今まで密かにあなたから遠ざけていたことです定義した文字列をあなた以外の誰かによって翻訳する必要があります文字列ごとに翻訳している間翻訳者の前に完全なApp UIはないのにそれらはすべての文字列で一貫性を保つ必要がありますなのでコードコメントを追加することで同僚があなたのコードを理解するのを助けるのと同じように助けが必要なのです文字列に関係なく常にコメントを定義する必要があると私は主張しますまたStoryboardファイルでも忘れないでください IDインスペクタにコメントフィールドがあります翻訳者を支援するためのヒントをいくつか紹介しますまずコメントで文字列が表示される場所を説明する必要がありますたとえばこれはボタン？ラベル？いくつかのVoiceOverテキスト？これがアクションであるかどうかを知る-注文する- またはステートメント（注文）が重要です第二に文脈を説明する必要があります注文を押すと取引は完了しますかまたはリストを並べ替えますか？最後にコメントは変数を説明する必要があります翻訳者があなたの文字列を見るとき彼らはあなたのコードを見ないので手がかりを得るための変数の名前でなく代わりに一般的なプレースホルダーのみ表示されますしたがってここでの最後の例では「Ordered」の前の数字は何を表していますか？これは過去の注文数ですか？注文したばかりのチケットの数？はい！コメントのおかげでチケットの総数だとわかります多くの言語の翻訳者が「チケット」という言葉のジェンダーにより正しく翻訳できるようになります場合によってはコメント内の変数の値の例を書くのが最も簡単なこともありますそれを念頭に置くとこうなります UIコードをローカライズする準備ができました次に文字列とは別に UIコードを維持する方法を学習します基本的にあなたはあなたの文字列が存在する場所を整理することができるでしょうこれを行うために Foundationがどのようにコードが正しくローカライズされた文字列ファイルを確実に読み込むのかを見てゆきましょうもちろんローカリゼーションは言語から始まりますプロジェクト設定に移動して新しい設定を追加できます Xcodeを見てみましょうプロジェクトを選択しプラスボタンをクリックしますローカリゼーションを追加します最新バージョンでメニューにたくさんの新しい言語が得られているのが分かるでしょう見てみましょう... ローカリゼーションAppリストはトップのベースから始まります確かにこれはUI要素が存在する場所で言語間で共有されているからですたとえばStoryboardファイルは有されます Siri Intentsファイルも共有されます次にそれらをベースに追加する必要がありますなのですべての共有資産に対して必ずボタンをクリックしてくださいそれでOKですがその一方であなたの文字列は共有されません文字列は１つの言語に属していますだからあなたは英語での文字列とアラビア語のすべての文字列があるでしょう特定の言語の文字列を使用して Appをテストするには SwiftUIでプレビュー環境を変更またはAppスキームの設定を変更しますデバイスがAppでサポートされていない言語である場合 Foundationは最良の代替案を見つけようとします私の電話がメキシコのスペイン語の場合 Foundationはラテンアメリカスペイン語にそれからスペイン語に次にApp開発言語たとえば英語にフォールバックしようとします最後に文字列がサーバーから来る場合ユーザーの好みの言語を尊重するようにしてください素晴らしい各言語には文字列のコレクションがあることがわかりましたこれらの文字列はさらに「テーブル」と呼ばれるファイルに整理できますすべての文字列を好きなように整理するためこの機能を使用できますたとえば各機能または各画面のテーブルを作成できますこれはデフォルトではオプションなのですべての文字列はLocalizableという名前のテーブルに配置されます具体的にはこれはすべての文字列 Localizable.stringsという名前のファイル内に格納されることを意味しますこれまでに学んだことを要約し例を見てみましょう私は変数を使用して文字列を宣言しカスタマイズされたテーブル名とコメントのある次のコードを持っています私のAppがフランス語をサポートしているとしましょう Xcodeでは英語からのフランス語の翻訳が含まれている UserProfile.strings ファイルが必要になりますフランス語のリソースフォルダに保存されます慣例によりfr.lprojという名前が付けられていますコメントはフランス語の翻訳者にとって非常に役に立ちました「places」という女性名詞をマークするために「e」を使用しました ticketsのフランス語は女性名詞です少しスパイスを効かせてバンドルについて話しましょうこのパラメータによりターゲットをまたいで文字列をロードできますバンドルパラメータはデフォルトでmainですあなた自身のAppではそれを必要としません mainはそのAppです App Extensionでは mainは独自のExtensionを指しますだからそれを必要としないのですしかしAppとそのExtensionの間で文字列を共有したいとしましょう ExtensionではあなたはメインAppのバンドルを提供する必要がありますそうすることで２つの間で文字列が重複するのを防ぐことができますフレームワークから文字列を取得することもできますその場合フレームワークの文字列を直接利用するか App内のコードでバンドルを指定することでまたはフレームワークが直接使用できる変数を提供しますこれらのローカライズされた文字列変数がフレームワークでフレームワーク自体のバンドルを指定することで定義されていますモデルを振り返ってみましょう今だけ私達は私達のAppをフレームワークによって提供される文字列をロードさせるためにそれを更新しますフレームワークは文字列を定義し文字列ファイル内の独自のバンドル内に翻訳が保存されていることを Foundationに通知しますこのパラメータがないと代わりにホスティングAppから文字列がフェッチされ見つかりません実際にはこのように見えますテキストが保存されているバンドルを提供しますフレームワークは独自のバンドル内の文字列を探しますそうすればAppにとっては簡単です文字列は単純なコード行で使用できますさらにローカリゼーションを実装する場合このようにフレームワークで作成する必要はありませんここに示されている文字列ファイルにはcompleteが含まれています理由を見てみましょうコードでできることはすべて見てきました文字列を宣言して整理しますしかし実際にあなたの翻訳を保持するファイルを作成する方法は見ていません実際にそれらの文字列ファイルを作成する必要はないことがわかりました Xcodeはすべての .stringsファイル作成を処理できますエクスポートローカリゼーションを使用する場合コードを読み取りすべての文字列を抽出します文字列ファイルを維持する必要がないのでこれは素晴らしいことです文字列のローカライズを忘れていた場合 UIでコーディングしたばかりですがこれはあなたのためです genstringsに苦労している場合はこれもあなたのためです今年Xcode 13で Swift文字列抽出のコンパイラサポートを追加しましたまたワークスペースが完全にサポートされるようになりましたこれによりロジックとあなたの翻訳間の懸念がさらに分離されます XcodeはSwiftからテキストと以前に見た Foundationメソッドを検出して抽出しますカスタムコードをお持ちの場合はご注意くださいこれらのAPIをラップしますがこれはデフォルトでは機能しません通常メソッドやマクロを使用する必要はありませんしかし本当に必要な場合はそれらを文字列マクロ名の下ビルド設定に追加できます残りは XcodeはApp名をローカライズするために Info.plistで定義されているプライバシーの説明と一般にローカライズ済みとしてマークされたすべてのアセット Xcodeのインスペクタで抽出します既存のローカリゼーションがある場合はすでに新しいUI用Xcodeのエクスポートに移行できます新しい文字列は既存のファイルに自動的に追加されますこれは自分のペースでプロジェクトを変換したい場合に最適ですボーナスとしてUIテストのスクリーンショットが含まれました翻訳者に最適です文字列があるコンテキストを取得するために App StoreでのAppのローカライズされたスクリーンショットを紹介するのは素晴らしいことです Xcodeは全ローカリゼーションカタログを抽出したので今は翻訳者の番だと思うでしょう実際あなたもそれを行うことができます！ Xcode 13の新機能エクスポートされたローカリゼーションカタログこれをXcodeで直接表示および編集できます生成された各ファイルを確認できます各テーブルは左側のバンドルに含まれていますそしてあなたの選択のために含まれているすべての文字列画像ファイルを確認できます文字列のフィルタリング並べ替えコメントの表示スクリーンショットさらには翻訳！独自のAppを開発して翻訳する場合これはとても便利です文字列を自分で確認してバグ修正することもできます翻訳者が翻訳された文字列カタログを返すとそれらをXcodeの Productメニューを使いプロジェクトにインポートできますそしてどーん！あなたの文字列ファイルstringsdicts およびその他のアセットが作成および更新されます同等のコマンドラインを使用して自動化されたエクスポートとインポートを継続的インテグレーションシステムで実行できます定期的に呼び出すことでプロジェクトは最新の文字列と新しいUIを翻訳する際の迅速なターンアラウンドを取得します強化されたワークフローの動作を今年のセッション「SwiftUI Appのローカライズ」で確認できますこちらのセッションで詳細をご覧くださいそれでおしまいです！あなたは文字列がどのように生まれ App内で生きているかを見ました結論としてより複雑な文字列を処理する方法を紹介しますそして私たちが用意している新機能をきっと気に入るはずです素晴らしいものから始めましょう！ローカリゼーションが組み込まれている属性付き文字列を改善しました Markdown構文のサポートにより可能になりました！文字列をフォーマットを失うことなくローカライズできるようになったのです１つの単語を太字にするためだけに危険な文字操作をする必要はありませんそういえば完全性に重点を置くためここではアスタリスクを使用していますリンク強調等幅テキスト等々を追加する方法を学ぶには「Foundationの新機能」を確認することをお勧めします文字列ファイルに１つの翻訳があるコードで定義する１つの文字列を見てきましたしかし時々あなたは複数の表現を持つ文字列を必要としますこれは定義したルールに適応する文字列のコレクションである stringsdictファイルで可能ですたとえば例を思い出してくださいどこでチケットを注文したいですか？英語では複数のチケットがあり１つのチケットに「s」がない場合接尾辞として「s」を追加しますコードをシンプルかつ正確に保つために stringsdictを使用してこの複数形を定義する必要があります Appをローカライズするとこれらのルールは言語ごとに異なりますロシア語のいくつかのケースを見てくださいあなたはそれをコードで扱いたくないそれはむしろローカリゼーションで扱う必要がありますそれをどのように実装するか見てみましょうコードを変更する必要はなく上記の既存のコードを引き続き使用しますまずあなたのために作成されている文字列ファイルと比較して stringsdictは手動オプトインですよってXcodeテンプレートを使用して作成しますインスペクタでのクリックを確認してください大丈夫それはすべて文字列で始まりますコードで定義していますあなたはコード内の複数の文字列を複合してもってもっている場合はそれぞれをこのルートエントリをここに追加できます内部では提示される実際の値を定義しますこの値は検索置換メカニズムに従いますこの例では「チケット」という名前のトークンを１つ定義しましたそれは完全な最終文字列を保持しますトークンの中にテキストのほとんどを入れるのがベストですが翻訳者が接頭辞や接尾辞を付けたり複数の変数がありにトークンを移動させたりする必要がある場合にはそのフィールドはローカライズされます OK そのトークンはコード内の１つの変数に応じて異なります次にそのチケットトークンを定義しましょうまず複数化を行っていることを確認します次にCスタイルのフォーマッタ dで変数が数値であることを示します最後に複数のルールを書くことができます英語ではルールを「１つ」と「その他」必要に応じて「ゼロ」と宣言するだけですエントリごとにチケットトークンの実際の値を書き込みます次にチケットが３つある場合英語では「その他」を使用します％dを数値３に置き換え「３チケットの注文」を生成します言語が多くのケースを必要とする場合でも心配しないでください Xcodeはエクスポート時にそれらを追加しますロシア語では既存のものの上に少数と多くを追加しますそれでおしまいです！文字列は実行時に複数化されます先に進む前に１つのケースを指摘したいと思います stringdictは複数形に使用する必要がありますが数字を含む文字列を対象としています英語の単数形の「１つ」のケースは以前に見ましたそれは確かにロシア語でも数字の１ですただし21 や31などにも使用されますその場合stringsdictの使用は正しくありませんこの例であなたが望むのは１つだけに等しくこれや両方またはすべてによって複数形は異なります数字はありませんstringsdictは使用しないでください友達全員に21枚のチケットを予約すると想像してみてくださいロシア語で「すべてのチケットを注文する」の代わりに「このチケットを注文する」と表示されます「私のお金はどこ？」と聞きたくなります３つの文字列のそれぞれを正しく複数形にするために代わりにすべての言語でシンプルだが効果的なif / elseを使用してくださいそれが複数形のサポートですが stringsdictは多くのバリアントタイプ文字列を処理します詳細については関連するセッションをご覧くださいこれは素晴らしいですがもっと簡単な方法を提供したい Foundationは今年文法を学ぶ方法を学びました！属性付き文字列に Markdownサポートが追加されこの新しい形式を inflect属性で使用しこのボタンのように実行時に計算された正しい値を取得しますこれはiOS 15とmacOS Montereyに追加された素晴らしい新機能で現在一部の言語でご利用いただけますより詳細な制御が必要な場合は stringsdictを使用できます複数形のサポートを追加するだけではありませんソフトウェア文字列をより包括的にしたかったのですたとえばAppがユーザーを歓迎する場合英語ではかなり簡単ですしかしそれはスペイン語ではそうは行かずそれはユーザーのアドレスの用語に依存するからですこれまでパーソナライズしていない文字列の提示の必要がありましたが正しいですがほとんどのスペイン語ユーザーには堅苦しい文字通り「私たちはあなたに私たちの歓迎を与えます」です文字列をユーザー向けパーソナライズできるならどうです新しいMarkdown表記で今それをすることができます！文字列はデバイスの言語設定で選択したアドレスの用語に従いますだからユーザーのための「bienvenida」フェミニンで紹介されたい人男性的な「bienvenido」そして私たちが知らなければ既存の語尾変化の代替案を使用します複数形およびアドレス起源のインライン語尾変化がコードまたはあなたの翻訳で定義できますこの新しい言語を選択の追加に非常に興奮しています私たちはあなたのAppが使うのを見るのが待ちきれません最後に今日はすべての方法を見てきましたローカライズ可能な文字列を書くことができますしかしデータを提示したい場合はあなたは実際にフレームワークsにそれらを書くべきです私たちのフォーマッターは何百もの言語と地域そしてさまざまな種類と単位の組み合わせを処理しますだからハードコーディングしないで難しいことは任せてくださいそしてこれはSwiftでフォーマッタを採用し今年からこれまで以上に簡単になります文字列の差し込みをインラインし使いやすくしました新しいお気に入りのAPIを見つけるため今年の「Foundationの新機能」を確認してください今日見たものすべての詳細を入手してください以前のリリースを展開する必要がある場合やフォーマッタの詳細が必要な場合は昨年のセッションの確認をいいでしょう今日あなたに持って行ってほしいのは最新のAPIを使用してコードを作成する場合 Xcodeはすべての文字列を生成することですバンドル間で文字列を整理する方法を見ました文法とフォーマット作成のためのあなたにとって簡単な新しいAPIを発見しましたこれらすべてのテクニックに従うと新しい言語を追加するのにコード変更の必要はありません！最後に常にテストしますどんなに努力しても文字列をローカライズするには Appをテストする必要がありますすべての言語で正常に動作することを確認します完全にローカライズされたAppでコンサートを予約がするのが待ちきれません WWDCの残りをお楽しみくださいご覧いただきありがとうございます ♪

3:30 - Declaring a string
```
Button("Order")
```

3:44 - Declaring a string anywhere else

button.title = NSLocalizedString("Order", comment: "…")
button.title = String(localized: "Order")

4:20 - Declaring a string in a SwiftUI view 2

Text("Your order is ready.")
Button("Order") {
  // Action…
}

4:33 - Declare a string in SwiftUI view with verbatim
```
Text(verbatim: "Sample data")
```

4:54 - Button to place an order

// SwiftUI
Button("Order") { … }


// Swift
button.title = String(localized: "Order")

5:15 - Button to place an order with a variable

let count = 3


// SwiftUI
Button("Order \(count) Tickets") { … }


// Swift
button.title = String(localized: "Order \(count) Tickets")

5:36 - Button to place an order with a variable 2

let count = 3

// Supports user’s preferred numbers,
// pluralization, RTL variables isolation…
// Previously: .localizedStringWithFormat()
String(localized: "Order \(count) Tickets")

6:21 - Use 2 separate strings

// Recommended for all languages
String(localized: "Order Now")
String(localized: "Order Later")

6:57 - Button to place an order 2

// SwiftUI
Text("Order")


// Swift
String(localized: "Order")

7:09 - Button to place an order with comment

// SwiftUI
Text("Order", comment: "Button: confirms concert tickets booking”)


// Swift
String(localized: "Order", comment: "Button: confirms concert tickets booking")

7:36 - What makes a good comment

Text("Order", comment: "Button: confirms concert tickets booking")
Text("Order", comment: "Button: confirms concert tickets booking")
Text("\(ticketCount) Ordered", comment: "Order summary: total number of tickets ordered")

10:52 - Request server strings in the user's language
```
Bundle.preferredLocalizations(from: allServerLanguages).first
```

11:37 - Declare a string with a variable, customized table name, and a comment

Text("\(ticketCount) Ordered",
     tableName: "UserProfile",
     comment: "Profile subtitle: total number of tickets ordered")

13:49 - Using a framework

/* —-----------—------------—-—---- In TicketKit Framework —---------—------------—-—---- */

// TicketKit/OrderStatus.swift
public enum OrderStatus {
    case pending, processing, complete, canceled, invalid(Error)

    var displayName: String {
        switch self {
        case .complete: return String(localized: "Complete",
                                      bundle: Bundle(for: AnyClassInTicketKit.self),
                                      comment: "Standalone ticket status: order finalized")
          
/* —-----------—-----------—---—---       In Host App      —---------—------------—-—---- */

import TicketKit
Text(OrderStatus.complete.displayName)

17:43 - Import translated strings catalogs

xcodebuild -exportLocalizations -workspace VacationPlanet.xcworkspace -localizationPath ~/Documents
xcodebuild -importLocalizations -workspace VacationPlanet.xcworkspace -localizationPath ~/Documents/de.xcloc

18:28 - Localized attributed strings

AttributedString(localized: "Your order is **complete**!",
                 comment: "Ticket order confirmation title")

19:22 - Plural with stringsdict

String(localized: "Order \(ticketCount) Ticket(s)")

22:46 - Plural for strings without a number

if ticketCount == 1 {
    button.text = String(localized: "Order This Ticket")
} else if ticketCount == 2 { // If needed
    button.text = String(localized: "Order Both Tickets")
} else {
    button.text = String(localized: "Order All Tickets")
}

23:31 - Automatic grammar agreement

AttributedString(localized: "Order ^[\(ticketsCount) Ticket](inflect: true)")

25:45 - Format data in strings

["pop", "rock", "electronic"].formatted(.list(type: .or)) // pop, rock, or electronic

Text("Total: \(price, format: .currency(code: "USD"))", // Total: $9.41
     comment: "Order subtitle: total price of all tickets")

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。