7

世界中で販売したい場合は、完全に国際化されたアプリケーションが必要です。Java ではリソース バンドルを使用しており、これにより静的テキスト コードサイドの問題が解決されます。

しかし、データベースに保存されているテキストについてはどうすればよいでしょうか? 静的な定義から始まり、ユーザーが変更可能なオブジェクトまで、ユーザーが入力したデータで終わります。

異なるロケールのユーザーが使用するデータベースがあると仮定すると、これをどのように処理しますか? 国際化はどこまで進んでいますか？どこに線を引きますか？ユーザーが理解できない言語のテキストを受信しないようにするには、どのような回避策がありますか?

4

7 に答える 7

6

システムで生成されたテキストをデータベースに保存しないでください。代わりに、コード (メッセージ番号など) を保存し、GUI レベルで国際化します。データベースから直接取得されるテキストのみが、ユーザーが自分で入力したテキストであることを確認してください。データベースが Unicode テキストを受け入れるように設定されていることを確認してください。

于 2008-11-24T13:27:20.690 に答える
2

まず、制限を十分に認識してください。ユーザーが作成したコンテンツの場合、ユーザーがアプリケーションに入力するものをローカライズしたい場合は、コミュニティ翻訳 (不安定)、機械翻訳 (信頼性が低い)、または有償の人間の翻訳者 (高額!) を検討しています。デフォルト カルチャ (英語?) 用とローカライズされたカルチャ用の 2 つのバージョンを提供するようにユーザーに依頼したい場合があります。これにより、他のユーザーにフォールバック翻訳を提供できます。

第二に、非常に長いデータベースの移行に備えてください... Excel スプレッドシートに 4 列のテキストがある場合、突然、各値を翻訳システムに挿入し、ローカライズされた ID を取得して、それを保存する必要があります。実際にインポートしているテーブルではSELECT *、翻訳テーブルに対してローカライズして文字列に戻す必要があるフレーズ ID のみが提供されます。

とはいえ、典型的なプロジェクトでデータベースによって駆動される多くのルックアップ テーブル、ドロップダウン リストなどをローカライズできます。他のコメントでは、外部リソース ファイルまたはスプレッドシートを参照する StringId 値をデータベースに保存することについて既に言及されていますが、ローカライズされたすべてのテキストをデータ自体と一緒にデータベースに保持することに関心がある場合は、このアプローチが役立つことがあります。

Phrase という名前のテーブルを使用しました。このテーブルには、アプリケーション内のすべてのテキストの ID とデフォルト (英語) のコンテンツが含まれています。

他のテーブルは次のようになります。

CREATE TABLE ProductType (
    Id int primary key,
    NamePhraseId int, -- link to the Phrase containing the name of this product type.
    DescriptionPhraseId int
)

サポートしている特定のニュートラル カルチャを含む 2 番目のテーブル Culture を作成します。ボーナス ポイントとして、このテーブルを自己参照ツリーとして実装します (各カルチャ レコードには null 許容の ParentCultureCode 参照が含まれます)。これにより、特定のカルチャ (カナダ フランス語の「fr-CA」) からニュートラル カルチャ (「fr」) にフォールバックできます。地域のローカリゼーションが存在しない場合)、不変/既定のカルチャ (通常は「en」が広く使用されているため)

実際の翻訳は、次のような LocalizedPhrase テーブルにあります。

CREATE TABLE LocalizedPhrase (
  PhraseId int primary key,
  CultureCode varchar(8) primary key,
  Content nvarchar(255) -- the actual localized content
)

男性/女性固有のローカライズを提供する場合は、このモデルを拡張できます。

CREATE TABLE GenderedLocalizedPhrase (
  PhraseId  int primary key,
  CultureCode varchar(8) primary key,
  GenderCode char(1) primary key, -- 'm', 'f' or '?' - links to Gender table
  Content nvarchar(255)
)

このテーブル グラフ全体をメモリにキャッシュし、それに応じてクエリ/結合戦略を変更する必要があります。Phrase クラス内にローカリゼーションをキャッシュし、Phrase オブジェクトの ToString() メソッドをオーバーライドして現在のスレッド カルチャを検査するのが 1 つの方法です。クエリ内でこれを実行しようとすると、かなりのパフォーマンス コストが発生し、すべてのクエリが次のようになります。

