番号のローカリゼーションは不要ではありませんか？

このページを読んだばかりですhttp://weblogs.asp.net/scottgu/archive/2010/06/10/jquery-globalization-plugin-from-microsoft.aspx

彼らがしたことの1つは、アラビア語の日付をアラビア語のカレンダーに変換することでした。そうするのは良い考えかどうか疑問に思っています。（ユーザーがアラビア語であっても）ユーザーにとって実際に迷惑/混乱するでしょうか。

また、2番目の質問は、ドイツ語などの一部の文化では33,899.99を33.899,99に変更する必要があるのか​​ということです。ライブラリがすでにそれを行っているので、そうすることは害になりませんが、これは実際にユーザーにもっと混乱を引き起こさないでしょう（たとえ彼がドイツ人であっても）。

私はこれらの人々がどのような文化から来たにせよ、33,899.99の数字を与えたとしても、あなたが間違ったことをする方法はないでしょうか？（私のウェブサイト/アプリケーションがあなたがあなたの人生でこれまでに使った最初のウェブサイト/アプリケーションでない限り、おそらくそれは可能ですが、確率はそれだけです）

私は、誰もがそれが何を意味するのかを見て、知っているフォーマットとして「ユニバーサル」を意味しました。白黒などで書かれた標準である必要はありません。誰もがそれを読んで、テキストが何を表しているのか混乱せずにすぐに知ることができる限り、それは普遍的です。確かに、1.234,00は間違いなく普遍的ではありません。私は、あなたが一生ずっと、コンピューターを使っていて、この数字形式にまったく出会ったことがない人を見つけることができると確信しています。ほとんどのWebサイト/アプリは、ローカライズに対応するために変更なしで1,234.00を使用していたため、事実上の（すべての人がそれを見て理解できる普遍的な形式）と考えています。

日付に関しては、01/02/03を書くと、誰がそれを知るか（一義的で、すぐに、あいまいさなしに）日付が何であるかはわかりません。しかし、2003年1月2日、2003年2月1日、2001年2月3日など、私たちがそれらを書いたとしても、だれもが間違っていることはないでしょうか？

この質問はローカライズを対象としていますが、「誰もが英語を読めるとは限りません！」それは国際化の問題だからです（このトピックを超えています）。ローカリゼーションに関する議論に固執しましょう。

なぜAnglosでは読めないのに、Anglos以外は日付や数字などをデコードする必要があるのでしょうか？ユーザーや顧客として、Anglos以外のユーザーに歓迎を感じてもらいたい場合は、数値と日付のローカリゼーションが絶対に必要です。ドイツ語のユーザーが、自分の言語の形式で番号を取得するのではなく、自分の番号を解決する必要があるのはなぜですか？

さらに、数値形式（および日付：以下のqv）のビューは、絶望的に単純化されています。たとえば、1,234,567の「自然」、「明白」、「論理」などの数字を見つけることは間違いありませんが、無数の番号付けスキームを持つ文化から来た人はどうでしょうか。たとえば、私の生徒（中国人）は、数字のグループ化が異なるため、常に1000を超える数字について混乱しています。彼らの思考プロセス（千点以上の無数のものを含む）のためのより「自然な」グループ化は123,4567です。さらに、一般にヨーロッパの数値システムが単に適さない多くのコンテキストがあります。そのような状況では、ここで一般的に使用されているすべての中国語一百二十三万四千五百六十七、さらにはさまざまなハイブリッドシステムを作成できると便利です。

日付のアイデアも間違っています。01/02/03の曖昧さ（アメリカ人が日付の基準への準拠を拒否しているという理由だけで）を正しく指摘し、代わりに2001年2月3日が明確であることを提案しました。ただし、そこに何か気づいたかどうかはわかりません。それは曖昧でなく曖昧さのない英語です。生徒たちに話を戻しますと、2001年2月3日（または二〇〇一年二月三日）を見るのがはるかに好まれることは確かに間違いありません。デコードすることなく読むことができます。

