paint-brush
Swift におけるローカリゼーションの進化: 文字列から文字列カタログへ@mniagolov
1,082 測定値
1,082 測定値

Swift におけるローカリゼーションの進化: 文字列から文字列カタログへ

Maksim Niagolov8m2024/06/12
Read on Terminal Reader

長すぎる; 読むには

Swift は、アプリケーションにローカリゼーションを簡単に組み込むための強力なツールを提供します。このガイドでは、Swift のローカリゼーションの変遷について、初期の手法から最新のツールまで説明し、開発者がこれらの機能を最大限に活用できるようにします。ローカリゼーションは、ユーザー エクスペリエンスを向上させ、その範囲を広げ、国際レベルでのソフトウェアの成功に大きな影響を与える可能性があります。
featured image - Swift におけるローカリゼーションの進化: 文字列から文字列カタログへ
Maksim Niagolov HackerNoon profile picture

昨今、世界はグローバル市場となっており、モバイル アプリケーションをさまざまな言語や文化に対応させることは単なるオプションではなく、必須事項です。ローカリゼーションにより、ユーザー エクスペリエンスが向上し、その範囲が広がり、国際レベルでのソフトウェアの成功に大きな影響を与える可能性があります。


iOS 開発者向けに、Swift はアプリケーションにローカリゼーションを簡単に組み込むための強力なツールを提供しています。このガイドでは、開発者がこれらの機能を最大限に活用できるように、初期の手法から最新のツールまで、Swift でのローカリゼーションの変遷について説明します。


ローカリゼーションにおける初期の課題

当初、Swift が導入されたとき、Swift は Objective-C からローカリゼーション インフラストラクチャを継承しました。これは、 Localizable.stringsファイルとNSLocalizedString関数を中心に構築されていました。このため、開発者はローカライズされた文字列を手動で編集し、異なる言語ファイル間で同期する必要がありましたが、このプロセスはエラーが発生しやすく、時間がかかります。

Localizable.stringsの基本

ローカライズ可能なファイルは、文字列が「キー」=「値」の形式で保存される単純なキーと値のペアのファイルです。ここで、 「キー」はコード識別子で、「値」はユーザーに表示されるローカライズされた文字列です。このファイルは、サポートされている各言語に複製して翻訳し、英語の場合は「en.lproj」 、ドイツ語の場合は「de.lproj」など、対応する適切な「.lproj」ディレクトリに配置する必要があります。

Localizable.stringsエントリの例:

 "hello_world_key" = "Hello, World!";


Swift コードでは、この文字列は次のように取得できます。

 let greeting = NSLocalizedString("hello_world_key", comment: "The default greeting")


NSLocalizedString 関数を使用すると、 Localizable.stringsのキーを使用してローカライズされたコンテンツに簡単にアクセスできます。


この関数はキーを受け取り、フォールバック値を提供し、翻訳者向けのコメントを追加します。コメントを提供することは、翻訳者にサブテキストを提供して翻訳の正確性と適合性を向上させるため、非常に重要です。


例: 時刻に基づいてユーザーに挨拶する:

 func greetingBasedOnTime() -> String { let hour = Calendar.current.component(.hour, from: Date()) let key = hour < 12 ? "good_morning_key" : "good_evening_key" return NSLocalizedString(key, comment: "Greeting based on time of day") }


対応するLocalizable.stringsではエントリは次のようになります。

 "good_morning_key" = "Good morning!"; "good_evening_key" = "Good evening!";


Localizable. 文字列に関して、次のような課題に直面する可能性がある。
1) スケーラビリティの問題。

文字列の数が増えると、処理が難しくなります。時間の経過とともに複数の .strings ファイルを管理するのは面倒になります。


2) 重複。

各言語には個別のファイルが必要で、文字列の管理において不整合や重複作業が発生する可能性があります。サポートする言語が 1 つだけであれば問題にならないかもしれませんが、複数の言語を管理する必要がある場合は面倒すぎることがあります。


