9

ほとんどの人は、既存のアプリを国際化することは、国際化されたアプリをゼロから開発するよりも費用がかかることに同意するでしょう。

それは本当に本当ですか？それとも、国際化されたアプリをゼロから作成する場合、I18N を実行するためのコストは、複数の小さな割り当てで償却されるだけで、誰も国際化タスクの重荷を背負っているとは感じていませんか?

成熟したアプリには、プロジェクトの歴史の中で削除された多くの LOC があり、国際化が後から考えられた場合は I18Ned である必要はなく、プロジェクトが国際化されていた場合は I18N であったと主張することさえできます。最初から。

では、今日開始するプロジェクトは国際化する必要があると思いますか、それとも、ソフトウェアが享受する成功 (または失敗) と需要の地理的分布に基づいて、その決定を将来に延ばすことができると思いますか?

Unicode データを操作する機能について話しているのではありません。ほとんどの主流言語、データベース、ライブラリで無料で利用できます。私は、具体的には、独自のソフトウェアのユーザー インターフェイスを複数の言語とロケールでサポートすることについて話しているのです。

4

10 に答える 10

14

「国際化されたアプリをゼロから作成する場合、I18N を行うコストは ... 償却されます」

しかし、それだけではありません。

ユーザーへのすべてのメッセージをさかのぼって追跡することは、場合によっては不可能です。

難しくない。不可能。

このことを考慮。

theMessage = "Some initial part" + some_function() + "some following part";

このような状況をすべて見つけるのは大変なことです。結局のところ、some_function文字列を返すだけです。それがデータベース キー (人に表示されることはありません) なのか、翻訳する必要があるメッセージなのかはわかりません。そして、それが翻訳されると、文法規則によって、3 つの部分からなる文字列の連結がばかげた考えであることが明らかになるかもしれません。

翻訳する必要がある可能性のある I18N メッセージが含まれているとして、すべての文字列値関数を単純に GREP することはできません。実際にコードを読んで、場合によっては関数を書き直す必要があります。

明らかに、some_function少しでも複雑な場合は、アプリケーションの一部がまだスウェーデン語であるのに、残りの部分が他の言語に正常に I18N 化されていることに困惑します。(特にスウェーデン人を選ぶのではなく、これを最終展開とは異なる開発に使用される任意の言語に置き換えてください。)

さらに悪いことに、C や C++ で作業している場合は、プリプロセッサ マクロと適切な C 言語構文との間でいくつかの分割が行われる可能性があります。

また、コードをオンザフライで構築できる動的言語では、すべてのコードを明確に識別できない設計によって身動きが取れなくなるでしょう。動的にコードを生成するのは悪い考えですが、さかのぼって I18N ジョブを実行することもできなくなります。

于 2010-02-25T12:46:32.227 に答える
5

新しいアプリケーションをゼロから作成するよりも、既存のアプリケーションに追加する方がコストがかかるという点には同意できません。

  • 多くの場合、アプリケーションが「大きく」なるまで、i18n は必要ありません。規模が大きくなれば、i18​​n に専念する開発チームが増える可能性が高くなるため、負担が軽減されます。
  • 実際には必要ないかもしれません。多くの小さなチームは、国際化を必要とする顧客がいないときに、国際化をサポートするために多大な努力を払っています。
  • 国際化すると、増分変更に時間がかかります。それほど時間はかかりませんが、製品に文字列を追加する必要があるたびに、最初にバンドルに追加してから参照を追加する必要があります。いいえ、大した作業ではありませんが、努力が必要で、少し時間がかかります。

私は「その橋に来たら渡って」、それを探している有料の顧客がいる場合にのみ国際化することを好みます。

于 2010-02-25T12:56:13.333 に答える
1

はい、既存のアプリを国際化することは、アプリを最初から国際化して開発するよりも間違いなく費用がかかります。そして、それは決して些細なことではありません。

例えば

Message = "Do you want to load the " & fileType() & " file?"

多くの言語には性別の合意などの文法規則があるため、コードを変更しないと国際化できません。可能なすべてのファイル タイプをロードするために、異なるメッセージ文字列が必要になることがよくあります。これは、部分文字列を結合できる英語とは異なります。

このような他の多くの問題があります: 同じ概念を表現するために英語よりも多くの文字が必要な言語があるため、より多くの UI スペースが必要です。東アジアではより大きなフォントが必要です。ユーザー インターフェイスでローカライズされた日付/時刻を使用する必要がありますが、おそらく英語です。 US データベースと通信するときは、CSV ファイルの区切りとしてセミコロンを使用する必要があります。文字列の比較と並べ替えは文化、電話番号と住所...

では、今日開始するプロジェクトは国際化する必要があると思いますか?それとも、ソフトウェアが享受する成功 (または失敗) と需要の地理的分布に基づいて、その決定を将来に延期することができますか?

場合によります。特定のプロジェクトが国際化される可能性はどのくらいありますか? 最初のバージョンを迅速に入手することはどれほど重要ですか?

于 2010-02-25T13:13:15.540 に答える
0

それはあなたのプロジェクトとあなたのチームがどのように組織されているかに依存します。

