01.02は2月1日それとも1月2日？お金を失うローカライズの落とし穴

「01.02.2025」という表記は、ある国では2月初め、別の国では1月初めを意味します。ロケールを考慮せずにオンラインストアやアプリがこの日付を表示すると、利用者は意図とは異なる読み方をしてしまうかもしれません。こうした細部は要件定義書にはめったに載りませんが、返品や納期の遅れ、気まずいサポートメールの原因になるのはまさにこうした点です。よくあるローカライズの落とし穴を取り上げ、それを防ぐ方法を考えてみましょう。

日付と時刻：同じ日付でも三通りの読み方

日付の要素の並び順は国によって異なります。ロシア、ドイツ、そしてヨーロッパの大部分では「日.月.年」の形式が採用されています。アメリカでは先に月が来るため、「03/04/2025」は4月3日ではなく3月4日を意味します。日本、中国、韓国では順序が逆で、年、月、日の順に書かれます。

時刻についても同じことが言えます。ロシア、ヨーロッパの大部分、ラテンアメリカでは24時間制が一般的ですが、アメリカ、カナダ、オーストラリア、インドでは、AMとPMを付けた12時間制が広く使われています。「5:00」とだけ書かれた表記は国によって異なる意味に読まれ、「5時」の約束が予定より12時間ずれてしまうこともあり得ます。

推測に頼らないためには、データやAPIにはISO 8601規格（例：2025-02-01T14:30）を使うのが望ましいでしょう。インターフェースに日付を表示するときは、手で文字列を組み立てるのではなく、ロケールの機能を使うべきです。

数値の区切り記号：点のある場所にカンマが来る

ロシアの「1 500,75」とアメリカの「1,500.75」は、同じ値を表しています。ドイツやブラジルでは桁区切りにピリオドを使い、小数点以下はカンマで書きます（「1.500,75」）。スイスではアポストロフィを使います（「1'500.75」）。インドでは桁のグループ分けが異なり、「1,00,000」は十万を意味します。

この点のミスは特に厄介です。「1.500」という価格が千五百を意味するつもりだったのに、システムが1.5と読み取ってしまうと、利用者はレジで初めて差に気づくことになります。そのため、コードの中で数値の文字列を手作業で連結することは避け、ロケールに基づく書式設定を使い、ファイルの取り込み時に数値の解析を必ず確認してください。

通貨：記号、位置、端数処理

通貨記号は些細なことに思えますが、混乱を招きやすいものです。「$」記号はアメリカ、カナダ、オーストラリアなど複数の国で使われているため、通貨コードがなければ「$」が挙げられたどの国のドルなのか分かりません。だからこそ、国際的な文脈では、ISO 4217規格の3文字の通貨コード（USD、EUR、RUBなど）を明記するのが一般的です。

記号の位置も異なります。英語圏では「$100」と書き、フランスでは「100 €」と、間に改行されないスペースを入れます。ロシアでは「100 ₽」または「100 руб.」と書きます。また、翻訳の段階でも問題が現れることがあります。「価格は消費税込み」という文は、言語によって文構造が変わるため、金額を差し込んで作られた文章では語順が崩れてしまうことがあります。

端数処理も通貨によって異なります。日本の円は通常小数点以下の桁を持たず、クウェート・ディナールは千分の一単位まであります。すべての通貨で一律に小数点以下2桁で計算するシステムでは、合計額が銀行の明細と数円（数銭）ずれることがあり、大口の取引では無視できない金額になることもあります。

メートル法とヤード・ポンド法

世界の大部分はメートル法を使っていますが、アメリカではフィート、ポンド、ガロン、華氏を使用しています。イギリスでは道路標識がマイルで表示され、牛乳はパイント単位で売られています。ただし、イギリスのパイントはアメリカのパイントより大きく、約568ミリリットルに対してアメリカは約473ミリリットルです。ガロンも大西洋の両側で異なります。

オンラインストアにとっては、商品の寸法、荷物の重量、梱包の容量を、購入者にとって馴染みのある単位で表示しつつ、正確さを損なわないことが求められるということです。取扱説明書を翻訳する翻訳者は、単位を訳すべきか、値を換算すべきかを理解しておく必要があります。例えば、説明書に「10インチ」とある場合、ロシア語版では「25 cm」とするのが適切ですが、技術仕様にとって元の数値が重要であれば、括弧内に元の値を残すべきでしょう。

フォームにおける電話番号、住所、氏名

会員登録フォームは主に三つの項目で問題が起きやすくなります。電話番号については、ロシアでは「+7 (999) 123-45-67」のような形式になりますが、ドイツでは桁数が一定ではなく、固定のマスクを使ったテンプレートでは入力を受け付けないことが多くあります。国番号を選択できるフィールドと、電話番号の検証用ライブラリを使うのが望ましいでしょう。

住所については、日本では大きい単位から小さい単位へ（都道府県、市区町村、町名、番地）と書きますが、ロシアやヨーロッパでは逆の順序です。アメリカの郵便番号は数字5桁ですが、イギリスは英数字の組み合わせです。「郵便番号（数字のみ）」という欄は、実在する住所の一部を弾いてしまいます。

氏名については、スペインやラテンアメリカでは姓が二つあることが多く、アイスランドでは姓の代わりに父称が使われ、名前が一つだけの人もいます。「O'Brien」のようなアポストロフィや、ハイフンによってエラーが起きてはいけません。最低限の要件は単純です。必要のない場所で二つの入力欄を必須にしないこと、そしてあらゆるUnicode文字を受け入れることです。

エラーを防ぐ方法：規格と検証

書式を扱う作業は、検証の段階ではなく設計の段階から始まります。以下が役立ちます。

日付はISO 8601、数値は書式なし、通貨はISO 4217のコード付きで保存し、表示はロケールに任せてください。
独自のテンプレートではなく、ICUやプラットフォームの標準的なローカライズライブラリを使ってください。
翻訳者に文脈を伝えてください。テキストには単語だけでなく、単位、通貨、日付の種類が明確に示されている必要があります。
01.02、12:00、1 000,50などの日付や数値を、順序が異なるロケールを含む複数のロケールでインターフェースをテストしてください。
最終確認には母語話者を参加させてください。「пять вечера」が、そのような言い方をしない場面で「17.00」と書かれていることに、彼らの方が早く気づくでしょう。

結論は単純です。形式は意味の一部です。優れた翻訳は、言葉だけでなく、読者が日付、価格、距離をどう理解するかまで保つものです。ローカライズを前もって計画に組み込めば、こうした落とし穴はほとんどコストをかけずに避けられます。リリース後に発見されると、修正には他のどの作業よりも多くの費用がかかります。

プロの翻訳が必要ですか？オンラインで注文して、言語を選び、ファイルをアップロードするだけで、数分で料金をご確認いただけます。