WWDC23でAppleが発表したXcodeの新機能は、私のRemafoXアプリの大部分をシャーロック（Appleが同等機能を標準搭載すること）しました。当然、私はこの新機能を詳細にテストし、関連するSlackアクティビティでビルドチームにあらゆる質問をぶつけました。実際のところ、String Catalogsは素晴らしい出来で、過去にアプリで手がけていたローレベルの作業のほとんどが不要になったため、私はアプリの方向性を再構想することにしました。
しかし、WWDC以降に話をした多くの開発者は、String Catalogsが自分のプロジェクトにどんな影響を及ぼすか、まだよく理解していませんでした。そこで、String Catalogsがいかに素晴らしいものかをより明確にするために、よくある質問に答えることにしました。
String Catalogsとは何ですか？Strings(dict)ファイルはどうなりますか？
String Catalogsは.xcstringsという拡張子のファイルで、カスタムJSON形式でコンテンツを保存します。正確なフォーマットはドキュメント化されていません（変更を求めるフィードバックを提出済み：FB12264877）。しかし開発者として、JSONコードを直接いじる必要はありません。Xcode 15にはビジュアルエディタが付属しているからです：
String Catalogsは.stringsと.stringsdictの両ファイルを置き換えるため、複数形にも標準で対応しています。en.lprojのような言語別フォルダに配置される.strings(dict)ファイルとは異なり、String Catalogsはすべての対応言語の翻訳を1つのファイルにまとめます。これにより、各翻訳の進捗をXcode内で直接表示するといった安全性チェックが可能になり、翻訳漏れをすぐに把握できます（RemafoXのLinter機能を代替）。同様に、新しいキーをすべての言語に自動的に追加してくれるため、大幅な時間短縮になります（RemafoXのNormalizer機能を代替）。将来のアップデートでは、ソース言語と同じパラメータ（例：%@）がローカライズに含まれているかチェックする機能なども追加される可能性があります（RemafoXで計画していた機能で、フィードバック提出済み：FB12264614）。
Strings(dict)ファイルを使っているプロジェクトがあります。移行は簡単ですか？
はい、とても簡単です！String Catalogsへの移行は非常にシンプルで、.strings(dict)ファイルを右クリックして「Migrate to String Catalog…」を選択するだけです。すると、プロジェクト内のすべての.strings(dict)ファイルの一覧がモーダルで表示され、どのファイルを1つのString Catalogにまとめるか選択できます。プロジェクトの異なる部分に別々のStringsファイルがある場合は、別々のString Catalogとして残すこともでき、すべてを1つにまとめる必要はありません。
でも、古いOSバージョンをサポートしています。それでも移行できますか？
はい、もちろんです！Appleのエンジニアはここで非常に賢い設計をしました。開発者としてはString Catalogsのすべての機能をフル活用できる一方で、アプリ側では.xcstringsのような新しいファイル形式は一切見えません。ビルドプロセス中にXcodeがString Catalogを従来の.stringsと.stringsdictファイルに変換するため、ターゲットにできるすべてのOSバージョンとの互換性が保証されます。つまり、プロジェクトでXcode 15に移行できるようになれば、すぐにString Catalogsのフル活用を始められます！
💁♂️ SF Symbolsのようなアプリがあったらいいのに、と思ったことはありませんか？ただしアイコンではなく、iOSの全対応言語の公式翻訳付きローカライズ文字列のためのもの。まさにそれを作りました。しかも完全無料です！ TranslateKitをダウンロードして、メニューバーをチェックしてみてください。🌐 👍
SwiftGen/RemafoXを使って、コンパイラチェックによる安全なローカライズキー参照をしています。この安全性は失われますか？
いいえ、まったく失われません。Xcodeは新しいファイル形式を導入するだけでなく、プロジェクトから新しいローカライズキーを自動的に抽出するツールも備えています。SwiftUIのローカライズAPI（LocalizedStringKeyやLocalizedStringResource）を使用していれば、自動的に検出されてString Catalogに追加されます。これはSwiftUIだけにとどまらず、String(localized:)のようなプレーンなSwift String API、NSLocalizedString()のようなObj-CスタイルのプレーンなAPI（カスタム名もサポート）、さらには.storyboardや.xibファイルのようなInterface Builderファイルでも機能します。Info.plistファイルについては、InfoPlist.xcstringsという名前の専用String Catalogを作成すれば、そこでも自動抽出が機能します。
なお、Xcode 15のAsset Catalogで画像やカラーに対して得られるようなキーの自動補完は、ローカライズキーでは提供されません。Asset Catalogsではカタログ自体（アセットが配置される場所）が情報源ですが、Xcodeはソースコードからローカライズを自動抽出するため、ローカライズの情報源はコード側にあります。そのため、コードにテキストを追加してStringsファイルに対応するものがない（以前は可能で、翻訳が壊れる原因になっていた）という状況は起こりえません。代わりに、プロジェクトでローカライズされたStringを追加するたびに、Xcodeがすべての対応言語に新しい翻訳キーを自動作成し、String Catalogで翻訳が未完了であることが表示されます。
ドイツ語に緑のチェックマークがないのは、翻訳が未完了であることを示しています。
タイポはどうなりますか？開発中にキーを変更できますか？
Xcodeは新しいキーを抽出してString Catalogに自動追加するだけでなく、プロジェクト内で参照されなくなったキーを確実に削除します。これは安全に行われます。まだどの言語でも翻訳を提供していないキーについては、プロジェクト内で見つからなくなった場合に自動的に削除されます。これはキーにタイポがあった場合や、開発中にキーを改善したくて変更した場合に典型的に起こることです。ただし、すでにいくつかの翻訳がある場合は、Xcodeは代わりにString Catalog内でそのキーを黄色い警告シンボル付きの「stale」（古い）としてマークします。これにより、参照されなくなったキーを簡単に見つけ、必要に応じて翻訳を新しいキーにコピーし、その後削除することができます。
コード/IBファイルで特定のテキストをローカライズしたくない場合は？
現時点では、情報源からの抽出を直接制御する方法はないようです。特にIBファイルについてはフィードバックを提出しました（FB12264777）。私のツールRemafoX（およびその前身BartyCrouch）ではIBファイルでの除外をサポートしているため、Appleから何らかの解決策が提供されない限り、それらを使っている人にとってはString Catalogsへの移行が難しい場合があります。コード内でStringを「翻訳不要」と明示的にマークする方法も見つけられませんでしたが、ほとんどのSwiftUIビューでは、Stringの代わりにTextビューを受け取る同じAPIのオーバーロードがあります。該当するビューでは、Text(verbatim: "Your Text")を使うことで、verbatimキーワードが翻訳不要とマークするため、テキストが抽出されないTextビューを作成できます。ただし、Textを受け取るオーバーロードが常に存在するわけではないため、抽出をより直接的に制御する方法についてフィードバックを提出しました（FB12469163）。当面の回避策として、LocalizedStringKeyオーバーロードが優先されるSwiftUI APIでは、String("Your Text")のようにStringイニシャライザを使う方法があります。
まとめ
Xcode 15で導入されたString Catalogsは、翻訳ファイルの管理を簡素化し、ローカライズワークフローに大きな改善をもたらします。開発者はプロジェクトをString Catalogsに簡単に移行でき、ローカライズキー参照の安全性を維持しつつ、古いOSバージョンもサポートし、キーの変更やタイポにも対応できます。いくつかの制限や改善の余地はあるものの、String Catalogsは従来のStringsファイルシステムと比べて大きな前進であり、デメリットはほぼありません。今すぐ移行しましょう！