ローカライズを念頭に置いて開発していますか？

ソフトウェアプロジェクトまたはWebサイトで作業する場合、ローカライズを念頭に置いて開発しますか？

これにより、例えば

• エラーメッセージを含むすべての文字列を外部化します。
• テキストを含む画像を使用していません。
• テキスト拡張を念頭に置いてUIを設計します。
• 擬似翻訳を使用して、プロセスの早い段階でUIをテストします。
• 等

あなたが取り組んでいるプロジェクトでは、これらは「いい」カテゴリにあり、ローカリゼーションチームに残りのことを心配させますか、または開発プロセスにローカライズの準備が組み込まれていますか？開発者が一般的にローカライズをどのように見ているかを聞きたいです。

私はフォーチュン500の大企業で働いており、常にローカライズを念頭に置いています。通常、私たちのプロジェクトは米国のみを対象にしていますが、長年にわたって何度もクライアントのためにアプリを作成し、他の誰かがそれを見て「やあ、国Xにぴったりだ」と言うでしょう。次に知っていることは、ローカライズを追加するコードを実行しているということです。最初からそれを使ってアプリを構築するのにこれ以上の時間はかかりません。さらに、クライアントが私たちのところに来て、アプリを使用する（言語を選択する）ように依頼すると、ファイルを渡して、翻訳してもらう（言語を選択する）ように指示し、完了です。 。

それは10年前に重要だったと思います。最近の技術は問題を解決しました。

私は3つの国語がある国に住んでいますが、そのうちの1つだけが少数民族です。

そのために発生する可能性のある問題を理解するためには、米国の西部が東部とは（非常に）異なる言語を話すようなものです。国の中心部では人口がいくらか統合されているため、どこでも両方の言語を使用する必要があると考えてください。

デスクトップアプリケーションとWebサイトで4つの言語を使用することは、現在でも非常に一般的です（3つの各国語+英語）。それは時々義務です。

私は自分の環境によって条件付けられてきたので、ローカライズを意識していました。はい、数年前、私はそれを心配していました。

現在、最新のIDEツールを使用すると、静的アプリケーションを完全にローカライズされたアプリケーションに非常に簡単に変換できるため、ローカライズについてはあまり気にしません。

Visual Studio .NETで使用するツール：

• CodeRushは、ハードコーディングされたテキストをリソースファイルに移動できるVisual Studioプラグインです。
• Easy Localizerを使用して、すべての追加言語を追加したExcelファイルのラベルを抽出し、リソースファイルにマージします。

私のクライアントのほとんどは1つの言語のみを必要とし、実際にはその1つの言語を指定しています。したがって、アプリケーションのローカライズに時間を費やすことはありません。ただし、他の言語を完全に無視できるわけではありません。そのため、基本を守ります。

• どこでもUnicodeを使用します。それは2k10です、言い訳はありません。
• 設計、いくつかのレイアウトで弾力性。すべての英語でさえ、同じポイントサイズで異なるフォントは非常に異なるスクリーンフットプリントを持ちます。
• ビュー層からアプリケーション関数/データモデリングを排除する

個人的には、潜在的なローカリゼーション言語が、アプリケーションが設計された言語と根本的に異なる場合、単純なテキストの選択よりも多くのことが行われます。テキスト置換は、比較的早い段階で会社が新しい場所で「迅速かつ汚い」実装を実現するのに役立ちますが、他の言語のユーザーの考え方の根本的な違いは解決しません。

私は日本語を勉強しましたが、私は自分がその言語の初心者であるとしか考えられませんが、直接翻訳されていない概念があることを十分に知っています。何かを使用可能にするものについては、さまざまなアイデアがあります。大きな主要な概念は似ているかもしれませんが、それは実際にユーザーに違いをもたらす詳細です。

非常に異なる文化のニーズに真に対応するには、アプリケーションにまったく新しい顔が必要です。そのため、モデル/ビュー/コントローラーの分離がさらに重要になります。アプリケーションが同じように機能する限り、ビュー部分は完全に置き換えることができます。それが起こるとき、誰かが問題に適切に取り組むためにいくらかの本当のお金を払うことを計画しています。

私たちは必要に応じてそれをやりました：市場を拡大したため、顧客向けのものはすべてi18nを念頭に置いて行われ、一部の内部のものは現在i18nに対応しているため、それを使用する従業員は英語を話す必要がありません。

そこで、必要に応じて、スタートアップとしてそれを行いました。

人々はローカライズの努力をかなり軽くしているようです。特に、元の言語として英語を使用する場合、他の言語では通常30〜40％のテキスト用のスペースが必要であるという事実を無視するのは簡単です。このため、翻訳者は理解しにくい略語を使用する必要がありますが、これはもちろんユーザーエクスペリエンスにとって悪いことです。

通常、最初から国際化が必要であることを知っていたとしても、後で必要になったときに国際化を追加します。私が使用している言語では、別の段階でそれを行うことはひどく違いはありません。また、初期の建設段階から面倒な一面を排除することができます。

私はアンドロイドアプリケーションを作成し、ローカライズはJavaスタイルの文字列ファイルを使用して非常に簡単です。すべてのAndroid言語で完全に国際化するための労力はほとんどありません。

回答：はい。私が作業している環境（Python / Zope / Plone）では、後で文字列をローカライズするのは非常に簡単です。したがって、最初から要件でない場合はスキップします。

ただし、テキストはUnicodeオブジェクトなどに保存します。

あ、はい。私のアプリケーションはローカライズが合理的に容易であることを確認し、ローカライズされていなくても国際的な環境で動作します。必要な労力が小さく、利益が大きいため、そうしないことは間違いです。