アプリケーションを開発するとき、ローカライズは特に重要です。これは、ユーザー数に直接影響し、それに応じて製品の成功に影響するためです。 さまざまな言語のインターネットユーザー数に関する既知の統計情報があり、特定の言語のグループを翻訳することにより、プログラムのユーザーの対象を大幅に拡大できることが結論付けられています。



私たちのチームは、OS XでICQプロジェクトとMail.Ruエージェント（hi Dima、Vova、Lesha）に取り組んでおり、製品は開発のさまざまな段階でさまざまな方法でローカライズされていました。 蓄積された経験を共有したいと思います。

1. Interface Builderによるローカリゼーション

ローカライズする最も簡単な方法は、標準のInterface Builder（IB）ツールを使用することです。 この場合、プロジェクト設定MyTestProject> Info> Localizationsに新しい言語を追加できます。 ここでは、既存のインターフェイスファイルを自動的に処理できます（ genstrings -o en.lproj *.m



という形式のコマンドgenstrings -o en.lproj *.m



）。



ユーザーインターフェイスで新しいファイルを作成する場合は、[ユーティリティ]ウィンドウの[ローカライズ]ボタンをクリックするだけです。 インターフェイスは一般にわかりやすく、理解しやすいです。 xibから文字列を取得するには、IB経由ではなく手動でローカライズする場合、次の形式のコンソールコマンドを使用するのが理にかなっています。

 ibtool --export-strings-file SomeViewController.utf16-strings.tmp \ SomeViewController.xib && iconv -f utf-16 -t utf-8 \ SomeViewController.utf16-strings.tmp > SomeViewController.strings && \ rm SomeViewController.utf16-strings.tmp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力は次のようになります。

 $ cat SomeViewController.strings /* Class = "NSTextFieldCell"; title = "   "; ObjectID = "4"; */ "4.title" = "   "; /* Class = "NSTextFieldCell"; title = "  "; ObjectID = "9"; */ "9.title" = "  "; /* Class = "NSTextFieldCell"; title = " "; ObjectID = "15"; */ "15.title" = " "; /* Class = "NSTextFieldCell"; title = ""; ObjectID = "23"; */ "23.title" = "";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果の翻訳は、任意のエディターで手動で修正するか、何らかの自動化を使用できます。その後、次のように新しいSomeViewController.strings文字列ファイルをxibに返すことができます。

 iconv -f utf-8 -t utf-16 SomeViewController.strings > \ SomeViewController.utf16-strings.tmp && ibtool --strings-file SomeViewController.utf16-strings.tmp \ SomeViewController.xib --write SomeViewController-updated.xib && \ rm SomeViewController.utf16-strings.tmp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの利点は、シンプルさと可視性、各言語の視覚制御「レイアウト」です。 短所には、gitのマージに関する問題、サポートされている多数の言語ではローカリゼーションの変更をIB経由で行う必要があるという事実が含まれますが、これは必ずしも便利ではありません。 または、上記のようなスクリプトを使用してxibsで翻訳を維持し、すべてを自動的に翻訳することもできますが、この場合、システムを複雑にせず、追加のアドオンを使用しない方が良いことが示されています。

2. NSLocalizedStringによるソフトウェアのローカライズ

このアプローチにより、前のものの欠点を取り除くことができ、 NSLocalizedStrings



関数を使用してインターフェイス要素のヘッダーがプログラムで設定されるという事実から成ります。

 self.startButton.stringValue = NSLocalizedString(@“StartCaption”, @“Start button in menu”); self.pauseButton.stringValue = NSLocalizedString(@“PauseCaption”, @“Pause button in menu”);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、関数の最初の引数は、対応するLocalizable.stringsファイルで対応するローカライズされた文字列を検索するために使用されるキーです。







ローカライズファイルの内容の例：

 Localizable.strings (Russian): “StartCaption” = “!”; “PauseCaption” = “!”; Localizable.strings (Engligh): “StartCaption” = “Start!”; “PauseCaption” = “Pause!”;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Localizable.strings



