iOSローカリゼーションファイルでの継承の実装





こんにちは、ハッカーの皆さん!



今日は、ローカリゼーションの問題を解決するための興味深い経験を共有したいと思います。 iOSでは、ローカリゼーションは、1つのターゲット、またはlocalizable.stringsのキーあまり繰り返さない複数のターゲットの観点から非常に便利に配置されます。ただし、キーの半分以上が繰り返されると同時に意味が異なる12のターゲットがある場合、すべてがより複雑になります。また、特定のターゲットに固有のキーのセットもあります。



まだこれに遭遇していない人のために、例を挙げて問題をより詳細に説明します。



一般的なコードの90%と3つのターゲットMyApp1MyApp2MyApp3)があり、それぞれに独自の名前とテキストがある大規模なプロジェクトがあるとします。本質的に、ターゲットは独立したアプリケーションです。それぞれを10言語に翻訳する必要があります。ただし、app1_localizable_key1app2_localizable_key1などのローカリゼーションキーは追加しません。コード内のすべてを美しくし、1行でローカライズする必要があります



NSLocalizedString(@"localizable_key1", nil)


どのなしの場合IFDEF、新しいターゲットを追加するとき、私たちはと場所を見てする必要はありませんので、NSLocalizedString巨大なプロジェクトのコードを通して、そこに新しいキーを登録します。また、いくつかのキーを特定のターゲット画面に関連付ける必要があります。キーapp2_screen1_keyapp3_screen2_keyがありました



これで、標準のXcodeツールを使用して次のことができます。



  • 共通部分localizable.stringsを各ターゲットにコピーすると、これらのファイルのコピーが3つ取得されます。
  • 対応するlocalizable.stringsにターゲット固有のキーを追加します。


どのような問題が発生しますか:



  • プロジェクトに新しい共有キーを追加するのは非常に費用がかかります。座席数は、ターゲットの数に言語の数を掛けたものに等しくなります。この例では、これは30か所です。
  • 現在積極的に取り組んでいる1〜2のターゲットにラインを追加し、1年後に1つ以上のターゲットを復活させることを決定した場合、エラーが発生する可能性があります。ローカリゼーションを相互に手動で同期するか、このためのスクリプトを作成する必要があります。また、ブランチを追加またはマージするときに多少のずれが見られ、一般的なキーが特定のキーと混在している場合は、本当の探求があります。
  • ローカリゼーションファイルの量。それらはすべて絶えず成長しているため、それらとの連携が困難になり、ブランチをマージするときに競合が発生する可能性が高くなります。


私が欲しいもの:



  • すべての公開鍵を別のファイルに保持します。
  • ターゲットごとに、特定のキーのみが保存されたファイルと、このターゲットの値を持つ一般的なキーがありました。


この例では、文字列を含む共通ファイルlocalizable.stringsがあります



"shared_localizable_key1" = "MyApp title"
"shared_localizable_key2" = "MyApp description"
"shared_localizable_key3" = "Shared text1"
"shared_localizable_key4" = "Shared text2"


キーを 含むlocalizable_app2.stringsファイルが欲しいのです



"shared_localizable_key1" = "MyApp2 another title"
"shared_localizable_key2" = "MyApp2 another description"
"app2_screen1_key" = "Profile screen title"


それら。ローカリゼーションファイルで継承原則を整理します



残念ながら、Xcodeはこれに合わせて調整されていないため、Xcodeがあちこちでスティックを動かしているため、長い間行きたくなかった自分の「自転車」を作り直す必要がありました。



18のターゲットと12の言語でプロジェクトがあります。そして、これは冗談ではありません。プロジェクトは非常に大きく、そこには非常に多くのターゲットが必要です。翻訳用に新しい公開鍵を追加する必要があるたびに、216個のローカリゼーションファイルを処理しています。これには時間がかかります。また、新しいターゲットを追加すると、さらに12個のlocalizable.stringsをコピーする必要があるという事実につながります。一般的に、ある時点で、私たちはもはやこのように生きることは不可能であることに気づき、解決策を探さなければなりませんでした。



その過程で何とかテストしたすべての方法については長い間話しません。すぐに実用的なソリューションに進みます。



