17

したがって、私たちは製品を国際化して、最終的には国際化する必要があると確信しています。私たちが進むにつれて、どれだけ国際化することをお勧めしますか?

言い換えれば、今は簡単ですが、コードベースを成熟させればさらに悪化する可能性があり、今から始めてもそれほど遅くならない国際化はあるのでしょうか。

使用した技術:C#、WPF、WinForms

4

7 に答える 7

33

コードベース自体にすべての文字列を書き込む前に、今すぐ準備してください。

これからのすべては手遅れになります。それは今しかないです!

確かに、今すぐ準備するのは少し余分な努力ですが、それをしないと、はるかに高価になります。

以下のリンクのすべてのガイドラインに従わない場合は、少なくとも、要約のポイント1、2、および7に注意してください。これらは、現在非常に安価であり、その後の私の経験で最も苦痛をもたらします。

これらのガイドラインを確認し、今すぐ始めてすべてを準備する方がよい理由を自分で確認してください。

  1. 世界に対応したアプリケーションの開発

  2. 世界に対応したアプリケーションを開発するためのベストプラクティス

少し抽出:

  1. ローカライズ可能なすべてのリソースを個別のリソース専用DLLに移動します。ローカライズ可能なリソースには、文字列、エラーメッセージ、ダイアログボックス、メニュー、埋め込みオブジェクトリソースなどのユーザーインターフェイス要素が含まれます。(後でリソースをDLLに移動するのは面倒です)
  2. 文字列やユーザーインターフェイスリソースをハードコーディングしないでください。(準備しないと、文字列をハードコーディングすることがわかります)
  3. ローカライズできないリソースをリソースのみのDLLに入れないでください。これは翻訳者に混乱を引き起こします。
  4. 連結されたフレーズから実行時に作成される複合文字列は使用しないでください。複合文字列は、すべての言語に適用されるわけではない英語の文法順序を想定していることが多いため、ローカライズが困難です。(インターフェース設計後、フレーズの変更は難しくなります)
  5. 文字列のコンポーネントの文法上の役割に応じて文字列を異なる方法で変換できる「EmptyFolder」などのあいまいな構造は避けてください。たとえば、「空」は動詞または形容詞のいずれかであり、これにより、イタリア語やフランス語などの言語で異なる翻訳が行われる可能性があります。(同じ問題)
  6. アプリケーションでテキストを含む画像やアイコンを使用することは避けてください。ローカライズするには費用がかかります。(画像上にレンダリングされたテキストを使用)
  7. 文字列の長さをユーザーインターフェイスで拡張するための十分なスペースを確保してください。一部の言語では、フレーズに50〜75パーセント多くのスペースが必要になる場合があります。(同じ問題ですが、今計画していない場合は、再設計の方が費用がかかります)
  8. System.Resources.ResourceManagerクラスを使用して、カルチャに基づいてリソースを取得します。
  9. Microsoft Visual Studio .NETを使用してWindowsフォームダイアログボックスを作成し、Windowsフォームリソースエディター(Winres.exe)を使用してローカライズできるようにします。Windowsフォームダイアログボックスを手動でコーディングしないでください。
于 2008-11-06T23:58:30.163 に答える
4

私見、「数年以内に」何かが起こると主張することは、文字通り「いつかは願っています」という意味で、実際には「決して」という意味ではありません。恐ろしい間違いをしないように、さまざまなチュートリアルをざっと見ていきますが。現在正しい国際化サポートを行うことは、将来の作業が少なくなることを意味し、一度慣れれば、今日の生産性に実際の影響を与えることはありません。しかし、数年で目標を測定できれば、今はまったく価値がないかもしれません。

私は国際化を行った2つのプロジェクトに取り組んできました。C#ASP.NET(プロジェクトに参加する前に存在していました)アプリとPHPアプリ(無料の国際化コントロールと独自の管理アプリを使用して独自の方法を自作しました)です。

すべてのテキスト(ラベル、ボタンテキストなど)をデータとしてデータベース内に保存する必要があります。これらをキーで参照し(最初の4語を使用し、大文字にし、スペースをアンダースコアに変換し、非英数字を削除します)、重複している場合は、末尾に数字を追加します。このキーメソッドの利点は、プログラマーがキーを見るだけでテキストの内容をかなり深く理解できることです。

データを抽出し、コンパイルのためにプロジェクトに追加する.NETリソースファイルをビルドするユーティリティを作成します。言語ごとに個別のリソースファイルを作成します。コードで、キーを使用して適切なエントリをポイントします。

この件に関するMSドキュメントをざっと読みます:http: //www.microsoft.com/globaldev/getwr/dotneti18n.mspx

避けるべきいくつかの基本的なこと:

  • 翻訳ソフトウェアを使用することは決してありません。地元の大学でその言語を使用するプロやインターンを雇ってください。
  • 文法は言語ごとに大きく異なるため、2つの既存のエントリを追加してテキストを作成しようとしないでください。これは機能しません。したがって、「クリック」という文字列があり、「今すぐクリック」という文字列が必要な場合は、2つのエントリをマージする設定を作成しないでください。翻訳中に、クリックする単語をコピーして、今すぐ翻訳してください。すべての文字列を最初からまったく新しい翻訳として扱います
于 2008-11-07T00:04:23.800 に答える
2

I will add to store and manipulate string data as Unicode (NVARCHAR in MS SQL).

于 2008-11-07T00:38:36.243 に答える
1
于 2009-06-02T11:45:01.990 に答える
0

テスト データを使用する場合は、英語以外 (ロシア語、ポーランド語、ノルウェー語など) の文字列を使用してください。エンコーディングは、隅々に小さな醜い頭を覗かせます。自分のライブラリにない場合は、外部のライブラリに。

私は個人的にロシア語を好みます。なぜなら、私はロシア語を話せませんが (私の名前の由来にもかかわらず)、ロシア語には外国語の文字が含まれており、英語よりも多くのスペースを必要とするため、スペーシングもテストされるからです。
それが言語固有のものなのか、それともロシア語の翻訳者が冗長な文字列が好きなだけなのかはわかりません.

于 2008-12-29T09:44:44.143 に答える
0

国際化は、あなたの製品を他の国でも使用できるようにします。それは簡単で、最初から実行する必要があります (このようにして、世界中の英語を話す人々があなたのソフトウェアを使用できるようになります)。これらの 3 つのルールは、ほとんどの場合、次のようになります。

  1. 国際文字をサポート - ファイルとデータベースでは Unicode データ型のみを使用してください。
  2. 国際的な日付、時刻、および数値の形式をサポートします。データをファイルまたはコンピューターで読み取り可能なストレージに保存する場合は CultureInfo.InvariantCulture を使用し、データを表示する場合やユーザー入力を解析する場合は CultureInfo.CurrentCulture を使用します。独自の解析を行ったり、他のカルチャ オブジェクトを使用したりしないでください。
  3. ユーザーが入力したテキスト データはブラック ボックスと見なす必要があります。特にユーザーに表示する場合は、単語や文字に分割しようとしないでください。言語によって回折規則があり、OS は左から順に表示する方法を知っています。正しいテキスト、そうではありません。

ローカリゼーションとは、ソフトウェアを別の言語に翻訳することです。これは困難で費用がかかります。文字列をハードコーディングしたり、小さな文字列から文を作成したりしないことから始めることをお勧めします。

于 2008-12-29T10:39:10.507 に答える