.NET における多言語対応

Question

いつもお世話になっております。

.NET において、リソースファイルを用いて多言語対応が可能なところまではわかったのですが、以下の点で悩んでいます。

対象のアプリケーション

以下の２つです。

• WPF によるデスクトップアプリケーション
• ASP.NET Core による Web アプリケーション

前提・実現したいこと

私の勤めている会社では、今後海外に製品を売り出す際は英語版として販売し、英語以外への翻訳は、現地の代理店側で翻訳業者などに依頼して対応してもらうことを想定しているようです。

そのため、英語で書かれたテキストファイルなどを現地の言語に翻訳して、そのテキストファイルを差し替えるだけで対応したいのだそうです。
つまり、英語以外への対応には私の勤めている会社は関与しないという方針です。

しかし、リソースファイルを使用して多言語対応を行ったとき、ビルドを行うと dll 形式でリソースファイルが出力されます。
ということは、リソースファイルを変更した場合は、必ずビルドする必要があると認識しています。
そのため、このままだとテキストファイルを差し替えるだけでの対応は無理なように思っています。

現地で翻訳したテキストファイルをもらい、それをリソースファイルに反映し、ビルドしなおして再配布できればよいのですが、それが不可能だった場合にどうしようかと悩んでいます。
また、リソースファイルは XML 形式のため、これをそのまま渡して翻訳してもらうのも厳しいので、もっとシンプルな形式で渡すよう言われるかもしれません。

しかし、せっかくフレームワークに多言語対応の仕組みがあるので、出来ればそれを使用し、独自実装などは行いたくないと考えています。

知りたいこと

上記を踏まえ、以下のことについてお教えいただければと思います。

• リソースファイルを dll 形式ではなく、テキスト形式で出力する方法はあるか？
• リソースファイルから別のファイルのテキストを参照することはできるか？

（例えば、リソースファイルから INI ファイルを参照するなどができれば、リソースファイルの出力は dll でも INI ファイルを翻訳すれば済むため）

• .NET に限らず、こういう要望に対しては一般的にどのように多言語対応を行うのか？

またはこういう要望は普通はないのか？

###補足情報(言語/FW/ツール等のバージョンなど)

• Visual Studio 2017 Professional
• .NET Framework 4.6.1 (WPF)
• .NET Core 2.0 (ASP.NET Core)
• 言語：C# 7.0

以上、宜しくお願い致します。

Answer 1

.NETの製品ではありませんが、過去にいくつかの製品のローカライズ（翻訳）案件に関わった経験があります。

.NETにおけるリソースファイルの扱いについては先のご回答で既に良い案がご提示されていますので、（私も参考にさせていただきました。ありがとうございます）

.NET に限らず、こういう要望に対しては一般的にどのように多言語対応を行うのか？

またはこういう要望は普通はないのか？

について、回答としてフォローさせてもらおうと思います。

このような要望はありましたが、安易な方法を提案された場合、ローカライズ（翻訳作業）に経費と時間を割きたくないと言う、どちらかと言うとは営業的、会社的（？）な理由が大きかったです。しかし結局は独自の安易な方法は採用されず、開発環境に用意された正規の手段で対応されていきました。

ローカライズは文字列の翻訳のみで終わることはほとんど無く、フォントの種類や大小、翻訳後に文の長さが変わることで画面のレイアウトや表示項目の大きさ、並びを調整することがあります。文字コードや地域別の表記がプログラムの動作に影響が出ることもあります。結局、最後はリソースエディターのような正規のツールを使って見た目と動作を確認しつつ、作業を進めるかたちに落ち着いています。

製品の規模や会社の組織が小さい内はやっつけで終わっていましたが、品質が問題になるとそれ用のローカライズチームが組まれ、技術力を持った翻訳担当者がエンジニア（プログラマー）と協力して、適切なツールを使うようになっていました。外部へ委託するにしても、その外部組織でツールに習熟するよう求めていきます。「ローカライズキット」と銘打って、ローカライズ（翻訳）作業に必要なファイルやツール、手順をまとめて提供するようにしたこともあります。

結局、品質を確保する為にエンジニアの視点が必要になります。製品のリリースでは最終段階でビルドするわけですし。