i18nとl10nの要点：お金やユーザーが必要ですか？ユーザーが望むものを作ります。ユーザーはあなたのものではなく、自分の言語で物事を望んでいます。話の終わり。

追加するように編集

無数のシステムよりもさらに悪化します。この素敵な進歩のためのインドの番号付けを見てください：

1
10
100
1000
10,000
1,00,000
10,00,000
1,00,00,000

...など：

100,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,000

最後に3でグループ化するのがわかりますか？3でグループ化した後、2でグループ化するのがわかりますか？再び3人のグループの突然の再導入を見てください。

さらに編集して追加します（このテーマを避けられないようです！）

10進数システムが普遍的であるという仮定でさえ間違っています。4ベース、5ベース、8ベース（8進数）、10ベース（10進数）、12ベース、20ベース、さらには60ベースのネイティブナンバリングシステムがあります。これらはすべて、実在の人々によってアクティブに使用されているシステムです（SFストーリーで構成されていない場合など）。これらのすべてがまだ生きているわけではありません（たとえば、英語の用語で12、60ベースの数値システムの痕跡を見ることができますが）。

日付に関しては、世界の多くでまだ活発に使用されている太陰暦を忘れないでください。イスラム教徒の世界では、1年を通して日付が変動する旧暦を使用する傾向がありますが、中国人は、日付を1か月以内に収める複雑なシステムを使用します。（そして、それは私の頭の上の2つの名前を付けただけです。）

また、私の2番目の質問は、ドイツ語などの一部の文化では3,899.99から3.899,99に変更する必要があるということです。ライブラリは既に私たちのためにそれを行っているので、そうすることは害になりませんが、これは実際にはユーザーにもっと混乱を引き起こさないでしょう（たとえ彼がドイツ人であっても）。

ユーザーがドイツ語であっても、ドイツ語の表記と混同されるでしょうか？私はそれに同意しないと確信しています。いいえ、ユーザーにとってより混乱を招くのは、ローカライズされたサイトにローカライズされていないデータが集中していることです。この点で、数字と日付は重要な問題です。

サービスをローカライズする場合は、適切にローカライズする必要があります。数値形式のスキッピングは怠zyで無知です。

3,899.99は普遍的な形式ではありません。「誰でも理解できる」という仮定は知的に怠theです。また、比較的失礼です。私たちはあなたが投稿した特定のリンクについて議論しているので、あなたにはできる機能があります。

アメリカ<>ユニバーサル。

「Jan 2 2003」のような日付を読み取るには、デコードに時間がかかります。私たちは常に月の前日を置きます。したがって、「2003年1月2日」でなければなりません。確かにそれを取得しますが、デコードするには5秒を考えなければなりません。

1,234のような数値を表示すると、ほとんどのヨーロッパ人は10進数を考えます。1,345.00は「気分が悪い」だけです。

アプリをローカライズしなくても問題ありません。あなたの国以外でヒットすることを期待しないでください。

ここでのあなたの問題は悪い仮定のようです。数値または日付に「ユニバーサルフォーマット」はありません。3,899.99は一部の場所で有効であり、他の場所では混乱を招きます。逆も同様です。人々は必要なものを頻繁に把握できますが、それはポイントではありません。同じことは、あなたが話している日付形式についても言えます。形式自体はロケール間で異なります。ここには「ユニバーサル」はありません。

一般的なソフトウェアが通常対処しない特定の科学的および技術的領域を除いて、これらのいずれにも普遍的な形式はありません。あなたのソフトウェアがあなた自身の場所以外のどこでもネイティブの用語で受け入れられることを望むなら、あなたはそれのために働く必要があるでしょう。

事実上の標準が人々の喉を下ろすという概念を突き出すことができますか？確かに。しかし、プロの国際化ソフトウェアでは、数字のローカリゼーション（質問ごと）は不要とは見なされません。

あなたはあなたが読むのに慣れているものが普遍的であると仮定しているようですが、そうではありません。