したがって、最初にすべての共有キーを見つける必要がありました。これはスクリプトを使用して実行できます。詳細については説明しません。これはかなり簡単な作業です。



さらに、共通の(ベース)ローカリゼーションファイル、または12の物理ファイルと、各ターゲットのファイルセットを受け取ったら、Xcodeに移動し、そこにすべてのファイルを追加します。同時に、どのターゲットにもファイルを添付しません。 [ターゲットメンバーシップ]の下の右側のペインをオフにする必要があります。







これらのマークはファイルにのみ設定します。これは、ファイルを組み立てるためのスクリプトの作業の結果です。



次に、同じ「バイク」が始まります。



  • Localization, build_localization.py.
  • Localizable. localizable.strings.
  • Localizable .






ファイルへのリンクをプロジェクトに正しく追加し、Xcodeがそれらを正しく認識するために必要なのはそれだけです。それ以外の場合は、キーの検索にそれらを使用しません。たとえば、正しいlocalizable.stringsファイルを含むLocalizableフォルダー作成し、それをフォルダー参照としてプロジェクトに追加すると、Xcodeがローカリゼーションキーを指定したことを認識しなくても、したがって、Localizableフォルダーを取得し、グループとしてドラッグして(create group)、必要に応じてアイテムをコピーするチェックボックスをオフにして、次の図のようにします。Localizable フォルダーを削除します







そしてそれをgitaの例外に追加します。 gitaのスクリプトの結果は必要ないため、ターゲットごとに変更され、コミットが詰まります。



次に、スクリプトをビルドフェーズに追加する必要があります。これを行うには、ビルドフェーズで、 [新規実行スクリプトフェーズ]をクリックし、パラメーターを使用してスクリプトを記述します。 




python3 ${SRCROOT}/Localization/build_localization.py -b “${SRCROOT}/BaseLocalization" -s "${SRCROOT}/Target1Localization" -d "${SRCROOT}/Localization/Localizable"


bはベースローカリゼーションのあるフォルダー、sは現在のターゲットのローカリゼーション、dは結果フォルダーです。



新しいフェーズを上に移動します。バンドルリソースコピーフェーズ以上である必要があります。それら。最初に、スクリプトがファイルを生成し、次にそれらがバンドルに取り込まれます。







ここで、スクリプトの実行中にファイルが変更されることをXcodeに伝えることが重要です。そうしないと、ビルド時にファイルが見つからないというエラーがスローされます。さらに、エラーはクリーンなアセンブリでのみ発生し、問題が何であるかがすぐには明らかになりません。ビルドフェーズで、すべてのローカリゼーションファイル出力ファイルに追加ます







これは、ターゲットごとに実行する必要があります。これを行う最も簡単な方法は、テキストエディタでプロジェクトを開くことです。これは、Xcodeがターゲット間でフェーズをコピー/貼り付けできないためです。したがって、各ターゲットのスクリプトパラメータ-sは異なります。



これで、各ビルドで、スクリプトはベースローカリゼーションファイルを取得し、ターゲットファイルから変更をロールオーバーし(キーの追加、上書き)、iOSがキーの検索に使用するLocalizableフォルダーローカリゼーションを生成します。



一般に、継承メカニズムを実装するときに計画されたものを取得しました。



  • 共有キーは1つのファイルに存在し、他のファイルに干渉しません。新しいキーを入力するプロセスの時間が18短縮されました時間。
  • 特定のターゲットに関連するキーは、対応するファイルにあります。
  • ファイルサイズが大幅に減少しました。繰り返し行の乱雑​​さを取り除きました。
  • プロジェクトに新しい言語を追加するプロセスも大幅に簡素化されます。
  • 新しいターゲットを作成するときに、不要な行をまとめてローカリゼーションをコピーする必要はありません。localizable.stringsという名前の新しいファイルを作成し、このターゲットに必要なものだけを追加します
  • 古いターゲットを復活させることにした場合は、行に対して何もする必要はありません。すべてがベースファイルからプルされます。
  • スクリプトはgitを散らかさず、作業の結果はローカルに残り、痛みを伴わずに削除できます。


→完成したスクリプトはここで取ることができます



完璧なスクリプトのふりをしていません。プルリクエストは大歓迎です。



All Articles