日本にもソフトウェアのローカライズのノウハウを持つ翻訳会社があります。そう言った会社に相談してみるのもひとつの手かと思います。製品展開の規模にもよるでしょうが、特に最初はエンジニア抜きでローカライズ作業を完了させることは難しいと思います。適切なツールを選択してそれなりに体制を整えていく必要があると考えます。

直接の回答ではなかった（むしろ、外れ気味？）かもしれませんが、参考情報としていただければ。

Comments

[kuttsun]

回答ありがとうございます。
結局私の会社でも画面レイアウトの関係などで、翻訳したファイルをもらってこちらで検証せざるを得ないというような話になっているようです。
ただやはり根底にはそこにコストをかけたくないというのがあるようで、専門のチームを組むとかツールの選定や作成とか翻訳者に技術力を求めるとかいうことには私も含めて意識がなかったので、こういう情報はとても参考になります。

[dodox86]

私のケースでも、最初は会社側よりはむしろエンジニアと翻訳者側の品質へのこだわりで適切なプロセスを導入するようになっていた感があります。会社側は常に「なぜ翻訳にそんなに時間とコストがかかるのだ？！」との意識でした。どちらの考えも理解はできるので難しいですが、品質が悪いとリリース後に結局、エンジニアやサポート部門に負荷がかかるので、注意が必要です。

Answer 2

WPFについて、パット見でよさげな気がするので紹介しておきます。
google先生に聞いて最初の方だったので既にご存知かもしれませんが・・・

多言語対応(C#、WPF編)
XAMLについては、INPUTをexcelとして運用する想定で、Excel⇔XAML部分まで提供されています。

Comments

[kuttsun]

回答ありがとうございます。
私は主に ASP.NET のほうを PG しているので、こちらの情報は知りませんでした。
Excel から変換できるのは確かに良さ気ですね。参考にさせていただきます。

Answer 3

似たような要件で色々試しているのですが、詳しくは書けないのでヒント的に幾つか。
※ただし、WPFのリソースではなく、.NETのリソースでの話です。また、デスクトップアプリケーションです。

リソースファイルを dll 形式ではなく、テキスト形式で出力する方法はあるか？

ResourceManagerから、GetResourceSetをとって列挙すれば良いので、どのような出力形式でも出力は可能です。
なので、txtとかcsvで出力(自力)して、このファイルを元に翻訳してもらいます。
exe自体に出力機能を持たせておくことで、最終のリソースを反映できます。

変更してもらったファイルは exe起動時等に読み込むものとします。
適用方法ですが、リソースDLLとして使用する方法として、リソースファイルのビルドは、al.exe があればできるので、exeの起動時にリソースファイルをビルドする力技も可能ではあります。
.NET環境が入っている場合、al.exeもインストールされていたりするので利用は可能。
ただし、保存先の権限や署名で問題になるかもしれません。

上記リソースDLLは色々と難しいので、ResourceManagerのラッパークラスを作成して、GetStringで返す値を変える対処の方が簡単かもしれません。
内部的にはCulture毎のDictionaryを持つことになります。

.NETの文字列リソースをWPFで使用(バインディング)はResXFileCodeGeneratorで自動生成されるクラスを利用して行っています。

要望的にはありそうなんですけどね。
もっと簡単な方法があれば私も知りたいです。

Comments

[kuttsun]

回答ありがとうございます。
確かにもう少し簡単にやりたいところですが、いろいろ教えていただきとても参考になります。

Answer 4

WPFだけですが、WPF におけるパッケージの URIで素のXMLファイルを指定できます。

個人的には「リソースファイルを書き換えるアプリケーションを代理店に配布する」に一票入れます。

Comments

[kuttsun]

回答ありがとうございます。

> 個人的には「リソースファイルを書き換えるアプリケーションを代理店に配布する」に一票入れます。

確かに言われてみれば、それが一番楽そうではありますね。
その方向で検討してみたいと思います。

[kuttsun]

差し当たり、リソースファイルを編集するツールを提供して、リソースファイルを編集してもらうことになりましたので、こちらをベストアンサーとさせていただきます。