アカウント名:
パスワード:
でだ。本題に従うなら、ここのコメントは、3つのことを考えなければいけないわけだ。
問題は 3. です。もし、3. が正しいということになったら、既存のロケール小数点表記が変更になるかも。そうすると、ja と en の、全表現を見直せ、ってことになります。メッセージカタログを使っているだけでは、この問題は解決しない。これも常識。
話は戻って。この大元のコメント [srad.jp]、要約すると「ロケール変更、一発」と書いてある。この方法は、1. のレベルの人が前提知識無しに信用すると問題がある。また、3. に対しては何の問題解決にもなっていない。つまり、大元のコメント [srad.jp]は、過剰に省略されていて、かつ非常識なことを書いている。しかも+モデがついている。これをほっといちゃ、問題なんですわ。
ここで、状況を整理して。
ところで。あなた [srad.jp]はtanimachiよりもより適切な知識と意見を持っているように見受けられます。だとしたら、あなたこそ、大元のコメント [srad.jp]に適切な説明コメントをつけ、世間の誤解を解き、正しい知識を教授して、おまけとして+モデをもらうべきだったんでしょう。
この話、国際化ライブラリやメッセージカタログは、副次的な話だと思ってます。新たな言語に対応するときや既対応言語の小数点表記の仕様が変わったときに。重要な点は、小数点表記だけでなく、表現全体を見直し、作り直す必要がある、ということ自体です。その実現方法は、しなきゃいけないことが決まった後の話です。つまり、当たり前のことの再確認が重要、方法はその当たり前の方法と一致していることを評価してから。そういう意味で言うと、ロケール一発というのは、ものの順序、方法、両方とも誤ってますね。
最後に。力説くさいのは自分の表現力不足。精進してみます。
話は戻って。この大元のコメント [slashdot.jp]、要約すると「ロケール変更、一発」と書いてある。
は、
国際化プログラミングでは、数値表現は日付や時間と同様にロケールによって変わるものです: ・数値: 1.0とか1,0とか、 -1とか1-とか ・通貨: 1,000,000 とか 1.000.000とか ・パーセント: 10% とか %10とか そのため、数値は各言語環境で用意している国際化フォーマット用のライブラリを使って文字列に変換します。 標準が変わったとしても、変更があるのは所詮ライブラリの中の話です。 # 数値フォーマットライブラリ使ってないで自分でカンマ入れてる輩は、も
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
数値表現は文字列の話だよ (スコア:1, 興味深い)
・数値: 1.0とか1,0とか、 -1とか1-とか
・通貨: 1,000,000 とか 1.000.000とか
・パーセント: 10% とか %10とか
そのため、数値は各言語環境で用意している国際化フォーマット用のライブラリを使って文字列に変換します。
標準が変わったとしても、変更があるのは所詮ライブラリの中の話です。
# 数値フォーマットライブラリ使ってないで自分でカンマ入れて
文字列の話ではない、仕様の話だ (スコア:1)
たとえば、値域を [最小値,最大値] と入力する、という仕様はどうしたものでしょうか。[1,2,3] って言われても、1.2から3までなのか。1から2.3までなのかわかんないし。
いや、こんな仕様、変えてしまえばいいんですけどね。問題は、仕様を考えるに当たり、「世界中の表記と習慣を知っておけ」といわれたって困る、ってことな
Re:文字列の話ではない、仕様の話だ (スコア:0)
> 問題は、仕様を考えるに当たり、「世界中の表記と習慣を知っておけ」といわれたって困る、ってことなんです。
だから国際ライブラリ化して、言語の数値リテラルと一線を画するんですよ。
数値リテラルはあくまでリテラルであって、自然言語での数値表現とは別のものにしているんです。
今回
Re:文字列の話ではない、仕様の話だ (スコア:1)
で、数字リテラルに "," が含まれる環境があるので、ふたつの数字リテラルの表示・入力を区切るのに "," を使っちゃいけない。それも了解。
じゃ、ふたつの数字リテラルを区切るのに使ってもよい文字と、それを使ってもよい理由を教えてください。という話です。この部分は、数字リテラル本体ではないので、国際化ライ
Re:文字列の話ではない、仕様の話だ (スコア:0)
国際化ライブラリを使う、で現状には特に問題ないのでは。
ようは自然言語の「数値表記文字列」とプログラミング言語文法の「数値リテラル」は最初から「別物として扱っている」ということなのですが。
例を使うと、あるプログラミング言語では範囲を [1.2, 3]としていた場合、自然言語の数値表記標準が変わったからといって[1,2, 3]に変える必然性はまったく無いのです。
1,2というような「リテラル」を使う言語なら文法が[1,2:3]のようにわかりやすくしているでしょう?
Re:文字列の話ではない、仕様の話だ (スコア:1)
「体重:56.4,58」と、体重の範囲を出力するプログラムがすでにあったとして、どうすればいいのですか? このままだと、たとえば仏文環境なら、「(体重のフランス語): 56,4,58」と表示されます。これじゃ、わけがわからないです。
私としては、最初から自然言語の話しかしていないつもりです。
Re:文字列の話ではない、仕様の話だ (スコア:0)
ロケールに応じて、自分でそれぞれ用意したフォーマッタとパーザーを選択すればいいだけでしょ。
この場合だと、パ
Re:文字列の話ではない、仕様の話だ (スコア:2, すばらしい洞察)
というわけで、「国際化プログラミングでは、数値表現は日付や時間と同様にロケールによって変わるものです [srad.jp]」では不十分であり、ロケールによる表現の変化に合わせ、周辺の表現も適切に考えておく必要があります。
また、「変更があるのは所詮ライブラリの中の話です [srad.jp]」だけでは収まらず、ライブラリ
Re:文字列の話ではない、仕様の話だ (スコア:0)
>また、「変更があるのは所詮ライブラリの中の話です [slashdot.jp]」だけでは収まらず、ライブラリの変更にあわせて周辺の表現を作り直す必要があります。
>たとえ数字と記号しか表示しないプログラムだとしても、サポート各言語ごと
Re:文字列の話ではない、仕様の話だ (スコア:1)
そそ。常識。それはそう。
でだ。本題に従うなら、ここのコメントは、3つのことを考えなければいけないわけだ。
2.については、少なくとも英語圏と日本語圏の人は、いまさら考えなくてもよいだろう。
問題は 3. です。もし、3. が正しいということになったら、既存のロケール小数点表記が変更になるかも。そうすると、ja と en の、全表現を見直せ、ってことになります。メッセージカタログを使っているだけでは、この問題は解決しない。これも常識。
話は戻って。この大元のコメント [srad.jp]、要約すると「ロケール変更、一発」と書いてある。この方法は、1. のレベルの人が前提知識無しに信用すると問題がある。また、3. に対しては何の問題解決にもなっていない。つまり、大元のコメント [srad.jp]は、過剰に省略されていて、かつ非常識なことを書いている。しかも+モデがついている。これをほっといちゃ、問題なんですわ。
ここで、状況を整理して。
ところで。あなた [srad.jp]はtanimachiよりもより適切な知識と意見を持っているように見受けられます。だとしたら、あなたこそ、大元のコメント [srad.jp]に適切な説明コメントをつけ、世間の誤解を解き、正しい知識を教授して、おまけとして+モデをもらうべきだったんでしょう。
この話、国際化ライブラリやメッセージカタログは、副次的な話だと思ってます。新たな言語に対応するときや既対応言語の小数点表記の仕様が変わったときに。重要な点は、小数点表記だけでなく、表現全体を見直し、作り直す必要がある、ということ自体です。その実現方法は、しなきゃいけないことが決まった後の話です。つまり、当たり前のことの再確認が重要、方法はその当たり前の方法と一致していることを評価してから。そういう意味で言うと、ロケール一発というのは、ものの順序、方法、両方とも誤ってますね。
最後に。力説くさいのは自分の表現力不足。精進してみます。
Re:文字列の話ではない、仕様の話だ (スコア:0)
は、