iOSローカライズの進化
ローカライズがどこまで進歩し、どこにまだ課題が残っているのかを理解するために、簡単に振り返ってみましょう。String Catalogs以前の時代、開発者はen.lprojのような言語別フォルダに配置された.stringsファイルと.stringsdictファイルの組み合わせに頼っていました。このシステムは機能的ではあったものの、いくつかの欠点がありました:
未使用や不足している翻訳に対する安全性チェックがない
異なる言語ファイル間の手動同期が必要
コードからの文字列抽出機能がない
SwiftGenやBartyCrouchといったツールが、型安全性と自動抽出を提供してこれらの問題に対処しました。そしてコミュニティは、翻訳者にコンテキストを提供し関連する文字列をグループ化するために、セマンティックキー(例:"Onboarding.Page1.title")を使うベストプラクティスを確立しました。
String Catalogs:革新的だがトレードオフも
2023年にAppleが導入したString Catalogsは、長年の課題を複数解決しました:
✅ コードからの自動キー抽出 ✅ 翻訳漏れの組み込み安全性チェック ✅ Xcode内での視覚的な進捗トラッキング ✅ 全言語を1つにまとめる統一ファイル形式 ✅ 古いiOSバージョンとの後方互換性
しかし、Appleが推奨する英語の文字列をキーとして使うアプローチは、コードの可読性を向上させる一方で、新たな課題を生みました:
❌ 関連する文字列がアルファベット順に散在 ❌ 翻訳者へのコンテキストが減少 ❌ 機能やスクリーンごとのグループ化がない
String Catalogsのグループ化の欠如は、翻訳時に不便です。
それと同様に重要なのが、iOS開発エコシステムにおけるローカライズ周りの大きなギャップです。これはSF Symbols登場前のアイコンの状況とよく似ています。SF Symbols以前は、すべての開発者が独自のアイコンを作成または調達する必要があり、アプリ間で一貫性のない体験につながっていました。SF Symbolsは、標準化された包括的なアイコンセットを提供することでこの問題を解決し、一貫性を確保しながら開発時間を大幅に短縮しました。
ローカライズの分野にも同様のソリューションが切実に求められています。すべてのアプリに「保存」「キャンセル」「完了」「プライバシーポリシー」「利用規約」といった共通のUI文字列が必要です。そしてアイコンと同じように、これらはアプリ間で一貫しているべきです。ユーザーは、一貫したアイコノグラフィーと同じように、この一貫性の恩恵を受けます。しかし現状では、各開発者がこれらの共通UI要素を独自に翻訳しており、異なるアプリの異なる言語で同じコンセプトに対してバラバラの翻訳が使われています。
TranslateKitの登場:欠けていたピース
オープンソースのTranslateKit SDKがこれらのギャップを埋め、ベストプラクティスを維持しながらString Catalogsのメリットを最大限に活かす包括的なソリューションを提供します。SF SymbolsがiOSアプリのアイコン利用に革命を起こしたように、この新しいSwiftパッケージはローカライズで同じことを目指しています。
1. 手間なしのセマンティックキー生成
#tkマクロが、コードをクリーンで読みやすく保ちながら、セマンティックキーを復活させます:
struct OnboardingView: View {
var body: some View {
// Generates key: OnboardingView.Body.welcomeToMyApp
Text(#tk("Welcome to MyApp"))
}
}このアプローチにより:
コードのコンテキストに基づいてセマンティックキーを自動生成
コードの可読性を維持
翻訳者に必要なコンテキストを提供
String Catalog内で関連する文字列をグループ化
自動生成されたセマンティックキーにより、関連する文字列が自然にグループ化されます。
必要なのはStringリテラルを#tk()で囲むだけ。とてもシンプルです!
2. プリローカライズ済みの共通UI要素
SF Symbolsがアイコンの利用を標準化したように、UIテキストにも一貫性が必要です。TranslateKitは、AppleがiOSでサポートする全40言語にプリローカライズされた2,000以上の文字列を提供します。
4つのカテゴリに分かれており、必要なものを簡単に見つけられます:
// Actions
Button(TK.Action.save) { saveData() }
// => en: "Save", de: "Sichern", etc.
// Labels
Text(TK.Label.privacyPolicy)
// => en: "Privacy Policy", de: "Sichern", etc.
// Messages
Text(TK.Message.areYouSure)
// => en: "Privacy Policy", de: "Datenschutzerklärung", etc.
// Placeholders
ProgressView(TK.Placeholder.loadingDots)
// => en: "Loading…", de: "Laden…", etc.メリット:
AppleのシステムUI翻訳と一致(一貫性)
共通UI要素のプロフェッショナルな品質を保証(正確性)
ローカライズのオーバーヘッドを削減(時間とコストを節約)
3. コンテキストを考慮した翻訳
現代のローカライズは単語を翻訳するだけではなく、コンテキストを理解することが重要です。自動キー生成が90%のケースに対応しますが、場合によってはオプションのcパラメータを追加で指定する必要があります:
struct DocumentView: View {
let fileName: String
var body: some View {
Button(#tk("Delete '\(fileName)'?",
c: "Example: Delete 'MyStats.csv'?")) {
handleDelete()
}
}
}このコメントパラメータが最もよく必要になるのは、上の例のように文字列に動的なデータが含まれている場合です。コメントには常に典型的なサンプルデータを含めることが重要です。そうしないと、翻訳者が適切に翻訳する方法がわからなくなる可能性があります。
次のステップ
この記事では、TranslateKit SDKがコアのローカライズワークフローをどのように近代化するかを紹介しました。複数形、フォーマッタなどのより高度なトピックに興味がある方は、YouTubeチャンネルを登録して関心を示してください:
✨ TranslateKit SDKはTranslateKit for Macと完璧に連携します。正確なAI翻訳ツールで、アプリの残りの部分をローカライズできます!超高速でお手頃価格。無料で試して、より多くのユーザーにリーチしましょう。