のキーLocalizable.strings



欠落している場合、 NSLocalizedStrings



はその値自体を返すことに注意してください。 キーとしてその値を使用する誘惑があります。私たちはしばらくの間これを行ってきました-美しく理解しやすいキーがあり、値を置くのを忘れることは大したことではありませんが、実際には、まず、キー値がより不便である可能性があることが明らかになりました基本言語のキー自体とは異なるものにすると、見苦しくなります。2つ目は、グラフィカルインターフェースにキーをポップすることで、ローカライズの正確さを制御する方が便利です。 NSLocalizedStrings



の2番目の引数は、特別な役割を果たさないコメントです;主に、既存のコードに基づいて文字列ファイルを生成し、文字列が何を参照しているかを明確にするために使用されます。 次の形式のスクリプトを使用して、翻訳用の行を含む現在のファイルを取得できます。

 #!/bin/bash export LANG=C LC_CTYPE=C LC_ALL=C for file in `find . -name "*.m"` do genstrings -a $file done cat Localizable.strings | sort -u | sed '/\/\\*/d' > actual.strings
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NSLocalizedString



とNSLocalizedString



すぐに[NSBundle localizedStringForKey:value:table:]



メソッドを使用することができ[NSBundle localizedStringForKey:value:table:]



これは実際に（メインバンドルに対して、テーブルとしてnilを使用して）ひっくり返ります。カスタム.stringsファイルから（その名前はテーブルとして示されます）。 使用される言語は、 NSUserDefaults



AppleLanguages



キーAppleLanguages



に基づいて決定されNSUserDefaults



。



異なる言語の翻訳の長さが非常に異なり、インターフェースが変動している場合、制御のサイズに基づいたソフトウェアの調整

 NSSize myButtonSize = [self.myButton.stringValue sizeWithAttributes:[NSDictionary dictionaryWithObject:self.myButton.font forKey:NSFontAttributeName]];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

自動レイアウトを使用すると、一般的にはより便利になります。











ここで、コントロールテキストを変更するとき、そのジオメトリを自動的に変更し、それに続くボタンを整列する方法を添付する必要があります。 わあ

3.動的なローカライズ

これでプロジェクトに適用されました。 むしろ以前のバージョンの修正であり、ポイントは言語がプログラム設定を介して動的に変更され、通知が送信されることです。これにより、アナログNSLocalizedString



がNSLocalizedString



ローカライズされたインターフェースをバイパスします- [NSBundle localizedStringForKey:value:table:]



実行時には、アプリケーションリソースから、プログラム設定で選択された言語の目的の文字列値を取得します。 ニュアンスのうち、それは注目に値する

• 実際には、一部の言語では一部の翻訳が表示されない場合があり、デフォルトから翻訳を取得する必要があります。
• ローカリゼーションがプロジェクトにない言語の場合、デフォルトの言語値を確認して返す必要があります。
• 一部の言語（ポルトガル語など）では、システムの言語指定（pt）とXcode環境（pt-BR）が異なる場合があるため、追加のチェックを行う必要があります。

一般に、各アプローチには独自の応用分野があります。 たとえば、IBを介したローカリゼーションは、多くの言語がサポートされておらず、多数のテキスト要素があり、インターフェイスのジオメトリがローカリゼーションごとに異なるアプリケーションに最適です。 ソフトウェアのローカリゼーションは、異なるローカリゼーションの多くの言語と行の長さが大きく異なるプロジェクトに対して最適に行われます。 場合によっては、混乱して動的なローカライズを行うことができますが、ここでの利点は、その場で言語をエレガントに切り替えることができ、ユーザーが満足することです。 自動レイアウトを忘れないでください。 この情報で誰かが自分自身に役立つものを見つけてくれることを願っています。 ご清聴ありがとうございました！