私はウェブサイトの国際化に携わってきましたが、1年間フルタイムで1人の開発者であり、必要に応じてインストールの影響（ファイルの再編成など）を処理するためにパートタイムで約6〜8か月かかりました。開発者は、プロジェクトで大幅なリファクタリングが必要になったときに時々関与します。これは、v3にあったアプリケーションにありました。

だからそれは間違いなく高価です。あなたが尋ねなければならないのは、最初からローカリゼーションシステムを提供するのにどれくらいの費用がかかるか、そしてそれが初期段階でプロジェクトにどのように影響するかということです。v1でのプロジェクトは、急いで設計された国際化フレームワークの問題によって引き起こされる遅延や後退に耐えられない可能性がありますが、幅広い顧客ベースを持つ安定したv3プロジェクトには、それを適切に行うための投資が必要になる場合があります。

また、ログメッセージを含むすべてを国際化するか、UI文字列だけを国際化するか、それらのUI文字列がいくつあるか、ローカリゼーションとそれに伴うQAを実行できるユーザー、さらにはどの言語かによっても異なります。サポートしたい-たとえば、システムはユニコード文字列をサポートする必要がありますか（これはアジア言語の要件です）。

于 2010-02-25T13:40:22.193 に答える
0

何が高価かは言えませんが、クリーンな API を使用すると、非常に低コストでアプリケーションを国際化できると言えます。

于 2010-02-25T12:57:14.707 に答える
0

「Unicode の処理」が「無料」で手に入ると本気で思っているなら、試してみると意外なことが起こるかもしれません。

ANSI または非常に類似した文字セットを使用する言語を超えた i18n 機能が証明されているフレームワークを使用しない限り、いくつかの問題や、Unicode の処理が正しくない、または単に利用できないというより重大な問題が発生します。比較的一般的な言語 (ドイツ語など) でも、Unicode をサポートしていない API や文字数を縮小または拡大することは困難です。

次に、読み順が異なる言語について考えてみましょう。

これは、最初から実際に計画を立て、サポートする予定の言語セットで破壊するまでテストする必要がある理由の 1 つです。

于 2010-02-25T13:01:22.760 に答える
0

また、国際化されたデータをサポートするようにデータベースのバックエンドを変更すると、コストがかかる可能性があることも忘れないでください。すでに 20,000,000 件のレコードがある場合は、その varchar フィールドを nvarchar に変更してみてください。

于 2010-02-25T18:40:22.347 に答える
0

i18n と l10n の概念は、単に文字列をいくつかの言語との間で翻訳するだけではなく、より広範です。

例: ユーザーによる日付と時刻の入力を考えてみましょう。設計時に国際化を考慮していない場合

a) ユーザーのためのインターフェースと

b) 保存、検索、および表示のメカニズム

他の入力スキームを有効にしたいときは、本当に悪い時間になります。

ほとんどの場合、最初から i18n は必要ありません。しかし、それが私の言いたいことです。i18n のために触れなければならないいくつかの領域について考えなければ、元のコードの大部分を書き直すことになるでしょう。そして、i18n を追加することは、事前に検討するよりもはるかにコストがかかります。

于 2010-02-25T13:06:29.773 に答える
0

大きな問題になりそうなことの 1 つは、さまざまな言語でメッセージの文字数が異なることです。iPhone アプリ、特に小さな画面で 10 文字のメッセージの UI を設計し、後で国際化しようとして同じものを表示するには 20 文字が必要であることがわかった場合、UI をやり直す必要があります。収容する。デスクトップ アプリであっても、これは大きな PITA になる可能性があります。

于 2010-02-25T13:09:50.243 に答える
0

言語によると思います。すべての j2ee(Java Web) アプリは i18n です。これは非常に簡単なためです (IDE でさえも文字列を抽出でき、名前を付けるだけです)。

j2ee では、後で追加する方が安価ですが、できるだけ早く追加するのが文化です。j2ee は多くのオープンソースを使用しており、ほとんどすべてのオープンソース ライブラリが i18n であるためだと思います。彼らにとっては素晴らしいアイデアですが、ほとんどの j2ee アプリにとってはそうではありません。ほとんどのエンタープライズ アプリは、1 つの言語を話す 1 つの企業向けのものです。

さらに、悪いテスターがあまりにも早くそれを入れた場合、彼らはラベルと翻訳に関するバグレポートを提供します(開発者によって行われた翻訳ではないのを一度だけ見ました)。テスターがそれを完了した後、優れた i18n サポートを備えたバグのあるアプリが作成されます。ただし、ユーザーが言語を切り替えて、それを使用できるかどうかを確認するのは楽しいかもしれません. しかし、あなたのアプリを使うのは彼らにとって退屈な仕事でしかないので、彼らはそれさえしません。i18n の唯一のユーザーはテスターです。

ある日誰かがそれを i18n にしたいかもしれないことを知っているので、奇妙な文字列結合は j2ee 文化にはありません。唯一の問題は、html テンプレートからラベルを抽出することです。

于 2010-02-25T19:23:50.310 に答える