-- assume @MyCulture contains the culture code ('ca-FR') that we are looking for:
SELECT 
    Product.Id, 
    Product.Name, 

    COALESCE(ProductStatusLocalizedPhrase.Content, ProductStatusPhrase.Content) as ProductStatus, 
    COALESCE(ProductTypeLocalizedPhrase.Content, ProductTypePhrase.Content) as ProductType, 
  FROM Product

    INNER JOIN ProductStatus ON Product.StatusId = ProductStatus.Id
    INNER JOIN Phrase as ProductStatusPhrase ON ProductStatus.NamePhraseId = Phrase.Id
    LEFT JOIN LocalizedPhrase as ProductStatusLocalizedPhrase 
      ON ProductStatus.NamePhraseId = ProductStatusLocalizedPhrase.Id and CultureCode = @MyCulture

    INNER JOIN ProductType ON Product.TypeId = ProductType.Id
    INNER JOIN Phrase as ProductTypePhrase ON ProductType.NamePhraseId = Phrase.Id
    LEFT JOIN LocalizedPhrase as ProductTypeLocalizedPhrase 
      ON ProductType.NamePhraseId = ProductTypeLocalizedPhrase.Id and CultureCode = @MyCulture
于 2008-11-24T14:19:15.077 に答える
1

ユーザーが理解できない言語のテキストを受け取らないようにするには、どのような回避策がありますか？

これは、ユーザーが入力したデータの場合にのみ問題になります。したがって、他のユーザーが理解できない可能性のある言語でコンテンツを表示しないようにする場合は、ロケールコードをコンテンツと一緒に保存し、同じロケール/ユーザーが選択した言語を持つユーザーにのみそのコンテンツを表示します。

一方、ユーザーはいくつかの言語を知っている可能性があるため、コンテンツの表示を制限しません。「このコンテンツは選択した言語では利用できません...」などの通知を追加して、コンテンツを利用可能な言語。このようにして、ユーザーが理解できるコンテンツを取得する可能性を高めます。

于 2008-11-24T13:42:41.750 に答える
1

データベース内の多くのテキストを「key:default text」に変更してから、翻訳ファイルで「key」を調べています。これは、顧客がデータベースで変更しないすべてのテキストをカバーします (たとえば、「信用状」と呼ぶもの)。顧客がテキストを変更した場合は、キーを削除するだけで、常にそこにある価値を得ることができます。

私たちのシステムには、上記を必要とする構成データを含むテーブルがいくつかあります。各顧客が単一の言語のみを必要とする場合、顧客が入力したテキストのみを含むテーブルは問題になりません。

于 2009-06-02T11:57:08.487 に答える
0

システムにはXMLファイルを使用しています。このファイルには、モジュールの特定の部分との主要な関連付けが含まれています。このようにして、XPathをすばやく実行して情報を取得できます。言語ごとに1つのファイルがあります（現時点では2つの言語をサポートしていますが、言語の追加はファイルをコピーして貼り付けるだけで非常に簡単です）。このソリューションは完璧ではありませんが、いくつかの利点があります。

  1. データベースにありません。
  2. プログラミングの外部の誰かが編集できます。
  3. 複数のビューで簡単に実装できます（WinFormとWebFormがあります）。
于 2008-11-24T13:42:40.127 に答える
0

静的データは変換テーブルを作成するのに最も簡単なので、StatusId、TranslationToken を持つ UserStatus テーブルを想像してください。次に、TranslationTable にはトークン、言語、およびテキストがあります。

または同様に、アプリケーションがリソース ファイルを使用して処理するトークンを返すこともできます。

ユーザー入力データに関しては、これははるかに複雑です。少なくともユニコード文字を受け入れる必要がありますが、問題は並べ替えと比較になります。一番大きいのは並べ替えです。できることの多くは、アプリケーションによって異なります。そのため、データベースが任意の時点で 1 つの言語のみをサポートする必要がある場合 (アプリケーションが顧客に配布された場合を想像してください)、照合はインストール時に設定できるため、議論の余地があります。

ただし、単一のデータベース内で複数の言語をサポートする必要がある場合は、照合を適切に処理する必要があります。照合をオンザフライで変更するために見つけた唯一の方法は、クエリ内で設定することであり、動的 SQL を生成する必要がありました。この例では、ロシア語、英語、ポーランド語をすべて同じテーブルの 1 つのフィールドに格納しています。

私たちはラテン語とキリル文字の照合以外を調査したことはありませんが、アジアの言語も同じように機能すると思います。

于 2008-11-24T13:32:33.160 に答える