キクスイ製アプリケーションソフトは、ユニコードアプリといって日本語Windowsでは日本語を、その他のWindowsでは自動的に英語を表示します。ところが、あるアプリをヨーロッパで起動するとエラーとなって動かないという問題が発生しました。

数値表記ルールは万国共通ではない

原因は、小数点表記のローカルルールでした。実はフランスやドイツ、イタリアなどのヨーロッパの国々では小数点表記にピリオド「.」でなく、カンマ「,」が使われているのです。これは貿易実務をしている方ならご存知のことかもしれません。
たとえば、Excelで直接読み込めるCSVファイルはComma Separated Valueと言うように、カンマをセパレータとしたファイルですが、ヨーロッパでは小数点とセパレータがカンマでは都合が悪いので、セミコロンをセパレータとして使いSemicolon Separated Valueとなりますが、それでも呼称（CSVファイル）は同じです。

エラーのメカニズムとしてはこのようなものです。
たとえば「*IDN?コマンド」で機種情報を問い合わせると、菊水の電源はヨーロッパの空気を感じ取るように作られてはいないので「KIKUSUI,PCR6000LE,AB123456,5.02」と返してきます。これはカンマ区切りの文字列で「KIKUSUI,モデル名,シリアルナンバー,バージョン」を意味します。そこから、バージョン情報を抜き取り大小比較するために文字列を数値に変換します。もし日米等のWindowsであれば「5.02」 を数値に型変換しても何の問題はありません。
しかしヨーロッパ（のWindows）では、文字列「5.02」を数値に型変換処理しても表記が「5.02」のままだと数値として認識されないのでエラーとなります。ここは「5,02」に変換されなければならないわけです。

多言語対応ではカルチャ情報を適宜使う

Windowsプログラムの世界ではカルチャ情報という概念があります。ここでの意味は文化ではありません。 地域と言語の情報という意味になります。

文字列「5.02」を数値として型変換するときに、インバリアントカルチャ（地域のカルチャに依存しない） で変換してねと付け加えるとエラーにならずに、ちゃんと数値として計算処理されるようになります。画面で数値を表示する場合は、カレントカルチャ（現在のカルチャ）を使えば、地域に合わせた表示がなされます。
また、たとえば菊水の電源に送る電圧設定コマンド（VOLT XXXXX）について、ヨーロッパ表記「123,4」を米国カルチャで処理するように書けば、それは「VOLT 123.4」となります。

図1カルチャ処理の例

MS-DOS時代はNECのPC98シリーズで動作すればよく、それはほぼ日本人向けでした。Windows3.1からWindows95時代は、日本語版と英語版を別アプリで用意していました。そしてWindowsXPの頃から .NET Frameworkの時代となり、日本語Windowsなら日本語で、その他のWindowsなら英語でと自動的に切り替わるユニコードアプリになり、加えて「ヨーロッパでの小数点処理」といったローカルルールに自動対応する方法も備わりました。

グローバル対応＝共通化ではない

世はグローバル対応が当然という風潮で、この流れは止めようがありません。しかし「グローバル対応＝共通化」ではありません。言語や文化、習慣といった「ローカル（地域性）」という現実は、なんだかんだ言ってもあるわけで、それを無視して製品仕様を共通化したところで受け入れてもらえるはずがありません。見かけは同じものでも、地域性から生じる差異を何らかの方法で誰かが埋める必要があります。
いずれはその仕事を「AI」が上手いことやってくれるのかもしれません。しかし当面は「人」であるソフトウェアエンジニアが、皆が見えないところでヒイヒイ言いながら対処してゆくことになるのでしょうね。

ということで、ヨーロッパは「てん（点）でダメ」というお話でした。
お後がよろしいようで・・・（笑）