試行錯誤プログラマの
メモランダム

トライ&エラーと対策方法の技術まとめ

【多言語対応の注意 #1】数値の区切り方

多くの言語にマルチに対応しなければならない時、言語ファイルを追加するだけでは危険なことがあります。
特定の言語だけエラー落ちしてしまう・・・なんてことも。

というわけで、今まで多言語対応した中で問題が起こったことのある内容について纏めて行きたいと思います。
多言語対応する方は是非参考にして開発をしていただければ!


小数点の表し方が違う

カンマ「,」 と ピリオド「.」 の使われ方が言語によって異なります。

小数点がピリオド「.」

 日本語、英語、中国語、韓国語など

 ⇛ 0.123

小数点がカンマ「,」
 スペイン語、ドイツ語、フランス語、イタリア語、ロシア語など

 ⇛ 0,123

桁の区切り方も違う

日本では1000を「1,000」と表しますが、こちらも言語によって違います。
基本的にカンマとピリオドの使われ方が反対になってる。
一部言語では、桁区切りはスペースになってるところも。

それで何が問題になる?

さて、これが本題。

基本的には数値型でそのまま使っていれば問題にはなりません。各言語で表示が変わるだけだからね。

問題になるのは、数値型ー文字列型を変換する必要がある場合です。

例えばC#では、int⇛Stringへ変換すると・・・

int i = 1/4;
string s = i.ToString();
// 日本語環境などでは s = "0.25"
// スペイン語環境などでは s = "0,25"

文字列でデータとして取り扱うとき、JSONなどのようにカンマを区切りにしてる事も多いと思います。そういうところでは致命的なことにもなります。

逆に文字列⇛数値変換なんかは、言語ごとにあったカンマorピリオドじゃないとそもそも変換失敗します。やべえ。


対応方法に関しては、開発言語やアプリの望む挙動などによりけりだと思いますので、よしなにやってくれればいいかと思います。
原因さえわかれば大したことはない事だからね。

例えば

  • 数値文字列変換の際にReplaceなどで「.」に統一させる
  • C#では、ToStringの引数にCultureInfo.InvariantCultureを渡すことで、英語標準の変換になる
  • そもそも数値文字列変換しない

とか。

Kiyama
Kiyama

多言語対応は実際問題が起こらないと気づかないことばかりです