☆国際化プログラミング
これは、 国際化プログラミングトピック をiOS＆Xcode4用に翻訳(かなり意訳)・手入れしたものである。
リソースプログラミングガイド;「文字列リソース」とかぶる部分は削除した。 そちらも併せて読むということで。

概要

今日のアプリケーションは全世界のユーザーに販売される。 あなたのアプリケーションをそのユーザーに売るには、標的市場ごとにあなたのソフトウエアのカスタマイズを必要とする。
外国のユーザーは、彼らが理解しない言語でのユーザーインターフェースを望みそうでない。 同様に、あなたは受け入れられるが、他の文化において失礼と思われる画像があるかもしれない。 問題は、あなたが理解しない言語でソフトウエアをどのように作るかである。 その答えは iOSにある国際化技術に見つけられる。

あなたが、サポートを望む言語毎にあなたのソフトウエアを書き直すよりはむしろ、 どんな言語もサポートするように、それを国際化することが出来る。
この工程には、ユーザーが見える全てのテキストと画像を実行可能コードから切り離すことが必要である。 一旦あなたがこのデータを別々のリソースファイルに分離したならば、 それを望ましい言語に翻訳することが出来て、 ローカライズされたリソースファイルをあなたのアプリケーションのバンドルにまとめることができる。 この文書は、これらの工程を、あなたのアプリケーションに準備するために必要なステップを理解するのを手助けする。

ちなみに、私の作っているアプリは、日本限定でないと使えないアプリはないので全て日英対応している。 実際、販売の半分は日本以外である。逆に言えば、英語対応しなければ販売量は半分になるわけで、 ならば苦労してでも英語対応する価値があると言うものである。 もっとも、全部合わせたって量はほんとうにしれてるけど。

ここだけの話、アプリの感想でも日本人は文句しか言わないから、辟易している。 何で建設的に意見が言えないかねぇ。あれは意見じゃ無くて単なる文句。 感情をぶつけるだけじゃ何も解決しない。どこが分からないのか、どこが悪いのか、どこをどうして欲しいのかはっきり言え。 全く幼稚で無駄。ということで、日本のメッセージは一切見ないようにしてる。 海外からはそうでも無いんだけどねぇ。
日本人は意見のし方を「国際化」しなきゃいけないんじゃないかと強く思う、今日この頃。

国際化とローカライズ

国際化は、ローカライズを容易にするために、アプリケーションを設計し作る工程である。
ローカライズは、国際化されたアプリケーションの、2つ以上の文化的に異なった市場への文化的、言語的の適合である。
十分ローカライズしたアプリケーションを起動するとき、 ユーザーはそれを、完全にくつろぎ、他の国で作られたように感じないだろう。

国際化とローカライズは補完的である。 アプリケーションを国際化することによって、ローカライズした内容のサポートが必要なプログラム基盤を作成する。 そのアプリケーションをローカライズすることによって、異なる文化の人々のためにカスタマイズされるリソースを追加する。 しばしば、アプリケーションをローカライズすることは、アプリケーションのユーザーの見えるテキストを翻訳することを含むが、 それはしなければならない作業の一部である。 あなたのアプリケーションは他の部分も修正されなければならない。 iOSアプリケーションの国際化の工程は、簡単で、どのデバイスでも同じである。
アプリケーションのバンドルディレクトリの中では、アプリケーションの実行可能コードを含んでいる1つのファイルと、 ローカライズしたリソースを含んでいる多くに分割されたファイルがあるかも知れない。

単一のローカライズのためのリソースファイルは、一緒に言語に特有のプロジェクト・ディレクトリに保存される。 それは、言語名.lprojというディレクトリである。 バンドルは、多くの言語に特有のプロジェクト・ディレクトリを含むかもしれない、 それぞれ１つづつが、アプリケーションがサポートするローカライズを意味している。 あなたは、同じバンドル内で、1バイト言語と2バイト言語のローカライズ化を一緒に記録することも出来る (例えば英語と日本語)。

