JapanShop／リテールテック等に、行ってきた！

　今日は、東京ビックサイトでやっている、JapanShop／リテールテックなどなど（いくつかの展示が一緒にやっている）にいってきました。その報告です。

---

■流通BMS

　コンピューター関係でいうと、やっぱ、流通BMS関連が多かった。
　昔、流通システム開発センターが、流通XML－EDIサブセットとかやって、こけてた（こたーねえ？？）けど、今度の流通BMSは、期待持てそうだよね。ebXMLとかつかって、ちゃんとしていそうだし。。（その手の話は、ここ）

---

■NFC、Felica、Mifareで、CRM？？

　ほかは、NFC(Near Field Communication)ですかねー。もちろん、Felicaによって、日本では、まいにち、駅（の改札）でつかわれているわけですが、それが標準化されたり、フォーラムがあったり、また、Felicaではない陣営である、Mifare（まいふぇあ）が、たばこカード（Taspo）に導入されたらしいけど、その辺の話題。

　凸版とかHPとかがやってましたね。

　HPでは、端末からサーバーを結ぶソリューションとしてFelicaを言っていた。ウィリアムのいたずらは、Felicaではなく、ケータイだと思ってるんだけど（これについては、今度考えを披露する予定）まー、ケータイにもFelica入ってるわけなので・・そーともいえるね。

　で、最近のNFCは、読みとれるだけでなく、書き込めるし、通信もできる。
　ってなことで、ケータイを２つ使って、お客さんのケータイにチケットがはいってて、それを、係員の人のケータイできる（もぎる）というやつを、DNPがやっていた。

　さらに、DNPはNext　CRMっていう話をやってた。P(プリンティング）＆I(インフォメーション）ということで、DM、インターネット、なにからなにまでの顧客に対するアプローチと、ケータイやポイントカード、その他いろいろによる顧客情報収集、RIAによる多彩なグラフ表示、さらにマーケティングなど、一切合財やりますよっていうかんじのCRM。
　たしかに、大日本は、DTPのときのように、データおさえちゃってるわけで、それは強いよね！
（データ抑えられちゃうと、ほかに移りにくい）

---

■減ったもの

　派手な展示とPOS関連の展示は、減ったかな・・
　OPOSとかは、もう、だれもいわないね（＾＾；）

　ざっと、こんなかんじかな・・

翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる－その２

　シリーズになりそうな「翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる」のつづき

ローカライズするには、たぶん、次の３つの手順が必要だと思う。

（１）国際化対応プログラムになっているか確認
（２）翻訳＆前のバージョンのものを入れる
（３）翻訳したものを戻し、稼動するか確認

ここで、前回は、（１）について説明しました。今回は、（２）の手順です。

---

■おおきく、自動的に訳す部分と、訳語統一→翻訳の手作業部分

　この翻訳は、おおきく以下の２つの部分に分かれます。
（あ）自動的に翻訳機などで訳す部分
　　　　前のバージョンの用語統一辞書があれば、
　　　　それを使って、翻訳機で訳し、
　　　　さらに前のバージョンと同じところは、
　　　　そのまま入れる

（い）訳語統一→翻訳の手作業部分
　　　　用語統一すべき部分の抽出
　　　　仮訳
　　　　用語統一
　　　　用語統一したもので再度翻訳
　　　　とりあえず、翻訳したもの作成→（３）へ

以下、その流れを図に描きます

---

■（あ）自動的に翻訳機などで訳す部分

図に描くと、こんなかんじ
翻訳元のファイルと（英語のメッセージカタログなど）
前にやっていた用語統一辞書を使って、翻訳します


一見複雑そうだけど、実はたいしたことなく、起動するだけで、あとは自動的にやってくれる部分。

ここで、最終的には、
・翻訳用のワークベンチ（Babelなど）を使う場合には、そこにデータが入る
・機械翻訳終了時点の実行ファイル
・ID（とステータスも入れとくと便利）の実行ファイル
ができます。下の２つはなぜ作るのかは、今後話します（これがないと、見当違いのところを仮訳してしまう）

---

■（い）訳語統一→翻訳の手作業部分

　そいつは、こんなかんじ


（あ）の成果物を入力とし、最終的に、「（３）翻訳したものを戻し、稼動するか確認」するための実行ファイルをつくります。また、今回分の用語統一辞書を作成します。

　大きく仮訳→用語統一→本訳ということになります。

---

では、(このシリーズの）次回から、それぞれの手順の内容について説明します。

Greasemonkey等でクライアント側でカスタマイズしないと、オープンソースの利便性はない。。

　３日に書いた、Greasemonkeyの話。

　Greasemonkey等を使って、（マッシュアップとかして）、ユーザーが意図する画面にカスタマイズすることができたとする。この場合、サーバーに手を入れていないから、サーバーは画面が変わらない限り、どんなバグ修正・環境変更をされてもOKってことになる。

　仮に、画面が変わってしまっても、その変更点に対するカスタマイズの修正だけで済む。

---

　一方、　Greasemonkey等をつかわず、サーバー側にあるHTMLやPHP等に対して、直接修正してカスタマイズしたときを考えよう。たとえば、XOOPSを、画面から何から、大幅に変更してしまったとする（テーマで書き変える以上の、プログラム修正をしてしまったとする）。

　この場合、バグFIXをした、新しいバージョンをいれてしまうと、カスタマイズ部分を書きつぶしてしまうので、そうそう、　新しいバージョンをいれることはできない。

　もし、バグFixしたものを、すぐに入れたいような場合は、セールスフォースのように、あらかじめ、カスタマイズできる範囲を決めて（実際にはカスタマイズツールを作って）、その範囲でカスタマイズを行うしかない。この場合、カスタマイズの部分は分離される（たいていは設定ファイルのようなものに）ので、それ以外のところを修正してもOKだ。
　この切り分けにより、セールスフォースは、どんどん更新をかけ、全ユーザーが更新のメリットを（享受しようと思えば）享受できるらしい。

　ただ、この場合、抜本的に画面もワークフローも変えちゃうようなものは、たぶん無理だろう。

---

　そーすると、どんどんバグフィックスして改訂版が出るという、オープンソースの利便性を享受したいのなら、

・サーバー側はできるだけいじらない
・カスタマイズは、クライアント側でGreasemonkeyとかを使って画面書き換えする

ということになるだろう。
今までよくある開発のように、サーバー側のHTML、PHPファイル等を修正してしまうと、最新版のアップグレードができなくなる（すると、書きつぶすので）ので、困るから。。

こんど、この前のケータイの認証の話とからめて、その辺のことを書きたいと思います。