私が住んでいる場所では、コンマは小数点区切り記号を示し、ドットは千桁区切り記号として（わずかに）使用されます。3,004.25ドルを解析するのは不自然です。しかし、もしあなたが5,535ドルを私に与えたなら、私はおそらくそれを約5ドル半と読むでしょう。3.899,99を読んでも混乱することはありません。なぜそう思うのかわかりません。

日付については、2001年2月3日と2001年2月3日を読むことができます。

そのため、ユーザーは通常、us-enにローカライズされたほとんどの数値と日付を解析できます。$ 5,535のように、あいまいさが生じる場合があります。いずれにせよ、自分のロケールよりも明確であると思われる理由がわかりません。

数字と通貨のローカライズに関する知識はあまりありませんが、日付はISO 8601（http://en.wikipedia.org/wiki/ISO_8601）の形式でYYYY-MM-DDの形式で扱われます（例：2011-05-10） 5月10日。

また、私の2番目の質問は、ドイツ語などの一部の文化では3,899.99から3.899,99に変更する必要があるということです。ライブラリは既に私たちのためにそれを行っているので、そうすることは害になりませんが、これは実際にはユーザーにもっと混乱を引き起こさないでしょう（たとえ彼がドイツ人であっても）。

私はドイツ人です。個人的に話すと、本当に紛らわしいです。なぜなら、私は非常に多くの英語のテキストを読み、ドイツ語のテキストよりも、すべてを混ぜ合わせて読んだからです。そのため、出会う各数字を少し休憩して、それがどの表記規則に準拠しているか、実際にどの程度の意味があるかを把握する必要があります。

したがって、ローカライズ設定では、スイスで使用されているシステムである1'234.00のように、数字のグループ化文字を一重引用符（ '）に設定しました。

私はこれらの人々がどのような文化から来たにせよ、3,899.99の数字を与えたとしても、あなたが間違ったことをする方法はないでしょうか？（とにかく、彼はおそらく普遍的なフォーマットを学んでいたので）

おそらくそれを理解することはできますが、少し時間がかかります。

私は、誰もがそれが何を意味するのかを見て、知っているフォーマットとして「ユニバーサル」を意味しました。確かに1.234,00は間違いなく普遍的ではありません。私はあなたが人生でこの数字のフォーマットを見たことがない人を見つけることができると確信しています。ほとんどのアプリはローカライズなしで1,234.00を使用していたので、それがデファクト（誰もがそれが何を意味し、誰もが知っている一般的な形式）であると信じていました。

ここドイツでは、1,234.00表記を見たことがない人がたくさんいます。

また、この問題には法的な意味合いがあります。間違った小数点で書かれた銀行口座の残高を想像してください。それからあらゆる種類のトラブルが発生する可能性があります。

日付に関しては、01/02/03を書くと、だれもそれが日付を知る方法がないと確信しています。

うん、嫌いだ！そして、多くの人々がまだそうしているので、イギリスとアメリカの表記法の間に矛盾があり、1人が月の前日を、もう1人がその日の前月を書いているように。

ローカライズが不可能な場合（書かれたテキストのように）、国境を越える可能性のあるものについては、標準化された形式2003-02-01をお勧めします。すぐに見ることはできませんが、2月1日または1月2日が意図されている場合、この表記法は標準化され、より重い数字が最初に（月の前に）表示されます。

あなたが望むものを達成する方法がありますが、それらはすべて誰にも自然なフォーマットを使用することを伴います。たとえば、タイムスタンプを人間が読める形式で製品に保存します：YYYYMMDDHHMMSS。混乱はありませんが、日常生活でその形式を使用している人はいません。

必要なのは、1970年1月1日から数秒など、普遍的な基本形式です。それがあれば、任意の形式で時刻を表示でき、ライブラリとOSは正しい時刻を再表示できます好きなように。

私が推測する答えよりもコメントですが、...

自然に来ない

「とにかく、彼はおそらく普遍的なフォーマットを学んでいたので」

