OSTRACISM CO.

C#とObjective-CとJavaと...

ローカリゼーション

　.NETもCocoaもJavaもテキストの扱いはUNICODEベースになっているため、普通にプログラムを書くとそれは概ね国際化対応になっている。国際化（インターナショナリゼーション）に気を付けるべき点は色々あるのだが、日付もお金も関係ないGraphicGripGropはそのまま国際化対応である。
　残るは地域化（ローカリゼーション）の方で、.NETもCocoaもJavaもそれなりに工夫した仕組みを用意している。少なくともプログラマが独自に云々という状況はない。

C#

　System.Windows.Forms.FormクラスにLocalizableプロパティがあり、これをtrueにすることでFormの持つ文字列が.resxファイルに追い出され、複数言語対応にできるようになり、Languageの（規定値）以外の言語を選ぶことで対応言語を追加できる。

m_rmStrings = new ResourceManager("GGG4W.Resource1", GetType().Assembly);
...
this.btnSearch.Text = m_rmStrings.GetString("RS_SEARCH");

　この.resxファイルの仕組みは独自に利用できて、名前を指定してインスタンス化したSystem.Resources.ResourceManagerクラスを使って、ローカライズされた文字列を得ることができる。

Objective-C

　Xcodeにて.nibファイルの情報を見ると、言語環境を追加のボタンがある。言語を追加するとデフォルト（English）の.nibの複製が新しい言語用に用意され、それを編集することになる。ウィンドウやダイアログのリソースが多重化される（すなわちメンテナンス性が低い）のでできるだけローカリゼーションは先延ばしにしたいところだ。

[btnSearch setTitle:NSLocalizedString(@"Search", @"")];

　Licalizable.stringsという特別な名前のファイルを用意するとNSLocalizedString関数（実体はマクロ）でローカライズされた文字列を得ることができる。

Java

　NetBeansではウィンドウやダイアログのGUI部品のtextプロパティにて、StringEditorからリソースバンドルにモードを変えるとPropertiesクラスを使った仕組みで複数言語対応にできるようになる。いちいち指示をGUI部品単位でしなくてはいけないのはあんまりで、要改善であろう。

btnSearch.setText(java.util.ResourceBundle.getBundle(m_bundlePath).getString("btnSearch"));

　java.util.ResourceBundleクラスは上記ではResourceからResource.propertiesというファイルを元に文字列を持ってくるが、例えば日本語環境だとResource_ja.propertiesの優先度が上がる。　ただ、NetBeansの問題か、Javaの問題かは不明だが、

btnSearch=\u691C\u7D22

のように日本語はエスケープされる必要があり、直接は書けない。メンテナンス性は皆無ということだ。
　Java版GraphicGripGrop の日本語化はちょっと挫折しかかった。

2005.08.03

「インデックス」へ戻る

OSTRACISM CO.
OSTRA / Takeshi Yoneki