ソフトウェアの地域化は、ソフトウェアのユーザー インターフェイスをある言語から別の言語に翻訳し、それを現地の文化に適応させるプロセスに関係します。私たちはローカライゼーションという用語を時々使用します。これは、英語の単語localization (偽の友人) を置き換えたものです。ローカリゼーションという単語はlとnで囲まれた 10 文字で構成されているため、 l10nと書くこともあります。
ソフトウェアを地域化する前に、まず国際化する必要があります。つまり、さまざまな言語や文化に翻訳できるように作成されている必要があります。
このプロセスには開発チームの多大な労力と労力が必要となるため、リージョン化プロセスを簡素化するツールが作成されています。これらのプロジェクトの多くは、コスト削減のために専門会社に委託されています。
ソフトウェアの地域化は、ソフトウェアを文化に適応させることでもあります。ロケール設定は通常、さまざまなアプリケーションで共有されます。一部の特殊なアプリケーションには独自の設定が必要です。 Unicodeコンソーシアムは、これらのロケールの標準化であるCommon Locale Data Repositoryプロジェクトに取り組んでいます。
地域化に関する問題
地域化に関する最初の問題は、翻訳された文の文脈の問題です。実際、インターフェイスでは、文が文脈に従って組み立てられた複数のエンティティで構成される場合があり、翻訳ソフトウェアではそれらが分離され、文脈から外れて表示されます。たとえば、次のような文
- タスクxを実行できません:オブジェクトy は仕様zに準拠するオブジェクトではありません。
「タスクxを実行できません:」と「オブジェクトy は仕様zに準拠したオブジェクトではありません。」という 2 つの文字列が別々に表示される場合があります。場合によっては、コロンの後に別の文が表示される場合もあります。さらに、名前x 、 y 、 z自体は個別に保存され、異なる場合があります。したがって、翻訳者は、文章がどのように構成されるかわからないまま、部分的な文章を翻訳することになります。
一貫性とフォーマットの問題もあります。つまり、文の関連付けはターゲット言語で意味をなすかどうかということです。最初の文字の前にスペースを入れるか、最後の文字の後にスペースを入れるべきでしょうか?…
ほとんどのプログラムには「ショートカット」があります。つまり、 [Ctrl]+ lettreまたは[Alt]+ lettreキーの組み合わせなどにより、最も頻繁に使用されるコマンドにすばやくアクセスできます。この方法はあまり直感的ではありませんが、経験豊富なユーザーの作業が容易になります。問題の文字は通常、コマンドの名前 (通常は先頭) に関連しています。それでは、ニーモニック文字を維持するために、ターゲット言語で別の文字を使用する必要があるでしょうか?これにより、一貫性の問題 (選択した文字が別の意味を持たないように注意する必要があります) と翻訳者の可能性の問題が生じます。つまり、翻訳インターフェイスでこの操作を実行できるのか、それともコードを変更する必要があるのかという問題が生じます。
この文字を変更できない場合は、マニュアルにニーモニックを示す必要があります。さらに、このコマンドがメニューにある場合、文字に下線が引かれることがあります。同じショートカット文字を使用するが、それが頭文字ではない場合は、忘れずに頭文字の下線を解除し、単語内の他の場所にその文字が存在する場合は下線を引く必要があります。
翻訳者に関しては、理想的には、対象言語を完全に使いこなせる必要があります。したがって、その言語の話者であり、その言語を学習しており、特定の語彙を知るために技術分野をよく知っていて、ソフトウェアを使いこなす必要もあります。文章の文脈を理解するために。これにより、翻訳に割り当てられるリソースの問題が生じます。困難な場合には、チームが必要になるか、珍しい宝石が必要になるかのどちらかです。いずれの場合も、翻訳者は開発者とコミュニケーションできる必要があります。
さらに、特定の文字列は意味を持たず、書式設定の指示 (改行、変数の書式など) であるため、翻訳者はこれらの特定の文字列を認識し、それらを翻訳しないように訓練する必要があります。コンテキスト。また、特定の役割を持つチャネル、たとえばソフトウェアによって検出され、特定のアクションをトリガーするチャネルにも注意する必要があります。これはむしろ上流のプログラミングの問題であり、国際化の観点から言えば、いかなるメカニズムも単語や語句の検索を伴うべきではありません。あるいは、少なくともそのような文字列は「ハードコード化」するのではなく、変数に入れて翻訳する必要があります。関連する方法で。
特殊なケースは、マクロ命令言語の場合です。ある言語のソフトウェアで作成されたマクロは、他の言語のソフトウェアでも使用できますか?これは本質的に、命令の表現の問題を引き起こします。命令が翻訳された場合、その単語はターゲット言語で保存されるのでしょうか、それとも別の方法で (元の言語で、または言語形式で) 保存されるのでしょうか。コード)、単語がディスプレイ上で翻訳されるだけですか?このケースは、たとえばMicrosoft Excelマクロで発生しました。
次に、インターフェイスの問題が発生します。メッセージの長さは言語によって異なるため、翻訳者はテキスト ボックスとボタンのサイズを変更する必要がある場合があります。
最後に、言語によっては左から右に書かれる場合もあれば、右から左に書かれる場合もあれば、上から下に書かれる場合もあります。このコンテキストでは、コントロール(ボタン、チェック ボックス、カーソル、入力ボックスなど) に付随するテキストをどこに配置する必要がありますか?
設計段階から計画するアプローチ
地域化はソフトウェアの設計から計画し、仕様の一部として含める必要があります。設計者は、タスクを容易にする開発標準に従う必要があります。例えば ：
- 上で述べたように、ハードコーディングされた (自然言語) 単語は使用せず、体系的に変数に入れます (たとえば、アクションをトリガーするためにテキスト内で検索される文字列、 「none」などの単語の典型的なケース)。
- テキスト用に確保されているスペースを拡張するために、グラフィカル インターフェイス内のオブジェクトの間隔を空けます。
- オブジェクトにタイトルが付けられている場合は、タイトルをオブジェクトの上に配置します。これにより、タイトルのサイズに応じてオブジェクトを移動したりサイズ変更したりする必要がなくなります。
- …
ITリージョナライゼーション支援ツール
Linuxでは、多言語コンピューター プログラムの作成を可能にするために po 形式が使用されます。 poファイルは、英語版のシステム メッセージと、翻訳された同等のメッセージが含まれるテキスト ファイルです。
- Lingobit Localizer 、.Net、MFC、Java 用のローカリゼーションツール
- Gettext : Linux を実行するほとんどのフリー ソフトウェアで使用されます。
- Codito (Delphi プロジェクト);
- マルチライザー (Delphi プロジェクト)。
- Visual Localize (AIT)、 Microsoft Windows Visual Studioおよび .NET プロジェクト用
- Accent Softwareの Loc@le™、 Microsoft Windows用 (配布は終了したようです)
