素人殺しの多国語対応TIPS

オリンピックが来るたびに多国語対応のことを思い出すお話の続編。

ソフトウェア工学的にいろんな言語を押しなべて見たときに、日本語もそこそこ難しい言語だとは思う。英数字に対して、半角abc123もあれば、全角ＡＢＣ１２３もあるのはクレイジーだろう。さらに、カタカナ、ひらがな、漢字など文字のバリエーションが多い。

それに比べて、他の言語は文字のバリエーションは少ない。でも、知らないと対応できない素人殺しな概念はたくさんある。ハードルを踏み倒しながら進むように、テストチームからの指摘や市場からの苦情によって学んだことを思いながら書く。

カンマ小数点

オススメ設定値のバックアップファイルを配布したところ、「値が反映されない」という不具合指摘を受けた。いくらやっても手元で不具合は再現せず、コンピューターの部分を丸ごとセンドバックしてもらってカンマ小数点が原因だと気付いた。

欧州圏のように、小数点としてカンマを使い、区切り記号としてピリオドを使う地域があるのだ。

OS側で設定できるものであれば、表示機能では「ピリオド」を指定するのではなく、「小数点」という概念を指定してAPI経由で記号を得る必要がある。異なった設定の環境間でもファイルのバックアップ/リストアができるような取り決め（ファイルはピリオドでいこうぜ等）も必要となる。

サマータイム

データベースの情報を時系列順に並べるにあたって、素直に設計すればデータベースに記録した日付・時刻の順番で並べるのが当たり前だろう。

だがしかし、サマータイムのある地域では、当たり前が崩れる。サマータイムの開始日は時間がジャンプするだけなので問題ないけれど、終了日である11月第1日曜日の1:59 の次は2:00ではなく再度1:00に戻る。つまり、素直に日付・時刻で並べると、このタイミングに記録されたデータの順番が狂ってしまう。

どこまで厳密さが求められる用途なのかにもよるけれど、もし順番が変わることで良からぬことが起きる場合は、対策が必要となる。具体的には、データベース内に日付時刻とは別の通し番号を格納してソート時に参照するとか。または、UTC（協定世界時）で記録しておいて表示手前で現地時間に変換するとか。

OSのログ

UTC（協定世界時）の話題ついでに。海外から「ソフトウェアが異常停止したんですけどー！」という報告をいただき、ログファイル一式を送ってもらって解析することがある。さながら捜査官の気持ちで調査に臨むも、どんなに解析してもOSのログ上は異常停止の記録が無いことに悩んでいた。

知ってしまえばどうってことはないのだけど、OSのログがUTC（協定世界時）で記録されているもんだから、ログビューアーは良かれと思って日本時間に変換してくれていた。日本でログ解析をする時には、報告された現地時間を日本時間に変換して読まねばならないのだ。

フォント

内部のテストで「入力しても受け付けられない文字がある」と指摘された。Unicodeなので入力できない訳はなく、よくよく調べると指定していたフォントでは表現できない無い文字だった。

Unicodeであるが故にいろんな文字でも受け入れることができるけれど、漢字も韓国語もギリシア語もロシア語もすべてを表現できるようなフォントなんて無い。

対策として、OSレベルで「フォントリンク」を指定した。複数のフォントを順番に指定しておき、指定したフォントでヒットしなければ次のフォントから探すというアレンジである。

これはこれで、並べたと時に不自然に見えないようなフォント選定などが難しかったりする。とは言え対策としては有効に働いた。

まとめ

自分達では当たり前と思っていることが、よその国では当たり前ではないということに気付くのは面白い。それが、海外旅行ではなく開発現場で箱詰めになりながらでも体験できるのだ。

一律ですべての対応が必要という訳ではなく、販売する地域が限定されていれば考慮が不要なものもあるし、製品によっては無頓着なままでも問題とならないものもある。だから判断をすればよいのだけれど、知らないことには判断の土台にも上がらない。

発売後のバージョンアップで多国語対応する場合や、派生開発（既にあるソフトウェア資産を活かして開発する）場合には、設計を変えることは難しく「最初に知っていればスマートに対処できたのに...」と感じる事も多い。

私が「素人殺し」だと感じたトピックを挙げてみた。この内容ってnoteよりかはQiitaだなと思いつつ、これから多国語対応をしようとする人には役立てば幸い。