複数の（社内）プロジェクト用の文字列翻訳データベースの構築

私たちの会社には、次のような文字列を格納する既存の翻訳ms-sqlテーブルがあります。

Id |     Key     | Language | Value 
 1 | hello-world |  nl-BE   | Hallo Wereld
 2 | hello-world |  en-GB   | Hello World

システムには3つの言語があり、将来的には最大で約10言語に増えると思います

このテーブルは、複数の非常に異なるプロジェクト（約60のプロジェクト、主にWebサイト/ Webアプリケーションと一部のWebサービス）によって読み取られ、それぞれが翻訳データベースへのデータベース接続を開き、翻訳をキャッシュします。

フロントエンド開発者からのフィードバックは、翻訳の入力または変更のためのUIのUIの最大の欠点は、どのプロジェクトがどの文字列を使用するかを理解できないことです。

彼らは時々それを使って7つのプロジェクトを壊していることを知らずに文字列を変更します。

これで、ユーザーは次のように入力するだけthis.Translate("Hello World")で、あとはシステムが処理します。

もちろん、私はそれらを次のようなものに強制することもできますthis.Translate("Hello World","AwesomeApplication1")が、それは多くの多くのプロジェクトにわたってかなりのリファクタリングを必要とするようです。

このソリューションを提供するにはどうしますか？開発者として、翻訳に「プロジェクト名」をどのように提供しますか？これをデータベースにどのように保存しますか？

重要な注意：翻訳の再利用は一元化されたデータベースの核心なので、次のようにして翻訳を1つのプロジェクトにスコープします

1|hello-world|nl-BE|Hallo Wereld|MyAwesomeApplicatoin1
5|hello-world|nl-BE|Hallo Wereld!|MyAwesomeApplicatoin2

本当に望まれるオプションではありません。

私は次のようなものが好きです：

1|hello-world|nl-BE|Hallo Wereld|MyAwesomeApplicatoin1,MyAwesomeApplicatoin2

または、テーブルに名前を置くだけの外部キーと同等です。

更新

データベースを正規化するというアドバイスに基づいて、これまでに次のようなものを考え出しました。

//this allows me to distinquish if translations where added by developer or by translator

UPDATE2：テキストの代わりにedmxを追加しました。他の人がそれをテストして使用できるように、人々が興味を持っているなら、私はこのコンセプトをラップしてWCFプロジェクトをgithubすることができます。

予備的な注記＃1：現在のところ、翻訳がどのように維持されているかを教えてくれません

予備ノート＃2：データベースは正規化されていません。あなたが最初に、取るつもりだどのような解決策データベースを正規化します。あなたが今それをしなければ、あなたは後でひどいメンテナンス問題に遭遇します

これが私がすることです。

1. プログラムIDをサーバーに戻すように変換呼び出しを書き換えます

2. バックエンドトランスレータは、文字列がまだ存在しない場合はデータベーステーブルに配置し、プログラムIDでタグ付けします。

3. 文字列が既に存在する場合、プログラムIDが文字列の作成に使用された元のプログラムIDと一致する場合にのみ更新されます。そうでない場合は、競合通知を返します。

バリエーション：

• プログラムIDの代わりに「開発者ID /トランスレータID」を使用できます。外国語を知っている人もいれば知っていると思う人もいるので、もっといいと思います。最初のグループのみが変更権限を持っています。

• どのプログラムが競合しているかがわかるように、文字列を使用するすべてのプログラムのIDをDBに保存できます。

• この「所有権」の考え方を個々の言語に拡張できます。1人は英語を、もう1人はオランダ語を話すことができます。

• データベースが正規化されると、「プログラムAは言語1、2、3、Bは3と5にある」などのビルドの複雑さを追加します

私はまた、欠けている翻訳などを表示する別の「翻訳メンテナンス」プログラムを書くことをお勧めします。以前は2レベルの承認でそれを行いました。

彼らは 'this'を参照しているので、プロジェクト名を 'this'に（たとえば、コンストラクターを介して）一度割り当てることができ、翻訳機能へのインターフェースはコーダーにとって変更されません。内部的には、プロジェクト名をデータベースクエリに追加するだけです。または、「これ」を使用して、プロジェクト名を独自に知ることができます。実際のところ、クラスをどのように構造化するかによって異なります。

ストレージについては、次のようなことができます。

1 ! hello-world ! nl-EN ! Hello World  ! *
2 ! hello-world ! nl-EN ! Howdy, World ! CowboyApp
3 ! hello-world ! nl-EN ! Arrgh        ! PirateApp

ワイルドカードを使用してすべてのアプリに一般的な翻訳を適用しますが、特定のアプリの翻訳をオーバーライドする場合は特定のアプリ名を使用します。これにより、重複が最小限に抑えられます。

どのプログラムがどの翻訳を使用しているかを確認するために、これを知っています。その情報を手作業で収集したくない場合は、翻訳要求をログに記録できます。

すべてのプロジェクトがC＃で記述されており、すべてのトランスレーター呼び出しが次のようになっている場合

this.Translate("hello-world")

「hello-world」が変換テーブルのキーである場合、正規表現を使用してすべてのトランスレータコールを検索し、キーワードに対応するプロジェクト名を割り当てる小さなソースコードスキャナーを書くことはそれほど難しくありません。このようにして、既存のコードや変換インターフェースを変更する必要はありません。

プログラムの実際の構造によっては、代わりに、アセンブリのILコードからその情報を抽出する方が簡単な場合があります。先ほど、翻訳の目的でも、このサンプルコードを使用してアセンブリを解析することで、非常によく似たことを行いました。