国際化されたアプリケーションの開発の第一歩は、あなたのアプリケーションで、すべての文化に特有の情報を識別することである。 あなたのユーザーインターフェースから文化に特有のテキスト、画像、音声を探し、 それらをリソースファイルに入れる。
それらをリソースファイルから必要とするデータを読み込ませるように、プログラムを変更する。 あなたがプログラムを精査して、ユーザーインターフェースが日付、時間、通貨値を表示する場所を探し、 現在のロケール情報を使ってそれらをフォーマットしていることを確認しなければならない。

あなたのアプリケーションのユーザーインターフェースが固定出来たなら、あなたはそれをローカライズし始めることができる。 それぞれのローカライズにつき、ローカライズ・チームは、nibファイル、テキスト、画像、音声ファイルの言語に特有のバージョンを作成する (いや、そんなチーム構成にしてみたいわ。全部1人でやってるとそれはそれは大変な作業であることよ) 。 あなたのアプリケーションがきちんと国際化されたものであるならば、この工程はソースコードに修正を必要としない。 したがってあなたは、社内で翻訳を作ることができるか、外部のローカライズ・サービスと契約を結ぶことができる。

たとえあなたがすぐに複数言語のサポートを計画をしないとしても、 前もってあなたのアプリケーションを国際化していることは良い考えである 国際化サポートをあなたのアプリケーションに組み入れることに対する処理的負荷もない (いや、全くないことは無いと思う。軽微だとは思うけど。開発負荷はかなり高くなるけど) 。
たとえあなたのアプリケーションが１か国語しか使わないとしても、 あなたはまだ、すべての利用できるコード・パスをテストする必要がある。 プログラムがきちんと1つの言語のための国際化されたのであるならば、他の言語のサポートにさらにほとんどテストを必要としない (そんなことはない。特に表示文字列長が変わることにレイアウトの変更はちょっちゅうである) 。 そのうえ、実行可能なファイルの外にリソースを保存することは、 基礎をなすプログラムを修正することなく、後であなたのアプリケーションの外見を変えることを、より簡単にする。

国際化のサポート

様々な方法で、iOSは国際化とローカライズした内容をサポートする。 選択された言語セットの概念とバンドルの機構、ローカライズされたリソース、 そして実行時バインディングがこのサポートの背後にある。

ユーザーはどのように言語初期設定を指定するか

ユーザーは、iOSの設定から、見たい言語を指定する。 図1は、iOSで言語選択を選ぶのに用いられるインターフェースを示す。

図 1 iOSでの言語選択


ここで以下の操作で望む言語を選ぶ。 
    一般 > 言語環境 > 言語
    (英語版では一般 > International > Language)
なぜならば、iOSデバイスは1ユーザーのみ、同時1言語のみ選択をサポートするからである。

システムは、ユーザー毎のデフォルトとしてAppleLanguagesキーの下に、言語のリストを保存する。 しかし、あなたが直接このキーの値を取り出すことを勧めない。 データベースで見つかるプログラムは、言語またはロケールIDの基準形式を含まないかもしれない。 代わりに、NSLocaleクラスのpreferredLanguagesメソッドまたはCFLocaleCopyPreferredLanguages関数を使う。

あなたのアプリケーションがそのバンドルディレクトリでリソースファイルにパスを要請するとき、 バンドル・インターフェースは、ローカライズがユーザーの選んだ言語と最も密接に一致するリソースを検索する。 バンドル・インターフェースはFoundationフレームワークのNSBundleクラスから成る。 そして、Core FoundationではCFBundleRefをサポートする関数から成る。

これらのインターフェースは、 あなたのアプリケーションのバンドルディレクトリの中にリソースファイルを見つけるためのサポートを提供する。 そのディレクトリを捜すとき常に、カレントユーザのために最適であるローカライズしたリソースを返す。 ローカライズがユーザーの選択した言語のために存在しないならば、 検索は(必要に応じて)ユーザーの選択した代替言語を使い続ける。 どのバンドルのローカライゼーションも利用者の選択と一致しないならば、 インターフェースは、ソフトウエアの開発時に使われた、ローカライズと関連したリソースを返す。