3) 文脈の欠如。

ただし、コメントは NSLocalizedString に追加できます。コメントが必ずしも翻訳者のコンテキストを完全に理解するのに役立つとは限らず、翻訳が不正確になる可能性があります。開発者は、コメントを適切に入力するのが面倒な場合がよくあります。

複数形化のためのstringsdictへの移行

stringsdictファイルの導入により、Swift のローカリゼーションが大幅に改善され、主に複数形の問題が解消されました。主な原因は、言語の複数形は異なる方法で形成されるため、英語には効果的でも、ロシア語やアラビア語などの他の言語には効果的ではない可能性があることです。


stringsdictが導入される前は、それらを管理するのは非常に困難でした。stringsdict stringsdict使用すると、プログラマーは「1」、「少数」、「多数」、「その他」などのカテゴリのルールを決定でき、言語間での翻訳の正確さのレベルが同じになることが保証されます。


stringsdictファイルを理解する

Stringsdictファイルは、数値に応じてローカライズされた文字列を作成するために使用される XML プロパティ リストです。この機能は、言語によって複数形を処理するためのルールが異なるため、複数形を正しく処理することを目的としています。

stringsdictファイルの構造:

stringsdictファイルのサンプルには、複数形にする必要のあるすべての文字列のエントリが含まれています。各エントリはキーと辞書で構成され、ユーザーはその中で異なる複数形のカテゴリを表す 1 つ以上のサブキーを定義します。


 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>numberOfSongs</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@songs@</string> <key>songs</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>One song</string> <key>other</key> <string>%d songs</string> </dict> </dict> </dict> </plist>


複数形化にstringsdictを使用する例

ユーザーが読んだ記事の数を表示するアプリケーションがあるとします。画面には、読んだ記事の数の正しい複数形を示すメッセージが表示されます。


英語とポーランド語のLocalizable.stringsdict :

 <!-- English --> <key>article_count</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@articles@</string> <key>articles</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>One article</string> <key>other</key> <string>%d articles</string> </dict> </dict> <!-- Polish --> <key>article_count</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@articles@</string> <key>articles</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>Jeden artykuł</string> <key>few</key> <string>%d artykuły</string> <key>many</key> <string>%d artykułów</string> <key>other</key> <string>%d artykułu</string> </dict> </dict>


ここで、ポーランド語のローカライズは、いくつかの言語における複数形の複雑さを明確に示しており、異なる数値コンテキストを正しく表すには、複数の複数カテゴリ (1、少数、多数、その他) を使用する必要があります。


迅速な実装:

NSLocalizedStringを呼び出すときに、ファイルで定義されたキーを参照するだけで、 stringsdictエントリをコード内で利用できます。

 let count = getArticleCount() let formatString = NSLocalizedString("article_count", comment: "Count of articles read by a user") let message = String(format: formatString, count)

このアプローチにより、サポートされている言語の文法に合わせて出力文字列を適応的に変更できます。これはすべて 1 行のコードで実行できます。


stringsdictの利点

  • 効率性: これにより、ローカリゼーション ファイルの管理と変更に費やされていた時間と労力を節約できます。
  • 精度: 開発環境内でより多くのコンテキストが直接提供されることで、単語翻訳の精度が向上します。
  • 柔軟性: ローカライズされたコンテンツに対するリアルタイムかつ動的な調整をサポートします。

文字列カタログを使用した最新のローカリゼーション手法

Xcode 15 で導入された新機能の 1 つに、開発者が iOS および macOS アプリケーションをこれまでよりもさらに簡単Localizable.stringsローカライズできるようにする文字列カタログがあります。Localizable.strings とstringsdict文字列を保存および整理するための便利なリソースでしたが、文字列カタログはローカライズされた文字列を管理するのにはるかにまとまりがあり、UI フレンドリです。


