開発者向けの例外メッセージはローカライズする必要がありますか？

Question

私は、開発者が誤ってAPIを使用していることを示す例外メッセージを参照しています。たとえば、メソッドにnullを誤って渡すつまり、開発者が最初に誤ったコードを実行した場合の例外のタイプです。システムのユーザーに表示されるべきではない例外メッセージのタイプ。

これは、プログラミング言語が英語であるため、プログラマーはすでに英語を理解しているという理論に関係しています。少なくとも、例外メッセージを解読するのに十分なものです。

http://www.codinghorror.com/blog/archives/001248.html（ここでは、この理論の無ください議論）

そして、はい、私は、.NET Frameworkは、「ローカライズすべて」アプローチに従っていることを知っています。

Answer 1

あなたの質問は、「すべての開発者が同じエラーメッセージを表示してGoogleに送信できるようにする必要がありますか？」と言い換えることができます。 ;）

その答えは「はい」です。

翻訳は、そのメッセージがもはや意図APIを書いた人は誰でも同じです

• ことを意味しません。それは同じ意味を持つかもしれないし、翻訳で何かを失ったかもしれない。それはひどく翻訳されるかもしれないし、場合によってはそれはまったく読めないかもしれません。
• それを読んだ人は、単にGoogleにエラーを入力して、このエラーが発生したすべての人が何をしたのか見ることはできません。誰もが違う言語で同じエラーを起こすからです。

について.NETの「すべてをローカライズする」アプローチについては、恐ろしいことです。私はそれが無制限に、特にそれがローカライズされたリソースを見つけることができない場合は、あなたが平易な英語のバージョンを提供しないためにトリップしてきた。代わりに、実際のエラー情報を効果的に捨てて、「リソースを見つけることができませんでした」というエラーが表示されます。

Answer 2

これは誰がコードを維持するかによって異なります。開発者が常に英語であれば、英語ですべてを保つことが理にかなっています。

さらに、.NET Frameworkがエラーメッセージをローカライズされた方法でスローするかどうかはわかりません。私はいつもそれらのエラーメッセージは常に英語であると思っていたので、あなたの内部エラーメッセージを英語でも維持するのは意味があります。

Answer 3

いいえ、私はそうではないと思います（少なくとも、私たちはそれをしません。そして、私たちはかなり大きいです:-)。開発者についても心配することなく、ユーザーが見るすべてのものをローカライズするのに十分な努力があります。

外国語のキーワードと標準ライブラリをサポートする主流の言語はないので、英語の基本的なコマンドは既に開発者の前提条件です。

もちろん、開発者が独自のライブラリ（または言語）を開発すると、英語以外の言語をローカライズしたり自由に選ぶことができます。

Answer 4

私たちの会社では、例外/エラーメッセージをコンパイラ/ IDE用に翻訳し、これらの例外/エラーメッセージを翻訳するフレームワークを提供していますが、翻訳は自分では行いません。彼が望むなら翻訳するのは顧客次第です。英語が普及しておらず、自国の言語が促進されている国はいくつかあります。したがって、翻訳されたエラーメッセージを許可することは理にかなっています。

Answer 5

例外メッセージを翻訳する場合は、例外メッセージが出現するすべてのテキストも翻訳する必要があります。これには、知識ベースやバグトラッキングシステムが含まれます。ユーザーやプログラマーは、画面上に表示される例外メッセージを検索する必要があるためです。