ユーザーはどのようにロケール初期設定を指定するか

ロケール指定は、日付、時刻と数字を表示する方法のために、地域の違いを伝える。 図2で示すように、iOSは多くの世界地方のためにあらかじめ定義されたロケールを指定する。 iOSでは、ユーザーは望ましい地域だけを選ぶことができる。

図 2 iOSでのロケール指定


ほとんどの場合、あなたのプログラムは、適用されているロケール指定について心配する必要は全くない。 大部分のAPIは、ロケールによって変わるデータを得るかフォーマットするとき、 アカウントの中にユーザー指定を取りに行く。
しかしながら、あなたがロケール情報を得る必要がある状況が、まだあるかもしれない。 たとえば、現在のロケール設定を表示する、異なるロケールの比較をする、現在のロケールより他のロケールを特定のデータに適用させる、等である。 それらの状況では、FoundationフレームワークはNSLocaleクラスを提供する。 そして、Core Foundationフレームワークは CFLocaleRef opaque型 をロケール情報を取り出すために提供する。

バンドル

アプリケーションバンドルは、ディレクトリである。 それは、アプリケーションの実行可能バイナリと関係する全てのリソースファイルを含む。 iOSはメインバンドルのみだけサポートする。
バンドルは、それらをより管理可能にするためにソフトウエアの複雑な部分をまとめる方法を提供する。 バンドルディレクトリは、アプリケーションを走らせるために必要な全てのファイルのための、トップレベルのコンテナの働きをする。 そのディレクトリの内側の構造は、プログラムとリソースを切り離して、見つけることをより簡単にする方法で組み立てるのに用いられる。
注：
プログラム内で、NSBundleオブジェクトまたはCFBundleRef opaque型に言及するとき、「バンドル」という用語も使われる。 これらの型はバンドルディレクトリのプログラムに基づいた表記で、バンドルの中にファイルを見つけるのに用いられる。

複数言語のためのリソースファイルが、どのように単一のアプリケーションバンドルに保存されかについて理解するために、 アプリケーションの基本的なバンドル構造を学ぶ時間をとることは価値がある。 リスト1は、2、3のローカライズしたリソースファイルを含むiOSアプリケーションの部分的な構造を示す。 左のテキストがバンドル内でのディレクトリとファイルを識別する。 一方で、右の説明はキー項目の目的を示している。 
リスト 1 iOS メインバンドルの構造

MyApp.app
    MyApp
    MyAppIcon.png
    MySearchIcon.png
    MyApp-info.plist
    Default.png
    MainWindow.xib
    Settings.bundle
        en.lproj
            Root.strings
        ja.proj
            Root.strings
        Root.plist
    MySettingsIcon.png
    ja.lproj
        Localizable.strings
        SetupViewController.xib
        InfoPlist.strings
    en.lproj
        Localizable.strings
        SetupViewController.xib
        InfoPlist.strings
この構造からわかることとおり、国際化されたアプリケーションは１つの.lprojディレクトリを、サポートする個々のローカライズのために必要とする。 ディレクトリは、それらが含む言語タグ(IETF language tag)よって名付けられる。 デフォルトでは、プロジェクト・ディレクトリは、あなたがアプリケーションを開発するために使っている言語と一致している単一の言語ディレクトリだけを含む。

あなたは、開発言語ディレクトリのファイルを簡単にコピーすることが出来て、それらを翻訳することが出来たが、 新しいローカライズしたリソースファイルを作る選ばれた方法は、Xcodeを使用することである。 ファイルを選んでUtilitiesビューを開けると、File inspectorの中に「Localize...」ボタンがある。
リソースファイルのためにこのボタンをクリックすることは、 Xcodeに、ビルド時に言語に特有のプロジェクト・ディレクトリで、最初のリソースファイルのコピーを置かなければならない、と告げる。 各々のコピーは、リソースファイルの最初の内容に基づく。 翻訳者がファイルをローカライズして、最初のファイルを、新しく翻訳されたバージョンと入れ替えるてプロジェクトを作り直すことができる。
Xcode 3.xではJapanese.lproj/English.lprojとか言う名前だったが、Xcode4.xでja.lproj/en.lprojに変わった。 そのため、Xcode3時代から開発を続けているプロジェクトの場合、Xcode4上ではローカライズが正常に働かないという状況になる。 その場合、
  1. Xcodeを完全に終了する
  2. Englishlproj/Janapese.lprojをenlproj/jp.lprojに変名する
  3. プロジェクト名.xcodeproj/project.pbxprojをテキストエディタ(相当)で開く
  4. Englishlproj/Janapese.lprojと書かれている部分をenlproj/jp.lprojに書き換える
