internationalization - コード「国際化」

Question

私はさまざまな国でさまざまなプロジェクトに取り組んでおり、次のようにコードが国際化されることがあると述べました。

LargeurEtHauteur () (SetWidthAndHeight、frの場合) Dim _ListaDeObiecte as List(Of Object) (_ObjectList、roの場合) internal void Sohranenie User ov () (SaveUsers、ruの場合) など。

ラテン文字を使用している国では、文字変換の必要がないため、この混合がより顕著になることがあります。

それ以上に、多くの場合、プログラミングの「専門用語」はプロジェクト仕様言語に触発されています。「プロジェクト言語」の用語は、英語で「翻訳可能」でない意味を持つ場合があります。

フランスのチームのように、フランス語の単語を使用するだけのプロジェクトもあります (たとえば、Personne、Vehicule、Projet など)。

その場合、すべてのビジネスオブジェクト名を説明する「辞書」を仕様に個人的に追加し、これらのオブジェクトのみが他の (フランス語) 言語で使用されます。

言う：

Collectif - ensemble des Personnes ;

すべてのアクション (Get、Set、Update、Modify、Load など) は英語です。

「強い」名前をコードで使用できるようになったので、 Add Personne To Collectif。

「国際化」へのあなたのアプローチは何ですか？

_{PS。

「btnAdd É l è ve」または「кпкСтоп」という名前のボタンを使用して、VisualStudio が .NET でプロジェクトをコンパイルおよび実行することに面白がっていました...}

score 14 · Accepted Answer

私の個人的なアプローチは、プログラミングコミュニティのすべてではありませんが多くの人に共有されているもので、ソースコードは英語であるべきであり、可能であればすべての開発ツールも英語であるべきだというものです。

これの最も重要な理由は、クラス名、エラーメッセージ、パス、およびその他のアーティファクトを毎回翻訳する必要なく、問題と解決策を世界と共有できることです (現在 StackOverflow で行っているように)。

また、ほとんどのライブラリは英語で記述されており、2 つの言語が混在する要素名を使用しても実際には誰の役にも立たないため、一貫性にも役立ちます。また、Addのような動詞が常に翻訳されるとは限らない場合、常に内部競合が発生します。

また、英語のコードを使用すると、理解や誤解を心配することなく、外国人をプロジェクトに簡単に追加できます (特に、スペイン語やポルトガル語など、多くの誤った同族語がある密接に関連する言語間)。

この件に関する良いリンク: http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

（誰かが不思議に思うかもしれませんが、私は南アメリカ人で、英語は私の第一言語ではありません）

score 5 · Accepted Answer

チームの全員が英語を上手に話せる場合でも (これは当然のことではありません)、すべてのビジネス用語に相当する英語を必ずしも知っているとは限りません。

何を許可するかはプロジェクト固有の決定だと思いますが、私は一般的に許容し、場合によってはローカル言語でのビジネス用語 (エンティティ名など) を推奨しますが、技術用語 (つまり、幅/高さの代わりに大/高さではありません) は推奨しません。 .

たとえば、フランスの金融業界では、OPCVM と FCP の意味を誰もが知っています。英語に翻訳しようとすると、混合言語を許可するよりも多くの誤解を招く可能性があります。

score 2 · Accepted Answer

いつか国際的に使用される可能性のあるコードを書いている場合は、英語で書いてください。疑わしい場合は、英語で書いてください。できればコメントも含めてください (ただし、職場の言語でいくつかのコメントを追加できると思います)。

残念ながら、コーディングに固有のものではありません。英語は私の母国語ではありませんが、多くの技術論文を読んだり、世界中の人々と国際会議に参加したりできました。これらのコラボレーションは、全員がそれぞれの母国語で出版した場合には機能しません。

自分の言葉を何としてでも守りたいと思うのは悲しいことかもしれませんが、現実的にならなければなりません。英語には、基本的なレベルを達成するために比較的単純であるという利点があると思います。名前に性別、活用、格がありません。

score 2 · Accepted Answer

私は現在、ノルウェー語で同じ問題を抱えています。プロジェクトでのあなたの立場、利用可能な時間、およびソフトウェアの役割に依存すると思います。

