実際、その後簡単にローカライズされるソフトウェアの作成では、最終結果を念頭に置いて作成を開始すれば、それほど複雑なことはありません。 Alconostでは 、製品が国際的である場合にワークロードを大幅に削減するのに役立つテクニックについての記事を翻訳しました。
ユーザーに個別に行を表示する
ローカライズの準備のための間違いなく最も重要な（そして最も無視される）ルールは、それらを使用するコードからユーザーに見えるすべての行を分離することです。
この場合の通常のアプローチは、製品のテキストコンテンツをプラットフォームまたは言語ごとに個別のリソースファイルに保存することです。 たとえば、Javaプログラマは、 ResourceBundleファイルに表示行を保持する必要があります。
アプリケーション内のテキストは、構造的にアプリケーションロジックに結び付けてはいけません。 表示された行は、アプリケーションの操作や他の機能に影響を与えることなく、変更のために常にアクセス可能でなければなりません。
興味深いことに、このタスクは、コードからテキストコンテンツを自動的に抽出し、翻訳のために人々に送信し、既製のローカライズされたコンテンツをオンラインで公開できる新しいテクノロジーのおかげで、Webアプリケーションにとってますます重要になりつつあります。アプリケーションコード。 このアプローチにより、アプリケーションを多言語化するための労力と時間を大幅に削減できます。
表示される行が長くなったり短くなったりする場合があることに注意してください。
英語のフレーズは、他の言語に翻訳すると2倍の長さになり、一部の言語では著しく減少する場合があります。 プログラムコードとGUIのコンポーネントが、表示される行の一定の長さに依存しないことが重要です。
もちろん、これはユーザーにテキストのグラフィカル表現を作成するときに作業を追加しますが、 これを正しく行うには多くの方法があります 。
テキストなしの画像を使用する
会社のロゴや製品を除くすべての場合、テキストの一部である画像の使用は避ける必要があります。このテキストコンテンツの翻訳はより困難になるためです。 テキストファイルの内容をすぐに翻訳するのではなく、画像を変換し、翻訳されたテキストを言語ごとに個別に配置するグラフィックデザイナーを雇う必要があります。
カレンダーの形式、時間、電話番号、通貨システムの違いを考慮する
コード作成者は、他の国では次のことができることを常に覚えておく必要があります。
- 別の日時形式を使用する
- 週の他の曜日の休日と見なすこと。
- まったく異なるカレンダーシステムを使用します 。
- 月名よりも週番号を使用することを好みます。
- 1時間未満の オフセットステップでタイムゾーンにいる;
- 異なる測定システムを使用します。
- 別の通貨またはお客様の通貨以外の通貨を使用してください。
- 電話番号の形式が異なります。
これらすべてをチェックリストに入れて 、コードをチェックし、製品の多言語使用を制限する可能性のあるハードコーディングを防止します。
確立された国際的なデータストレージ標準を常に使用します。 たとえば、電話番号にはE.164 、タイムスタンプにはISO-8601 、言語にはISO 639.2 、国にはISO 3166 、タイムゾーンにはtzデータベースを使用します。
ASCIIを避け、Unicodeを使用
以前は、英語圏市場専用のソフトウェアを作成した開発者は、 ASCIIエンコードを使用した場合にのみ機能するコードに技術を静かに実装していました。 たとえば、アルファベット文字の1ビットをASCIIから変更すると、大文字から小文字に切り替えられました。 ただし、それ以来、世界のニーズはASCIIの能力をはるかに超えており、現在ではテキストデータをエンコードし、国際文字をサポートする正しい方法としてUnicodeが受け入れられています。
UnicodeがASCIIと互換性がある場合でも、文字列エンコードの問題を回避する最善の方法は、次の規則に従うことです。
- ASCIIで文字エンコードを許可しないでください。
- 1バイトが1文字に等しいという事実に頼らないでください。
- 常にUnicode互換のフォントとライブラリを使用します。
幸いなことに、Java、C＃、Objective-Cなど、これまでで最も人気のあるプログラミング言語には、文字列型のネイティブUnicodeサポートが含まれています。 それらの使用は、国際的なシンボルの問題の解決策を一般的なものに変えます。
アプリケーションがUnicodeを完全にサポートしている場合でも、データベースにデータを格納する可能性があり、貧弱な論理データ構造は、国際的なエンコーディングとの互換性のためにコードで行われたすべての作業を簡単に台無しにする可能性があります。 たとえば、SQL Serverデータベースでは、表示される行はnvarchar型で保存する必要がありますが、MySQLではutf8mb4を使用するのが最適です。
Unicodeの詳細については、 Joel Spolskyの 入門記事をご覧ください 。
テキストは常に左から右に読み取られるわけではないことに注意してください。
テキストの表示における最も一般的な違いは、アラビア語とヘブライ語のように、 右から左へのスペルです。
Webアプリケーションでは、システム全体のCSS方向プロパティを変更するだけで、右から左に記述する言語に翻訳するときに発生する主な問題を解決できます。
また、テキストは上から下に読み取られますが、 頻度はずっと低くなります。
ユーザーに表示されるテキストはシンプルでなければなりません。
他の市場向けにアプリケーションメッセージをローカライズする場合、翻訳者はシンプルでクリアなテキストを簡単に操作できます。
専門用語に類似した過度に技術的な言語は、十分に翻訳されない可能性があります。 ニッチではなく、めったに見つからない通常のフレーズや用語を使用することをお勧めします。
基本的な多言語サポートをテストする
優れた開発者は、自分が作成する製品の機能について自動化されたテストを本能的に作成します。 製品が国際文字をサポートしていることを確認するために、さらにいくつかのテストを製品検証キットに追加することは非常に価値があり、それほど労力はかかりません。
たとえば、コンサートのチケットを予約するためのWebアプリケーションを想像してください。 偽の名前「Ivan Ivanov」を持つユーザーが座席を予約でき、支払い後に受け取るチケットに自分の名前が正しく表示されることを確認するテストがすでに作成されているとします。 ユーザー名を「Ivan-假会河Ivanov-沖批批」に変更し、支払い後に同じ文字がチケットに表示されることを確認する簡単なテストを追加して、国際文字サポートがアプリケーションとデータベース。 この単純なアプローチ（「 擬似ローカリゼーション 」と呼ばれることもあります）により、開発者は、製品の完全な専門翻訳や開発者自身からの完全な言語知識を注文することなく、アプリケーションが国際文字を含む文字列の転送と保存をサポートしているかどうかを確認できます。
自動テストにはさらに多くの機能があります。 彼らの助けを借りて、製品コードの基礎をやり直すことなく、右から左に読み取られたフィールドが正しく機能するかどうか、または国際的な複数形がサポートされているかどうかを確認できます。
グローバルな機会を受け入れる
国際的に使用できるソフトウェアの開発は、見た目や以前のように複雑ではありません。 これらの単純なルールに従い、最初はもう少し作業を行うことで、計画よりもはるかに大きな市場での使用に適したソフトウェア製品を作成できます。 そのため、便利な製品がより手頃な価格になります！
アルコノストでは 、ソフトウェアのプロによるローカリゼーションを迅速かつ効率的にお手伝いさせていただきます。
翻訳者について
この記事はAlconostによって翻訳されました。
Alconostは、60の言語でアプリケーション、ゲーム、およびサイトをローカライズします 。 ネイティブ翻訳者、言語テスト、APIを備えたクラウドプラットフォーム、継続的なローカリゼーション、プロジェクトマネージャー24時間365日、あらゆる形式の文字列リソース。
また、Google PlayとApp Storeの販売、画像、広告、教育、ティーザー、エクスプライナー、予告編のサイト向けに、 広告および教育用ビデオを作成しています。
詳細： https : //alconost.com