とすると正常になる。

アプリケーション・バンドルには、ローカライズを必要とするいくつかのリソース種類がある。 ローカライズ時に、あなたはローカライズ・サービス、または、あなたの企業内翻訳部に元の言語の.lprojフォルダを送る (たとえば、英語を話す国々の開発者のためにはen.lproj)。 あなたは、ローカライズ者が適当な翻訳を確実にするために、ユーザーインターフェース要素に コンテキスト内にリソースを動的に読み込ませて表示するに十分な面積を確保するために、 コンパイル済みのアプリケーションも送る必要がある。 各々の目標言語のために、翻訳者は、適切にローカライズされた各々のリソースファイルの入った.lprojフォルダを送り返す。

ローカライズ・チームによってリソースファイルを編集するのに用いられるツールは、リソースの種類によって異なる。 nibファイルは、一般に、Xcode内IBを使って編集される。 他のリソースファイルは、適切なエディタで編集することができる。

バンドル、バンドルの構造(アプリケーションの構造も含む)、リソースを見つけるためにどのようにバンドル・インターフェースを使用するか についてのより詳しい情報は、 「バンドルプログラミングガイド」(Bundle Programming Guide) を見なさい。

言語とロケール指定

iOSは、ISO標準を言語とロケールの識別のためにサポートする(BCP 47仕様)。 これらのコードが、言語に特有のプロジェクト・ディレクトリの命名と、言語とロケール情報が必要である他の場所で使われる。

利用できる規則を使って、あなたは異なる言語を区別することができる(Macでは方言まで区別出来るが、ここでは省略)。 以下の章は、あなたのプログラムでこの情報を指定する方法を示す。

言語指定

言語指定のために、 ISO 639-1かISO 639-2規則を使うことができる。 ISO 639-1仕様は、言語を識別するために２文字のコードを使って、言語を識別する。 しかし、ISO 639-1コードが特定の言語に利用できないならば、 代わりにISO 639-2仕様によって定義される3文字指定子を使うべきかもしれない。 表1は、一部言語の、ISO指定子をリストする。 ハワイ語のためのISO 639-1指定子がないことに注意すべきである。このときはISO 639-2指定子を使用しなければならない。

テーブル 1 ISO言語指定の例
言語 ISO 639-1 ISO 639-2
英語 en eng
フランス語 fr fre
ドイツ語 de ger
日本語 ja jpn
ハワイ語 指定子なし haw

ISO 639-1とISO 639-2コードの完全なリストについては、 http://www.loc.gov/standards/iso639-2/php/English_list.phpを見に行きなさい。

言語に特有のProjectディレクトリ

あなたがより一般化したローカライズしたリソースを作ると、単一のリソースの組で、より多く地域をサポートできる。 これはあなたのバンドルで多くのスペースを節約することができ、翻訳コストを下げる。 たとえば、あなたが英語言語の異なる地域を区別する必要がないなら、 アメリカ、イギリスとオーストラリアでユーザーをサポートするために単一のen.lprojディレクトリに含めることができる。 また、iOS上では、常に単一の言語ディレクトリを使わなければならない。

iOSでリソースを捜すとき、バンドル・ルーチンは、ユーザーの選んだ言葉のために、一般的な言語ディレクトリで要請されたリソースを探す。

バンドルルーチンがどのようにリソースを配置するのかについてのより詳しい情報は、 「バンドルプログラミングガイド」(Bundle Programming Guide) の「Accessing a Bundle's Contents」を見なさい。

