ロケールとはOSが扱う「言語」と「国」を規定するものであります。
Palm Pre Sprint版においては en_us（英語_米国）と es_us（スペイン語_米国）、2つのロケールがサポートされております。
これに jp_jp（日本語_日本）のロケールを追加したい、或いは入れ替えたい、果たしてそんな事が可能なんでしょうか？
webOS のロケール決定メカニズムとは如何なるものなのか？
更にディープな部分へと解析を進めて行きました。
■ランゲージコードとカントリーコード
皆さん良くご存知の通り、旧PalmOSの時代、日本のロケールは jpJP でした。
ボクは webOS でも jp_jp で良いだろうと思っておりましたが、どうもコレは間違いだったみたいです。
調べましたところ ISO 639 では、以下のように規定されておりました。
言語コード：ja → 日本語
また、ISO 3166-2 では以下のように規定されておりました
国コード：JP → 日本
つまり、日本のロケールは jp_jp では無く、ja_jp が正しいコードになります。
■旧来手法による検証
Palm Mojo Framework の API リファレンスを読んでみますと、現在のシステムロケールを取得するAPIとして、Mojo.Locale.getCurrentLocale() という関数が有りました。
http://developer.palm.com/palm-sdk/jsdoc/symbols/Mojo.Locale.html
旧PalmOSでも、これと似たようなAPIが有りました、J-OS や JaPon では、このAPIをフックする事により、システムロケールを jpJP と詐称する手法が用いられました。
つまりホントは英語版で enUS なのに「システムロケールは jpJP だよ～」と嘘をつく訳ですね。
これと同じ手法が webOS でも使えるのではないかと、ボクは考えたのです。
捜しましたところ Mojo.Locale.getCurrentLocale() 関数は、以下のモジュール内に有りました。
/usr/palm/frameworks/mojo/builtins/palmInitFramework200_18.js
もちろん関数自体が java script で書かれていますので、ソースリスト丸見え、テキストエディタで書き換え自由な訳です、ボクは簡単に出来るものと信じておりました。
ところがです、この関数をいくら弄ってみても、ロケールを詐称する事が出来ないのです、これには悩みました。
それで、Pre に標準搭載されているアプリ側のソースも調べてみたんです。
すると、どのアプリからも、この関数を呼んで無いじゃあ～りませんか、こりゃ完全にやられました（ＴＴ）
■webOSのサービスによる検証
そこで次にボクは Laungage picker のソースを解析し、この中でロケールを切り替えている処理部分を抜き出して、簡単なテストアプリを作ってみました。
以下は、そのテストアプリの画面と、その部分のソースです、画面のボタンを押すと、webOSのサービスを呼ぶ方法でロケールを切り替えるという、極めて単純なアプリであります。
var languageCode = “ja”;
var countryCode = “jp”;
this.setLocaleReq1 = new Mojo.Service.Request(”palm://com.palm.systemservice”, {
method: ’setPreferences’,
parameters: {”locale”:{”languageCode”:languageCode,”countryCode”:countryCode}},
});
それで、このテストアプリの
var languageCode = “ja”;
var countryCode = “jp”;
という部分を色々変えてみてテストを行いましたところ、確かに en_us または es_us の場合は、ロケールを切り替える事が出来ました。
ただし、それ以外のロケールには、いくらやっても切り替わりません。
これはどう考えても en_us と es_us ロケール以外は変更出来無いようにしているみたいです。
「これはキャリア（Sprint）の縛りなのか？」そんな憶測がボクの頭の中をよぎりました。
そんな訳で、まさに八方塞がり、もう何日もこの壁に突き当たったまま、ボクは先に進む事が出来なくなってしまったのです。
しかし、運命の女神は、まだボクを見捨てた訳ではありませんでした。
つづく