恩赦私、それがことだので、私は本当に、かなり遅れて学校にまで、その「ユニバーサル」形式を「学習」しませんでした：誰心配。または少なくとも、必要になるまで（たとえば、公式文書、ビジネスなど）。そのため、あなたの文化の慣習を使用しないフォーマットを見ると混乱します。いつものMM/DD/YYYYかDD/MM/YYYY、おそらく同様に大きな問題です。

学習は特権です

また、残念なことに、多くの人々はそれらのことを「学ぶ」機会を得られません。先進国であっても、すべてのバディが学校（小学校でも）に通ったり終わらせたりするわけではありません。そして、私はこれを十分に強調することはできませんが、彼らのためにソフトウェアを設計しています。

Googleのやり方をご覧ください。彼らはどうやら、言語関連製品の社内での作業に真剣に取り組んでいるようです。また、この理由からローカライズされたサービスを提供するために最善を尽くしています。

ここの多くのプログラマーは、通常、「共通」言語（英語、およびASCIIでエンコードされた、かなりお願いします）を好みますが、多くの人々は、自分の言語で迎えられると、より歓迎されます。誰もあなたの言語を話せず、文章があなたの言語から非常に離れている外国の空港でゲートから降りるようなものです。あなたがそれに慣れていないなら、それは少し怖いことがあります。そして正直に言って、それをITの世界に持ち帰るには、ユニコード文字や他の言語の単語の音声学的に近似したバージョンを含むソースファイルを開くことでさえ、非常に苦痛です。

しかし、システム設計者の意図が何であり、どのフォーマットを目指しているのかを毎回疑問に思うことになります。しかし、他のことを理解できない人にとっては、そうなると混乱することはほとんどありません。

文化の問題

最後に、この問題の核心には別のことがあると思います。もしあなたの提案に従えば、他にもたくさんの偉大な文化を共食いし、それらはすべて存在するに値し、記憶され、称賛されるでしょう。そして、彼らは自分たちの著作とこれらの小さな-一見無関係に見える-詳細も生きています。それらは文化の一部であり、それぞれの文化には理由があります。

私はこれを、悪意のある大西洋帝国の拡大に関する奇跡にしたくはありませんが、それは人々の厳しい反応とコメントを引き起こすようなものです。単にあなたが他の人の意見、好み、文化を捨てたいと思うように見えるからです（あなたはそうは思わないでしょう）。または、いずれにしても、あなたは彼らのやり方にほとんど敬意を払わず、それらをあなたのユーザーベースの一部とは思わず、彼らを歓迎する努力をしたくなく、一般的に彼らをあまり気にしない。

編集-個人的な逸話：イギリス/オーストラリアのスペルではなくアメリカのスペルで「謝罪」または「承認」を書くたびに私のパートナーは私に叫ぶので、日付を使い始めたら面白い方法で数字... :)

世界のほとんどは、,小数点として使用します（下の画像の緑）。多数派が少数派に適応する理由がわかりません。

私は、千単位の区切り記号に提案された代替形式を見たと思います：1'000'000
提案された小数点区切り記号があるかどうかはわかりませんが。
ローカリゼーションは今のところ不要だとは思わない。

通常、私たちプログラマーのすべて、およびインターネットを頻繁にさまよう人は、英語の数字の形式と測定値を知っている可能性が非常に高いので、それほど多くのことを知らず、コンピューターを使用し、独自の形式に見えますが、その逆を意味します。

番号付けと測定の標準を統一することは、1,000.00形式を標準として使用できるグローバルスケールで行うのに良いことだと思いますが、そうではありません。 。

PS：私はディスカバリーアンドヒストリーチャンネルでアメリカのドキュメンタリーをたくさん見ていfootball fieldsます。彼らは、米国外の誰もが（アメリカの）サッカー場の長さについての手がかりを持っていないことを理解していますか？

私の個人的な信念は

ソフトウェアのローカリゼーションは有害です