カスタム指定子の利用

NSBundleクラスまたはCore Foundationバンドル関数に不明の言語またはロケール略語を使用することも(一応)可能ではある。 たとえば、あなたはISO規則にまだリストされない言語のために、あなた自身の言語指定を造ることが出来る。

あなたが新しい指定子を作成することを選ぶならば、必ずBCP 47のセクション2.2.1と4.5にある規則に従うようにしなさい。 これらの規則に続かないタグは、動く保証がない。
カスタム・タグを使用するときは、ユーザーの言語指定によって格納される略語が、 正確に.lprojディレクトリに用いられる指定子と一致しなければならない。

国際化のためのガイドライン

以下の章は、 あなたが目標とするプラットホーム上で利用できるサポートの利点を得るために、 ソフトウエアをどのように国際化するかについての推奨について述べる。

標準的な言語とロケール IDの利用

iOSでも標準的な言語 IDを得るためのサポートが追加された。 NSLocaleクラスも追加され、Foundationフレームワークに類似したサポートを持ってきた。

バンドルを使う

バンドル機構は、それらがサポートする言語に名づけられる別々のディレクトリに ローカライズされたリソースを置かせることによって、ローカライズ化の処理を単純化する。 NSBundleクラスとCFBundleRef関数は、カレントユーザの言語設定に基づくプログラムをローカライズするために、 リソース・フォルダのこの集合を使う。
この機構は、バンドルされたプログラムが、異なるユーザーのために異なる言語でそれ自体を表示することを可能にする。 ディレクトリによってリソースをまとめることは、後で新しいローカライズを追加することを簡単にする。

Unicodeテキストのサポート

アプリケーションは、テキストをユーザーに表示することが必要であるすべての状況で、Unicodeベースの技術を使わなければならない。 Unicodeのサポートは、複数バイト文字とシステムがサポートする(アラビア語、タイ語、ギリシア語、ハワイ語を含む)いくつかの言語 にとって不可欠である。
あなたが複数バイト言語のためにソフトウエアをローカライズするか否かを問わず、 ユーザーが彼らのネイティブ言語をテキスト・データに入れることができるように、Unicodeをサポートしなければならない。

システムは、Unicodeのテキストを管理し表示するために広範囲なサポートを提供する。 Core FoundationとCocoa文字列は、Unicode文字列をあなたのアプリケーションに保存する方法を提供する。

Unicodeがユーザーに表示されるテキストのため重要である一方、 あなたは、アプリケーションで至る所でそれを使う必要はない。 たとえば、それらのメッセージが翻訳されて、ユーザーに表示されることを望まない限り、 デバッグ用のテキスト、または内蔵ロギング機構のためにまでUnicodeを使う必要はないかもしれない。

複数文字サポート追加のためのガイドライン

複数文字サポートを提供するアプリケーションは、同時にいろいろな文字でテキストを正確に示すことができる。 そのようなアプリケーションはユーザーの言語指定に関係なく、同じ文書に異なる言語の文字を含む テキストの入力・表示・出力を受け入れることが出来る。 アプリケーションが複数文字サポートを提供する準備が出来ていないならば、テキストの一部は正しく現れないだろう。

複数文字サポートは将来ますます重要になると予想される。 オペレーティングシステムだけでなくサードパーティー製のアプリケーションにおいても。 ユーザーは1つの言語で文書を作成することができ、 それらの言語選択を変え、そして最後に保存した言語で文書を開けられることを期待している。

アプリケーションに複数文字サポートを追加するために、あなたは適当なUnicode技術とAPIを使用しなければならない。 Foundationフレームワークのクラスは、自動的に複数文字サポートを提供する。

翻訳できる文字列を注意深く考える

あなたのアプリケーションにテキストを書き込むとき、そのテキストが翻訳されるかもしれない。 言語の文法の違いは、文字列ファイルで利用できるフォーマッティング・オプションでさえ、 翻訳するのが難しいテキストを作ることができる。
特に、単数形および複数形の間で識別を必要とする文字列(たとえばカウント変数)は、 異なる状況で異なる文字列を必要とするかもしれない。 それらが起こる前に、あなたの翻訳チームに潜在的翻訳問題を除く方法について語りなさい。

