Not only is the Internet dead, it's starting to smell really bad.:2008年01月10日分

2008/01/10(Thu)

g11n vs i18n

あまり上手ではない例え話の続き。

非常口マークなどの ピクトグラムってーのは日本発のg11nだったりします(ISO/TC145図記号)。
一方で 緊急通報用電話番号なんてのはまだ世界各国地域によって違うままです。
前サカ日本代表監督が倒れた時、奥方が救急車の呼び方が判らなくてなんてニュースがありましたが
「世界中何処にいても同じ操作で緊急通報」できるようになれば世の中ちょっと便利になるかもしれません。

g11n的には

世界中の緊急通報用電話番号を全て「911」に統一しませんか?

となります。
世界各国どこでも911というアイデアはとてもシンプルで、ある意味理想ではあるのですが
911というプレフィクスを既に一般の電番に使ってる地域では、ン万世帯単位の番号変更が必要になってしまいます。
また911に番号が変わったことを周知しなければなりませんし、移行期間 *1中は新旧両方を維持 *2
する必要があります(でないと移行に失敗した時に緊急通報手段なくなっちゃう)。

まあ合理化の為に通報受付センターを統一できたりする可能性もあるわけですが *3
日本からの通報に対してオペレーターが英語で応えたり、メルボルンの洪水に北京から消防車が
出動したりするよなTとんでもないB馬鹿げたS処理 *4にならないよう(なおかつ通報からの現場到着の時間が遅くならないよう)
設計しなければなりません、それでもまだシンプルでいられますか?大風呂敷過ぎませんか?

他にも携帯電話のエラー「送信できませんでした(911)」に返電するYUTORI対策とか
想定外の問題に頭を悩ませる事があるかもしれません、なんせまだテストされてない新しいものですし。

他方、i18n的には

世界中の電話機に新しく「緊急通報用ボタン」をつけませんか?

なのです。
ボタン一発で

  1. 現在位置を判定
  2. 地域 → 電番変換データベース検索(日本/119, 北米/911, ...)
  3. 通報しますた

まで自動でやってくれる新機能つきの電話機を新発売しましょーというわけです。
緊急通報用電話番号が本当は何番なのかは、ボタンとして隠蔽されます。
そしてこれまでちゃんと機能してきた日本の119、北米の911というシステムは
新システムのバックエンドとして温存されます(合理化は後回しになりますが)。
テストし尽くされたものは触るな(なぜなら今動いてるのは奇跡だからw)の法則にかなってます。

しかし世界中の電話機が全てこの新しいボタンを実装するまで、とてもとても長い時間がかかることが予想されます *5
それまでは「世界中何処にいても同じ操作で緊急通報できる」メリットは享受できないわけです。
この空白期間中にまあ大抵の人は「シンプルをモットーとする」g11nの鯵に orzオルグ(死語)されてしまいますやね。

また各国で異なる通報方法をうまくラップする為に、このボタンの実装が止むに止まれず
「3回まわして柔らかくなったところにスポイトで(以下略」なんて覚えられないような操作になったりする事もあるわけです。

g11nの主張は「万国共通、統一された後の世界はなんてシンプルなんだー、さあイマ~ジ(JAS略」ですが

などの点をチェックして、嘘が無いか見極めなければ。
実は複雑さ、コストにおいてi18nなアプローチと何ら変わりなかったなんて往々にして起こるわけです。
んでレガシーの存在が目の上のなんとやらだと、強制移行という2011年地デジの旅方式(スターリンAA略

逆にi18nの「まぁまぁ時間がかかるものですから、でも今日よりは明日は…」という言い訳も信じてもいけません。
実はその新しい電話機はSEDのよに永遠に商品化されないぜ
Don't Believe The Hype(by Public Enemy)な可能性もあるわけでして。
その意味でも code then spec, not spec then code じゅーよー。

そしてラップ(wrapな、rapじゃなくて)することによってえらく複雑なインタフェースになってしまうようなら
レガシーを捨てた場合に生じる不都合とちゃんと天秤に載せて判断することですな。

リベラル・保守どっちも空手形しか持ってないのに2大政党制なんて悪夢だよね、って何の話だったけ。

そもそもwchar_tって何?って人が一番多いのでは :-)
Java方面だって これ守ってるコードが納品されてきたことはあまり無いうちの現場の明日はどっちだ?

*1:ダラダラと続き、永遠に終わらない可能性が高いかもね...
*2:新旧維持ならまだいいんだけどUnicodeの場合、既存文字集合との変換テーブル作成はとてもとても時間のかかる作業なわけでして...
*3:ISO-2022のように状態遷移を保持する必要が無いーとか主張したりね...
*4:16bitの尻拭いにサロゲートペアとか、漢字統合の尻拭いに言語タグとか異体字セレクタとかね...
*5:実際、C90AMD1やC99のwchar_t APIなどの実装がなかなか揃わなかったことは C1X宣言にも反省として取り上げられてますな。