私の場合、ノルウェー語で作業している既存のプロトコルとライブラリにすべての用語を保持することにしました。これは、何世代にもわたる管理者がこれらに慣れていることを合理的に期待できるためであり、ライブラリはプロトコルに依存しているためです。国際プロジェクトのライブラリラッパーで、各メソッド名を文字通りに翻訳し、メソッドの英語のドキュメントを追加しました。

コードに関するコメントとドキュメントは英語です。

ソフトウェアをゼロから設計する場合、「移植性」を維持するために、すべてのメソッド名とビジネス用語について英語の用語を見つけようとします (合理的であれば. 用語が見つからない例はほとんど思いつきません.)。

score 2 · Accepted Answer

一般に、言語の概念を参照するコードは、プログラミング言語と同じ母国語にする必要があります (つまり、英語 - for、while、文字列はすべて英語の単語です)。

ローカル言語で変数とドメインの概念を使用することは問題ありませんが (ただし、素晴らしいことではありません)、List、Object、Decimal などを、プログラマーが 2 つの言語を調整するために多くの作業を必要とする用語に翻訳したくないことは間違いありません。それでも、コレクション、メンバーシップ、人、ユーザーなどの非常に一般的なドメイン概念と、可能であれば請求書、領収書などのあまり一般的ではないドメイン概念を英語に制限するよう強く働きかけます。

クラスの半分を VB でコーディングし、半分を C# でコーディングするようなものです。つまり、脳が認知シフトを行わなければなりません。これはハイブリッドアプリ (Web 上の JavaScript とバックエンドの C#) には適していますが、実行中の内容を明確に保つのに役立つため、一般的なプログラミングには適していません。

さらに、すべてに英語を使用すると、ドメインと言語の単語がうまく連携します。

例外は常にあります。いずれにせよ、固有の単語を使用する場合があります。その単語がドメインを最もよく表している場合です。たとえば、私たちの (英語) コードベースでは、メキシコでソフトウェアを実行している人々にのみ関連する特定の概念について、メキシコスペイン語の用語を参照していました。通常、日本語の用語は音声/ローマ字で綴られていましたが、外国人がピクトグラムを発音するのは困難でした;-)。

score 1 · Accepted Answer

良い設計ガイドラインは、英語の名前と英語のコメントのみを使用してコードを書くことだと思います（もちろん、あなたのチームがこれを行うことができる場合、しかし国際的なチームの場合、英語は最も人気があるので自然に選択するようです言語、特にITの世界で）。

このようなガイドラインの良い説明は、ほとんどのプログラミング言語のキーワードは英語から取られているため、英語の名前を使用してコードを書くと、より一貫した外観が得られ、これにより、読みやすいコードで終わるということです。

もう1つの理由は、ほとんどのコンパイラがクラスやメソッドなどの名前としてASCII文字しか処理できないため、ASCII以外の文字を含むアルファベットを使用する言語を使用する場合、おそらく奇妙な名前で終わる可能性があります。

私の頭に浮かんだ3番目の理由は、SOのようなサイトでコードを共有することです。今日、私はクラスがスペイン語の名前を持っているコードの一部で投稿を開きました。このクラスの目的が何であるかを推測するのは困難でした（必要でない場合でも、コードを読んで使用されているすべての単語を理解するとよいでしょう:)）。

要約すると、コードの国際化は良い考えではないと思います。プログラミング言語のキーワード（たとえば、class、try、while）もローカライズできると想像できます。おそらく、そのときの生活がどれほど困難になるかも想像できます...

score 1 · Accepted Answer

私はそのようなコードベースを「国際化」ではなく「ひどい」と呼びたいと思います。英語で行います。

score 0 · Accepted Answer

一貫性を保つために、コードを (プログラミング) 言語と同じ (人間の) 言語にします。つまり、プログラミング言語が英語のキーワード ( for、switch、publicなど) を使用している場合、残りのコードは英語のままにします。キーワードのスワヒリ語翻訳を (たとえば) 認識するコンパイラを使用している場合は、残りのコードをスワヒリ語のままにしてください。

多くの API には、(人間の) 言語に関係なく従う標準化された命名スキームがあり、付随するドキュメントは (ソースコードの代わりに) 必要に応じて翻訳されます。

どの (人間の) 言語を選択する場合でも、1 つを選択してそれに固執してください。私は、ドイツ語と英語が混在したコードよりも、ドイツ語のソースコードを調べたいと思っています。

internationalization - コード「国際化」

8 に答える 8

Related

Reference