ほとんどの場合、実行が不十分であるだけでなく、英語を話すコミュニティのユーザーが削減され、ヘルプを得るためのリソースがはるかに多くなります。これはドイツ人にとってそれほど大した問題ではないかもしれませんが、たとえばスロバキア語を話すと、まともな翻訳が得られたとしても、ユーザーを足で撃ったようなものです。現地の用語を知っておく必要があり、それがあなたが望むものを表現するのに適していない場合、それを拡張する必要があります（大混乱を引き起こすリスクがあります。同じ用語に異なる意味を与える場合があります）。
フランスのMacで何かを修正しなければならなかったことがあります。私のフランスのIT用語は、前述のMacの所有者の用語よりも悪かったため、苦労しました。対応する用語の推測の間で前後に翻訳する必要がありました。

英語の専門用語を習得することは、ネイティブの用語よりもそれほど難しくはなく、コンピューターを操作できる程度まで英語を習得することはそれほど難しくありません。また、それはあなたに世界を開きます。代わりに、現在のところ、多くのソフトウェアベンダーは、ドイツから来た場合、ソフトウェアの英語版を入手することをますます難しくしています。さらに悪いことに、多くのサイトが自動的に言語を選択します。Microsoftはこれまでのところ、英語で何かをグーグルで検索し、そのサイトで結果を開くと、リソースがロケールで自動的に表示されます。ああ!!!

私見ですが、インターフェースのローカライズを理解する必要がある場合、インターフェースを間違え、翻訳しても欠陥は消えず、むしろ増えます。

ソフトウェアのローカライズは正しく行われなければなりません

もしソフトウェアをローカライズする、正しくしようとしない限り、それを行う意味はまったくありません。ドイツ人がほとんど理解できないドイツ語のインターフェースにはほとんど価値がありません。

ドイツのすべての人が前者の意味を理解していても、翻訳の過程で「家」を「ハウス」に翻訳することに同意します。
同様に、あなたはに翻訳9/11/2001する必要があります11.9.2001ます。ドイツ人は、前の表記が日付を表していることを理解する可能性が非常に高いですが、おそらく2001年11月9日と解釈します。

この歴史的な日付だけを選んだ理由は、私の個人的な経験で何かを説明するためです。ドイツのメディアはこの悲劇を「ナインイレブン」と呼ぶこともありました。当時の私の英語はあまり上手でなく、特に日付表記に関する知識があまりなかったので、頭の中でこれを「911」として視覚化し、電話番号を使用してイベントを緊急事態と関連付ける何らかのメタファーであると考えました。私の一連の考えを振り返ってみると、私はそれが非常に遠いものであることに同意しますが、別の日付表記に慣れている人にとっては、「11」のようにベルを鳴らさなかったため、もっともらしいようです。これは、特定の規則が私たちの考えにどのように刻まれているか、そしてこれが明白なデータの誤解につながる可能性があることを示しているはずです。

数字に関しては、これは人間にとってそれほど大きな問題ではなく、プログラムにとってははるかに大きな問題です。ドイツ語のローカライズされたソフトウェアは1234.56、「1.234,56」（または運がよければ「1234,56」、運がよければ「1'234,56」）として出力されます。英語形式を想定した寛容なパーサーにそれを直接フィードすると、それは解釈され1.234、容赦のないパーサーはコンマで窒息します。これはほぼ同じ問題ですが、逆の場合も同様です。
また、テンキーのドイツ語キーボードレイアウトでは、ドットのあるコンマがあります。そのため、ドイツ人からドイツ語形式の入力を取得する可能性があります。これを処理できることが方法です「Abbrechen」に「キャンセル」の翻訳よりも重要。

もしあなたが本当に「フォーマットを気にしない」という道を進んでいるのであれば、あなたとあなたのユーザーは何も翻訳しないことで賛成するでしょう。それは少なくとも彼らに英語の文脈を警告するからです。意味をあなたが理解していないので、誤って解釈する情報を印刷するよりも、人々が理解できない単語に辞書を使用するように強制することで、被害が少なくなります。