ASP.Net MVCアプリケーションを開発していますか？その他の答えは、デスクトップアプリケーションに固有のようです。一般的なものをキャプチャしてみましょう。
ロケール検出
アプリケーションがユーザーのロケールを正しく検出することは非常に重要です。デスクトップアプリケーションでは、CultureInfo.CurrentCultureは優先フォーマットロケール（数値、日付、通貨などのフォーマットに使用されるべき）を保持しますが、CultureInfo.CurrentUICultureは優先ユーザーインターフェイスロケール（ローカライズされたメッセージの表示に使用されるべき）を保持します。Webアプリケーションの場合、派手なロケール検出ワークフローを実装する（つまり、オンデマンドで言語の変更をサポートする）場合を除き、両方のカルチャをauto（AcceptLanguageヘッダーからロケールを自動的に検出する）に設定する必要があります。
文字列を外部化する
すべての文字列はリソース、つまりResxファイルから取得する必要があります。Winformsアプリでは、フォームのLocalizableプロパティをtrueに設定することで簡単に実現できます。また、モデルから取得した文字列を手動で（残念ながら）外部化する必要があります。また、比較的簡単です。Asp.Netでは、すべてを手動で外部化する必要があります...
レイアウト
文字列の展開を許可する必要があります。Winformsの世界では、より長いテキストに対応するためにレイアウトが自動的に調整されるようにするために使用する必要があるTableLayoutPanelを介して実現できます。ウェブの世界では、あなたは少し運が悪いです。CSSローカリゼーションメカニズム-CSS定義を変更（オーバーライド）する方法を実装する必要がある場合があります。これにより、ローカリゼーション担当者は、オンデマンドでスタイルの問題を修正できます。レンダリングされたページの各HTML要素が一意のIDを持っていることを確認してください-正確に対象を指定できます。
文化固有の問題
西洋文化に特有のグラフィック、色、音の使用は避けてください。本当に必要な場合は、ローカライズの手段を提供してください。方向に敏感なグラフィックスは避けてください（アラビア語やヘブライ語を言うためにローカライズしようとすると問題になるため）。また、全世界が同じ数字を使用していると仮定しないでください（つまり、アラビア語には当てはまりません）。
ToString（）およびParse（）
サポートされていない限り、ToString（）を呼び出すときは、必ず CultureInfo を渡してください。そうすれば、あなたはあなたの意図にコメントしています。例：内部で何らかの数値を使用しており、何らかの理由でそれを文字列に変換する必要がある場合：
int i = 42;
var s = i.ToString(CultureInfo.InvariantCulture);
ユーザーに表示される数値の場合：
var s = i.ToString(CultureInfo.CurrentCulture); // formatting culture used
同じことがParse（）、TryParse（）、さらにParseExact（）にも当てはまります。CultureInfoを適切に使用しないと、いくつかの厄介なバグが発生する可能性があります。これは、Microsoftの貧しい人々が、善意に満ち、CultureInfo.CurrentCultureを既定の1つとして扱うことをお勧めすることを決定したためです（何も渡さない場合に使用されます）-結局、誰かがToString（ ）ユーザーに表示したいですか？常にそうであるとは限りません-たとえば、アプリケーションのバージョン番号をデータベースに保存してから、バージョンクラスのインスタンスに変換してみてください。幸運を。
日付とタイムゾーン
DateTime を常に UTCで保存およびインスタンス化してください（DateTime.NowではなくDateTime.UtcNowを使用してください）。表示時にローカル形式でローカル時間に変換します：
DateTime now = DateTime.UtcNow;
var s = now.ToLocalTime().ToString(CultureInfo.CurrentCulture);
本文に時間参照を含むメールを送信する必要がある場合は、必ずタイムゾーン情報を含めてください。UTCオフセットと都市のリストの両方を含めてください。
DateTime someDate; // i.e. from database
var formattedDate = String.Format("{0} {1}",
someDate.ToLocaleTime().ToString(CultureInfo.CurrentCulture),
TimeZoneInfo.Local.DisplayName);
複合メッセージ
すでに文字列を連結しないように警告されています。代わりに、おそらく上記のようにString.Format（）を使用します。ただし、複合メッセージの使用は最小限に抑える必要があると述べなければなりません。それは、ターゲットの文法規則が非常に一般的に異なるためです。そのため、翻訳者は文を並べ替えるだけでなく（プレースホルダとString.Format（）を使用して解決します）、置換されるもの。例を挙げましょう。
// Multiple plural forms
English: 4 viruses found.
Polish: Znaleziono 4 wirusy. **OR** Znaleziono 5 wirusów.
// Conjugation
English: Program encountered incorrect character | Application encountered incorrect character.
Polish: Program napotkał nieznaną literę | Aplikacja napotkała nieznaną literę.
その他の連結の問題
連結は文字列に制限されません。コントロールを一緒にレイアウトすることは避けてください：
[番号付きのテキストボックス]日後にもう一度通知します。
これは次のように再設計する必要があります。この日数でもう一度通知する：[テキストボックス]。
文字エンコードとフォント
Unicode（つまりUTF-8）のテキストは常に保存、転送します。フォントをハードコードしないでください-ローカライズではフォントの変更が必要になる場合があり、デフォルトのフォントフォールバックメカニズムをオフにします（Winformsの場合）。ほとんどのフィールドで「奇妙な」文字（つまりユーザー名）を許可することを忘れないでください。
テスト
おそらく、いわゆる疑似翻訳を実装する必要があります。つまり、たとえばドイツ文化のリソースを作成し、接頭辞と接尾辞を追加して英語の文字列をコピーします。プレースホルダーをラップして、複合文字列を簡単に検出することもできます。擬似翻訳の目的は、ハードコードされた文字列、レイアウトの問題、複合メッセージの過度の使用などのローカライズ可能性の問題を検出することです。