それを参考に最近、今開発中のPlayer!に実際に適用しつつ改善したことについてまとめます。前半は、iOS以外の他のプラットフォームでも共通のことでけっこう有用だと思います。それらだけ見ればiOSアプリの国際化については網羅出来るくらいの作りにしてますヽ(・ω・`)「絶対に日本語版以外出さない」というアプリ以外は、初めから国際化対応しておくべき「国際化対応しておく」というのは英語対応をする、という意味では無く、文言をコードに直書きせずに国際化リソースとして分離しておく、という意味です。開発リソースの余裕が無かったり、英語対応したところでユーザーも少ないということで、初めは日本語のみでリリースすることが多く、それは全く問題無いと思っています。初めは1カ国語のみの対応でも、ちゃんと国際化リソースとして切り出しておくことで以下のメリットがあります。Paul"NGこう定義したものを使い回すと、多言語対応の際に破綻することがあります。%@"原則、1種類の文言に対して、フルセンテンスで定義しておきましょう。細かく分割して冗長性を減らして、それらを連結するようなアプローチは1言語では出来ても、多言語対応時に破綻します。同じ表現になるものも、文脈が異なるのであれば別定義にしましょう。「走行」という意味と「走る」という意味で、ともに「Run」という表現にする場合、以下のように2種類の言語リソースとして定義しておくべきです。"Run";今の例では、2種類でしたが、名詞か動詞かという区別だけでなく、配置場所的に文脈が異なる場合なども、さらに冗長に定義しておくと安心です。"Run";言語リソーステーブルで分割するとベターです。テーブルファイル名を指定して呼ぶObjective-Cではそれぞれ使用関数が違いましたが、Swiftでは以下のtableName引数の有無でハンドリングします。他は後者を用いています。先ほどの例の場合、こうなります。A」このような順番指定付きにすれば良いです。上の例では、String(format:...)関数を使いましたが、数値の入った文言は以下を使うのが良いです。String例えば、日本では数値は三桁コンマ区切りですが、ピリオド区切りの国もあります。そのあたりを良い感じに出力してくれます。.DecimalStyleformatter.stringFromNumber(12345)!これはダメな例です。全ての国でコンマ区切りになってしまいます。フォーマットを明示的に指定するのはこれに限らず避けましょう。capitalizedStringこの使い分けで違和感の見た目になるケースはけっこう稀な気がしますが、対応は簡単なのでやるに越したことはないです。例としては、"i".uppercaseStringWithLocale(locale)大半のlocaleの出力は、Iになりますが、tr_TR(トルコ)だと正しくİというローカライズされた文字列が取得出来ます。uppercaseStringを使った場合はもちろんI出力になってしまいます。このメソッドに与えるlocaleについては「正しいlocaleを取得する」を参照してください。数値のフォーマットNSNumberFormatter・NSDateFormatterを使いこなしましょう。このformatterにはデフォルトではNSLocale.currentLocale()がセットされているので、「正しいlocaleを取得する」を参照してlocaleを上書きしましょう。Referenceに書いてあるdateとtimeのstyleの組み合わせで良ければ、それで済ませましょう。styleに無い表記パターンを指定したい場合は、localeに応じたカスタムフォーマットを指定しましょう。"6月28日"NSDateFormatter.dateFormatFromTemplateのtemplate引数に与えた書式記号を良い感じに並び替えつつlocaleに最適な形で出力してくれます。FormatterのインスタンスをキャッシュFormatterの初期化はけっこうコスト高い上に、連続的に呼ばれがちな処理なので、使い回すようにしましょう。Swiftだとこんな感じです。端末のlocale設定が変わった時に追従するようにNSNotificationCenter使って監視するコードも載っていますが、個人的にはそこまで気を遣わなくても良いかなーと感じちゃいます。YES引数付きで起動すると...何と、文字列が2つ繰り返されて約2倍の長さになってくれます。CASE)で表示してくれます。6からGUIで設定出来るようになりました。6からGUIで行えるようになりました。Qiitaで以前書きました。Qiitaにて別記事にしました。簡単に取れるでしょ?と思うかもしれませんが、アプリの文言の国際化対応においては少し気をつけるべきことがあります。仮に、日英のみ対応のアプリ(日本語設定以外だと英語UIになる)だとします。そこでフランスのユーザーが使ったとすると、英語UIで使われるはずです。あれば、フランスのlocaleではなく一貫して英語localeにするのが望ましい表示だと思います。NSLocalizedStringなどを使う分にはアプリが正しく設定されていれば、英語localeで表示してくれますが、以下の関数など、localeを明示的に指定する必要のあるものを使う場合、NSLocale.currentLocale()で取得したlocaleを使うと、今の例だとその部分だけフランス語表示になってちぐはぐなUIになってしまいます。使う場合もデフォルトではcurrentLocaleが設定されてしまっているので、正しいlocaleを明示的に設定する必要があります。正しいlocaleを明示的に設定する必要もちろん、アプリの表示言語じゃなくて実際のlocaleを設定したい場合、NSLocale.currentLocale()でOKです。多言語対応用の文言を設定する際の正しいlocaleの取得法これで、上の例だと英語localeになります。localeIdentifier)アプリの言語設定は、iPhoneの設定アプリの言語設定の「使用する言語の優先順序」に従ってアプリが対応している言語とマッチされたものが選択され、それと同じロジックをコードで再現しています。NSLocalizedStringを呼びやすくするTipsquestbeat/Linを使うと、補完してくれて便利です。6・Swiftの組み合わせでも動きます。key名を自動補完で選ぶと、それに適合するtableNameも自動補完してくれるなど、かなり気が利いています。Swiftの場合、NSLocalizedStringを呼ぶと、bundleやvalueのオプション引数まで自動入力されてしまって煩わしいので、さらにスニペットを併用するのがオススメです。追記していくかもしれませんが、とりあえず1つだけ。5くらいでそれ以前より取り回しよくなりましたが、最近は一切使わないようにしています。Qiita)結局動的にコードで上書きせざるを得ないところがあって、Storyboard上の文字列のうちどこが実際にUIに表示されるのかが分かりにくい初めは固定文字列だったのに後から動的に変更したくなった場合に、コードで上書くように変更するのもちょっと面倒とはいえ、実際のUIと文言が紐付いて分かりやすい、静的な文言はコードで書かなくて良いので楽、など利点もあると思います。アプリの規模が大きくなってくると、段々デメリットが大きくなっていくと感じているので、僕はもう初めから使わないようにしてます。upLoginユーザーは見つかりませんでした。