文字列カタログで強調する必要がある主な側面は次のとおりです。

  • ビジュアル エディター: 従来の単純なプレーン テキスト ファイルとは異なり、文字列カタログは Xcode のビジュアル エディターを使用して編集されるため、ローカライズされた文字列の追加、変更、削除がはるかに簡単になります。


  • インライン ドキュメント: 開発者は文字列カタログ内で説明とコンテキストを直接提供できるため、翻訳の明瞭性と正確性が大幅に向上します。


  • 動的ローカリゼーション: Strings Catalog は動的ローカリゼーションをサポートしているため、開発者はアプリケーションを終了せずにローカライズされた文字列を変更できます。これは、テストや反復的な開発に最適です。


  • 高度な複数形化と適応: また、複数形をより細かく制御し、UI 要素やデバイスの種類に応じてバリエーションのあるテキストを提供することで、 stringsdictの欠点のいくつかを克服します。


迅速な実装:

メッセージング アプリケーションで、ユーザーに未読のメッセージの数を通知する必要があるとします。通知は、受信したメッセージの数を表示して動的にする必要があり、コンテンツの種類に応じて調整する必要があります。


ステップバイステップのセットアップ:

  1. 文字列カタログを作成する:プロジェクトに新しい文字列カタログを追加します。これにより、 .stringcatalogファイルが生成されます。


  2. エントリの追加:エディターを使用して、ローカライズする必要がある各文字列のエントリを追加します。次に、各エントリのキー、デフォルト値、および複数形のルールや適応パラメータを指定します。


  3. コンテンツのローカライズ:サポートされている各言語の翻訳を提供し、複数形の異なる形式やデバイス タイプへの適応などを指定します。


  4. コードで実装: Swift コードでローカライズされた識別子を使用してこれらの文字列を参照します。


 <!-- String Catalog Entry --> <key>unread_messages_count</key> <dict> <key>NSStringLocalizedFormatKey</key> <string>%#@messages@</string> <key>messages</key> <dict> <key>NSStringFormatSpecTypeKey</key> <string>NSStringPluralRuleType</string> <key>one</key> <string>You have one unread message.</string> <key>other</key> <string>You have %d unread messages.</string> </dict> </dict>


この文字列には次のようにアクセスできます:

 let unreadCount = fetchUnreadMessagesCount() let message = NSLocalizedString("unread_messages_count", value: "You have \(unreadCount) unread messages.", comment: "Notify about unread messages") print(message)



文字列カタログの利点

  • 効率性: ローカリゼーション ファイルの管理に必要な時間と労力を節約します。


  • 精度: 開発環境で直接的なコンテキストをさらに追加することで、精度が向上します。


  • 柔軟性: ローカライズされたコンテンツに対するリアルタイムの更新や動的な更新をサポートします。これは、急速な開発サイクルで特に役立ちます。

課題

文字列カタログは大幅な改善をもたらしますが、課題も伴います。まず、学習曲線があります。新しいシステムや何かを作成する方法に慣れるには時間がかかります。開発者が直面する可能性のあるもう 1 つの潜在的な課題は、従来のローカリゼーション ファイルが既に作成され使用されている既存のプロジェクトに文字列カタログを統合するために必要な時間と調整に関連しています。

結論

Swift の文字列カタログは、ローカリゼーション テクノロジをさらに改良した最新のもので、強力なだけでなく、柔軟で使いやすいツールを提供します。このテクノロジを開発ライフサイクルの一部として追加することで、チームはローカリゼーション プロセスの効率と品質を大幅に向上させ、より優れたグローバル製品を作成できます。


Swift ローカリゼーション ツールの最新の開発状況に合わせて、この記事を継続的に更新していきます。何か抜けている点があると感じた場合や、私の発言についてご意見がある場合は、下のコメント ボックスで共有してください。興味深い情報や最新ニュースをさらに入手するには、ぜひ私をフォローしてください。