すべての人に良い一日を！ 私の名前はニコライ、私はTouch Instinctの iOSリーダーです。 開発プロセスでは、多くの場合、複数の言語で動作する必要があるプロジェクトに対処する必要があります。 ローカライズを使用する際にどのようなアプローチをしたかを説明します。
基本的なアプローチの短所
iOSアプリケーションのローカライズには、いくつかの基本的なアプローチがあります。 最初に決定することは、アプリケーションがストーリーボードを使用して開発されているかどうかです。
ストーリーボードを使用する
ストーリーボードで文字列を直接ローカライズできます。 ただし、このアプローチにはいくつかの欠点があります。
- 多数のストーリーボードの場合、ローカライズされた線がプロジェクト全体に散らばっています。
- 属性文字列、およびいくつかのコンポーネントで構成される文字列を使用することは不可能です。
- それでもコード内の行の一部をローカライズする必要があります。 これにより、アプリケーションのバリエーションがさらに広がります。
- 実際、コードレビューを行う際に他の開発者に何かを確認する方法はありません。
絵コンテなし
この場合、コード内のすべてをローカライズします。 ただし、いくつかのマイナスがあります。 実際、ローカライズ文字列localizable.stringsを持つファイルは魔法です。 そのようなファイルを変更すると、人的要因によるエラーの可能性が非常に高くなります。 テスト中にエラーが見つかるまで、変更を追跡できません。
したがって、iOS SDKにはローカライズ用の既製のメカニズムが既にありますが、重大な欠点があります。 詳細はこちらをご覧ください。
私たちは目標に対処します
標準的な解決策がうまくいかない場合は、すぐに急いで独自の「自転車」を作らないでください。 達成すべき目標を策定します。
将来の決定が満たすべき主要な基準：
- プロジェクトでサポートされているすべてのモバイルプラットフォームのローカライズリソースを組み合わせます。 モバイル開発では、多くの場合、一度に複数のプラットフォーム（通常はiOS + Android）のプロジェクトを行います。 異なるプラットフォーム上の同じアプリケーションは、ローカライズに同じリソースを使用します。 この場合、個々のプラットフォームごとに特定の行を持つことが可能です。
- 開発者の参加なしで、プロジェクトに新しいローカライズラインを自動的に追加します。 アプリケーションが複数の言語を使用する場合、翻訳者または翻訳者とプロジェクトの間の仲介者がリソースを埋めます。 メディエーターは、マネージャーまたは他のチームメンバーにすることができます。 非技術専門家にコードへのアクセスを許可する-マナーが悪い。 ローカリゼーションリソースを別の場所に保管することをお勧めします。 同時に、開発者が毎回これらのリソースを「手作業で」追加しないことが必要です。
- コンパイル段階でローカライズリソースを変更する際のプロジェクトのエラーの検出。 NSLocalizedStringを使用する標準的なアプローチでは、文字列自体がlocalizable.stringsで変更され、コードに変更がない場合、アプリケーションはエラーで終了することを想定しています。 最初のエラー検索画面は、プロジェクトのビルドプロセスです。 ローカリゼーション文字列の変更、および変更の結果として発生するエラーは、この段階で取得する必要があります。
- プロジェクトに魔法のラインがない。 プロジェクトの魔法の意味はすべて悪です。 多くの方法でそれらをきれいにすることができます。 コードにコメントしたり、名前を話すことで定数に魔法の値を入れたりする方法があります。
Touch Instinctのローカライズ
文字列のリポジトリを作成する
まず、バージョン管理システムに別のリポジトリを作成する必要があります。 このリポジトリには何を保存する必要がありますか？ すべてがシンプルです。 これは、common_strings_eng.json / common_strings_ru.json /などの形式のjsonファイルが格納される場所です。 言語ごとに個別のjsonファイルが作成されます。
そのようなファイルの内容を考慮してください。 Jsonはキーと値のペアの形式のテキストデータ記述形式であるため、ローカライズされた各文字列のキー名を作成し、すべてのファイルで使用します。 値はローカライズされた値であり、アプリケーション自体に表示されます。
当社には、すべてのアプリケーションでキーを統合し、各プロジェクト内でキーを統一するためのスタイルガイドがあります。
注意深い読者には、いくつかの質問があります。
1）jsonファイルに記入するとき、間違いを犯す可能性があります。たとえば、特定の言語のいくつかのキーの値を記入するのを忘れますか？
はい、そうです。 ただし、ここでは、責任はすでに翻訳者または一人のレベルにまで拡大されています。 同時に、すべてのjsonファイルを調べて、ファイルのどこに何が欠けているかを示すスクリプトを簡単に作成できます。
2）このシステムは、 複数の 「古い」 システムを使用して動作します。 便利ですか？
複数の小さな教育プログラム。 実際、これらは量に応じて名詞の形です。 例：1日、2日、5日。 確かに、複数形を扱うのは難しいと開発者から聞くことができます。 ただし、アプリケーションにはそのようなリソースはほとんどないと結論付けました。 他の利点を得ると、これは無視できます。 ここで辞書の形で複数を扱う標準メカニズムの仕事を見ることができます 。
これで、プロジェクトのローカライズされたリソースが作成される個別のリポジトリができました。
例：
{ "common_global_error": "", "common_notifications_no_new_notifications": " ", }
アプリケーションをローカライズします
文字列を含むリポジトリは、サブモジュールとしてプロジェクトに接続する必要があります。 それは何を与えますか？ 行の最新バージョンが必要ない場合は、サブモジュールのバージョンを更新するだけではなく、翻訳者/デザイナー/その他の関係者が次のバージョンのリソースを安全に作成できます。
プロジェクトの開発プロセスでは、ストーリーボードが使用されている場合でも、コードでローカライズを使用することにしました。
サブモジュールを接続した後、それらを使用するためにアプリケーションの行を取得する必要があります。 これを行うには、スクリプトを作成し、実行スクリプトとしてビルドフェーズに追加します。
スクリプト自体には、phpを使用します。 ただし、他のスクリプト言語に書き換えることができます。
このスクリプトをプロジェクトに追加します。 次に、実行スクリプトに追加します。
php ./common_strings/import_strings.php
事前に、たとえば「ローカリゼーション」と呼びます。 非常に多くの場合、まったく名前のないスクリプトを実行するサードパーティのプロジェクトを見る必要があります。 したがって、そこで起こっていることをすぐに理解することはできません。
事前にプロジェクトに空のlocalizable.stringsファイルとString + Localization.swiftを作成します。 最初のビルド（cmd + B）の後、プロジェクトのlocalizable.stringsファイルと、String + Localization.swiftファイルが完成しました。 スクリプトが実行されない、または正しく実行されない場合は、スクリプトは入力のみを担当するため、これらのファイルが事前に作成されていることを確認してください。
既製のファイルLocalizable.stringの例（ロシア語）
完成したファイルの例String + Localization.swift
さらに、ローカライズを容易にするために、 Stringの拡張機能を作成します。
これで、プロジェクトでString + Localizationの行を使用できます。 例：
emptyLabel.text = .commonNotificationsNoNewNotifications
さらに、これはもはや魔法のラインではありません。 カーソルを合わせると、プロジェクトの開発者が最も理解しやすい言語の単語の翻訳も確認できます。
プロジェクトが.commonNotificationsNoNewNotificationsという行を使用している場合、翻訳者が新しいバージョンでそれを削除すると、開発者にはコンパイルエラーが表示されます。 この行はプロジェクトに存在しないため、修正する必要があるためです。 リソースの変更に関するエラーを予測的に受け取りましたが、実稼働環境ではリリースしませんでした/テスターに渡しました/など。
その結果、すべての目標を達成するローカリゼーションを操作するシステムが得られます。 この方法でいくつかのプロジェクトがすでに完了しています。 この手法が、アプリケーションのローカライズプロセスを簡素化し、開発者への依存を軽減するのに役立つことを願っています。