「リソースプログラミングガイド」の「文字列リソース」 を見なさい。

現在の言語とロケールを得る

あなたのアプリケーションがきちんと国際化されたのならば、 適用されるローカライズがどれを使うかについて、まれに選択しなければならない。
NSBundleクラスとCFBundleRef opaque型に関連したルーチンは、 どのローカライズしたリソースファイルをプログラムの要求の応答として返すか決定するため、 ユーザーの指定を自動的に適用する。 しかしながら、状況は、単にバンドルからリソースを読み込ませることを越えているかもしれない。 それはあなたのプログラムに、どのローカライズが使用中だったかについて、知ることを要求する。 その状況のために、NSBundleとCFBundleRefは、あなたがその情報を得る方法を提供する。

あなたのバンドルでサポートされるローカライズを指定すること

ローカライゼーションを得る方法の技術を議論する前に、 バンドルがシステムに、どのようにそのサポートされたローカライズを伝えるか、について覚えていることが、重要である。
バンドルのリソースを含んでいるディレクトリは、一つ以上の言語に特有のプロジェクト(.lproj)ディレクトリを含む。 これらの.lprojディレクトリの各々は、特定の言語に関連したリソースを含む。 NSBundleクラスのメソッドとCFBundleRef opaque型と関連関数は、 これらのディレクトリを探して、サポートされたローカライズのリストを作るために、それらを使う。 しかしながら、これはこのリストを作る唯一の方法でない。

アプリケーションは、サポートする追加のローカライズを情報プロパティリスト(Info.plist)ファイルを通して、 システムに通知することができる あなたのバンドルの.lprojディレクトリに含まれないローカライゼーションを指定するためには、 このファイルにCFBundleLocalizationsキーを追加する。 キーのための値は、文字列の配列であり、それぞれは 「言語とロケール指定」で述べられる ISO言語指定子である。

好ましいローカライズを得る

あなたがプログラムバンドルを管理するためにCFBundleRef opaque型と関連関数を使っているならば、 最も関連したローカライズを得るために、CFBundleCopyPreferredLocalizationsFromArray関数を使うことができる。 このメソッドを呼ぶとき、あなたはソフトウエアでサポートするローカライズのリストを渡さなければならない。

バンドル情報を用いてこのリストを生成するために、関数CFBundleCopyBundleLocalizationsを使うこともできる。 この関数は、ユーザーの言語と地域指定と、あなたのアプリケーションのサポートされたローカライズを比較する。 関数は、少数のローカライズとともに文字列の配列を返す。 それらのうちの1つは、ユーザーに最も適切な言語のみのローカライズである。 地域に特有のローカライズも利用できるならば、関数は同様にそれを返す。 そして、それに言語のみのローカライズに対する優先権を与える。

あなたがObjective-Cでアプリケーションを書いているなら、 NSBundle クラスの preferredLocalizationsFromArray: と localizations メソッドを、 CFBundleCopyPreferredLocalizationsFromArray と CFBundleCopyBundleLocalizations の代わりに使うことが出来る。 単一のメソッドで両方のアクションを実行する手段として、preferredLocalizationsメソッドを使うこともできる。 Core Foundation関数と同様に、 preferredLocalizations と preferredLocalizationsFromArray: メソッドは バンドルによって使用中の言語指定子を含んでいる文字列の配列を返す。

ローカライズのためのNibファイルの準備

iOSのための統合開発環境(IDE)は、IBを含むXcodeとパフォーマンス・ツールのセットから成る。 開発者は、アプリケーションのユーザーインターフェースを作成するために、インタフェース・ビルダーを利用する。 インタフェース・ビルダーはインターフェースをnibファイルと呼ばれるXMLアーカイブで保存する。 ちょうど画像と音声ファイルをローカライズすることができるように、nibファイルをローカライズすることができる。

nibファイルは、アプリケーションのユーザーインターフェースを保存する。 それは、ウインドウ、ダイアログ、ボタン、スライダー、テキストオブジェクトと、これらの要素のためのヘルプ・タグのような ユーザーインターフェース要素を含む。

nibファイルはまた、ユーザーがコントロールを起動させるとき、実行されるアクションを起こすこれらのオブジェクト間の接続を保存する。
注：
この章は、インタフェース・ビルダーとそのnibファイルについて述べるが、 議論の多くは、他のツールで作成されるローカライズしたユーザーインターフェースにも適用できる。

効果的に Nib ファイルを使う

翻訳者は一般的に、一度にユーザーインターフェースの部分をローカライズする。 そして、文字列長の変化のためにグラフィック要素をちょうど良いように合わせる。 どんなサイズのアプリケーションでも、ウインドウやパネル(つまりダイアログ)を、そのnibファイル中に置くことは良い考えである。 この慣例は、ゆったりとユーザーインターフェースを読み込ませる；つまり、それらが使われるように一部分を読み込ませることを可能にするだけでなく、 徐々に増える段階でローカライズが進展するのを許す。 それも、アプリケーションのメニューを、別々のnibファイルに置く、良い考え方である。

翻訳者は、nibファイルをローカライズするために、インタフェース・ビルダー、 AppleGlot(ダウンロードにはDeveloper IDが必要。) と ibtool の組合せを使うことができる。 これらのツールを使用することで、 翻訳者は、所定の言語の.lprojディレクトリでnibファイルを開けて、 文字列をローカライズして、新しい文字列に対応するためにユーザーインターフェース要素のサイズを変えて、 nibファイルへ変化を保存する。
いくつかの注意点を上げる。 nib ファイル中で、ローカライズは、あなたのウインドウで見えるテキストのサイズをたぶん変える、ということを覚えているべきである。 テキスト・ラベルが拡大する余地を持たないならば、ローカライズ者は、あなたのウインドウのサイズ、 またはラベルまたは他のコントロールの位置を調節しなければならないかもしれない。 一般に、英語のテキストラベルは、翻訳の間に長さが最高40%拡大すると思っていなければならない。 (日本語から英語にするときもだいぶ伸びることが多い。)

ibtoolの利用

手動でnibファイルを翻訳することは疲れる作業である。 そしてプロジェクト中ですでにローカライズしたnibファイルに、以降の設計変更を伝搬するのはより疲れる。 幸いにも、ibtoolコマンドラインユーティリティは、他のnibファイルに変化を伝播することを非常により簡単にする。 このツールは、あなたのnibファイルでのすべての文字列の辞書に作用する。 これを使えば、文字列をnibファイルから抽出することが出来、翻訳し、そしてnibファイルにそれらを注入する。 あるいは、あなたがすでに有効な翻訳を持っているならば、ローカライズしたnibファイルを更新するために、 最近の設計変更を含んでいるマスターnibファイルに、すでに翻訳された文字列を注入することができる。

以下の例は、プロジェクトのmain nibから英語文字列を新しい文字列ファイルに抽出する方法を示す。 あなたは結果として生じるファイルのコピーを、後で使うために備えて、保存するか、翻訳チームにファイルを与えることができる。 
ibtool --generate-strings-file MainMenu.strings en.lproj/MainMenu.nib
次の例は元の英語ベースのnibファイルを取り出し、nibのローカライズしたバージョンを作成するために、翻訳された文字列を合併する。 
// 翻訳された文字列が、オリジナルファイルと同じ名前で de.lprojディレクトリにある
ibtool --strings-file de.lproj/MainMenu.strings --write de.lproj/MainMenu.nib en.lproj/MainMenu.nib
重要
nib ファイル中の文字列の翻訳が、ローカライズ工程の1つの段階でしかないことを忘れてはならない。 ローカライズ者は、ビューとコントロールのレイアウトを文字列長の変化を考慮して合わせる必要があるかもしれない。 また、ibtoolはフォーマッタ・オブジェクトと関連した日付時間フォーマットを自動的に更新しない。

国際化している他のリソース

いくつかのユーザーインターフェース・オブジェクトは、データ解析またはフォーマット時に自動的にローカライズするかもしれない。 一例では、あなたがiOSテキスト・フィールドを数字フォーマッタで構成しておくならば、 数値をフォーマットする時、ユーザのロケール指定によりフォーマッターは自動的に変換する。 しかしながら、他のオブジェクトはあなたに、明示的に現在のロケールを指定することを要求するかもしれない。

リソースと Core Foundation

あなたがCore Foundationフレームワークを使っていて、 フォーマットまたはスキャン日付または数字情報が必要なら、 CFDateFormatterRefとCFNumberFormatterRefタイプを使いなさい。 これらの型は、日付と数字が正しくフォーマットされることを確実とするために、現在のロケール情報を使う。 詳しくは、 CFDateFormatterリファレンス と CFNumberFormatterリファレンス を見なさい。
・・・とはあるけど、 NSDateFormatterとかNSNumberFormatterを使った方が良いと思う。

リソースと Cocoa

あなたがNSString、NSDateまたはNSScannerのような低レベルのオブジェクトを使って 日付または数字をフォーマットしているか、スキャンしていて、 結果として生じるテキストがユーザーに表示されるなら、あなたは現在のロケール情報を使わなければならない。
FoundationフレームワークのNSLocaleクラスでも、ロケール情報を簡単に得られる。 それに加え、いくつかのFoundationフレームワーククラスは、ロケール引数をもつメソッドを提供する。 
NSString: 
- (id)initWithFormat:(NSString *)format locale:(NSDictionary *)dict,...; 
+ (id)stringWithFormat:(NSString *)format,...; 
+ (id)localizedStringWithFormat:(NSString *)format,...; 

NSScanner: 
- (void)setLocale:(NSDictionary *)dict; 
+ (id)scannerWithString:(NSString *)string;
+ (id)localizedScannerWithString:(NSString *)string; 

NSObject: 
- (NSString *)description; 
- (NSString *)descriptionWithLocale:(NSDictionary *)locale; 

NSDate: 
- (id)initWithString:(NSString *)description calendarFormat:(NSString *)format locale:(NSDictionary *)dict;
ロケールは辞書として表現される。 それはキーと値の組を、ローカライズがどのように実行されなければならないかについての情報の保管に使う。
この辞書内での可能なキーのいくつかは、Foundation/NSUserDefaults.hにリストされる。 一般にnilか、標準ユーザー辞書から構築された辞書を渡す。 ユーザー指定から辞書を生成するためには、以下のプログラムを使う。 
[[NSUserDefaults standardUserDefaults] dictionaryRepresentation]
このプログラムはユーザーのデフォルトとユーザーが指定した順の言語を、平坦化したビューを伴った辞書で返す。 ユーザーのデフォルトが優先なので、どんな言語に特有の情報でも(ユーザーの指定から典型的にセットされる) デフォルトのエントリによってオーバーライドされるかもしれない。

UIKitフレームワークはローカライズを、オブジェクトの「ローカライズ版」を求めるメソッドを提供することによってより簡単にする。 それは以下のとおりである: 
- (id)initWithFormat:(NSString *)format, locale:(NSDictionary *)dict,...; 
+ (id)localizedStringWithFormat:(NSString *)format,,...;
第2のメソッドは、ユーザーの現在のデフォルトの辞書表記による最初のものを呼ぶ。 
[[NSUserDefaults standardUserDefaults] dictionaryRepresentation]
ロケール引数のないこれらのメソッドのバージョンにおいては、処理はローカライズしないでされる。

参照

バンドル機構は、アプリケーションのローカライズ版をサポートすることで優れた役割を演ずる。 そのうえ、国際化工程の一部は、 実行ファイルに直接書き込まれた、 文字列と他のローカライズ可能な内容、 の代わりに リソースファイルを使うことを必要とする。 したがって、あなたは、国際化工程について関連した情報のために、以下の本を読まなければならない：