2002/9/24 新居雅行(msyk@msyk.net)
Mac OS X 10.2がリリースされたが、たくさんの新機能があるため、地味な機能はちょっと埋もれているという感じでもある。その中での「フォルダ名のローカライズ」はけっこう知られているネタではあるとは思うが、いろいろな機能が込められており、興味深い。
ただ、こうした機能もOSへの搭載はおそらくほとんど実績がないと思われる。システム的な動作は「定義通り」であるが、ローカライズということ自体がユーザの操作体系にいい影響を与えるのか、あるいは悪影響を与えるのかといったことも、これから検証することになる。ローカライズ機能を評価するには、まずはその機能を知ることから始めたい。
なお、ドキュメントでは、この種の機能をLocalizeと表現しているが、意味合いは「国際化」だと思われる。ここでは、とりあえず、ローカライズで通すことにしよう。
Mac OS X 10.1.xまでは、ユーザのホームフォルダにはDocumentsやLibraryというフォルダがあり、これらは最初から用意されていた。特に、Libraryフォルダについては、絶対にホームフォルダになくてはいけないものである。いずれにしても、どんな言語でも、英語でフォルダ名が表示されていた。
それが、Mac OS X 10.2から、その時に優先的に使用される言語の設定に応じて、その言語での名前が表示されている。Documentsフォルダは、日本語システム(日本語が最優先に設定されているシステム)では、「書類」フォルダと見えるようになっている。
Englishを優先言語にした
日本語を優先言語にした
韓国語を優先言語にした
なお、Finderの表示はもちろんだが、ファイルを開いたり保存するダイアログボックスでも同様に、言語に応じたローカライズがなされるようになっている。
Finderの環境設定にある「常にファイルの拡張子を表示する」によって、ローカライズがオン/オフされてしまう。これは、チップスというよりもほとんどバグじゃないかと思われる。
こうしたローカライズは、フォルダに対して行えるというのが原則だ。ローカライズには、3通りのメカニズムがMac OS Xでは機能している。
1つ目の既定のフォルダについてのローカライズは、前に図に示したようなものだ。システム(正しくは、FinderとNavigation Servicesだろう)において決められた名前のフォルダに対し、そのフォルダの中に「.localized」という名前のファイルがあれば、そのフォルダ名はローカライズされる。たとえば、「アプリケーション」フォルダ内には、.localizedフォルダが存在するが、ドットで始まるファイルなのでFinderは見えない。Terminalで一覧するときも「ls -a」などオプションをつけないと、一覧には加わらない。
この.localizedファイルは、Finderやエディタなどで作ることは不可能である。FinderやNavigation Servicesのダイアログボックスはドットで始まるファイル名のファイルを作ることができないからだ。結果的に、Terminalで作業して作成するか、プログラムを作って作成することになる。また、削除も同じだ。.localizedファイルの中身は何もはいっていないくてもいいので、Terminalでは「touch .localized」といったコマンドで作成できる(カレントディレクトリにファイルが作られる)。
したがって、.localizedファイルを作成したり、あるいは削除することで、ローカライズの機能を生きるようにしたり、あるいは機能しなくすることができる。こうしたプログラムは、シェルスクリプトで簡単に作成できるのだが、せっかくなので、簡単に実行できるように「ローカライズドスクリプト」というものを作成しておいた。
なお、ホームにあるDocumentsは、「書類」となるが、結果的に他のフォルダにある「Documents」フォルダも、そのフォルダ内に.localizedファイルを作成しておくと、日本語システムでは「書類」と見えてしまう。便利なのかどうなのかはさておき、いずれにしても、システムのロジックが若干はかいま見れるだろう。
この手法でローカライズされたフォルダは、プログラムからは英語での名前で参照できる。つまり、どんな言語で使っている場合でも、プログラムの中では、Documentsフォルダであり、Libraryフォルダなのである。AppleScriptでも、「書類」ではなく「Documents」フォルダとなる。
前に示した3つの手法のうちの2つ目の「アプリケーションのローカライズ」は、アプリケーションのパッケージ(言い換えれば、拡張子が.appのフォルダ)において有効な方法だ。システムに付属のアプリケーションだと、TextEditは、英語やドイツ語だとTextEditなのに対して、日本語システムでは「テキストエディタ」などとなっているが、この手法はパッケージであればどんなアプリケーションでも通用する方法である。
言語ごとにアプリケーション名を変えるには、Info.plistファイルに、CFBundleDisplayNameというキーの項目を付け加えておく。ただし、トップ階層のInfo.plistファイルには、アプリケーション名そのものを書いておく。そして、言語リソースフォルダにあるInfoPlist.stringsファイルに、その言語での名前を記述しておく。つまり、キーになるファイルの内容を示すと、以下のようになる。なお、テキストエディタのInfoPlist.stringsファイルは通常のUnicodeでエンコードされている。
フォルダ階層 | ファイルの中身 | ||||
TextEdit.app | |||||
Contents | |||||
Info.plist | <key>CFBundleDisplayName</key> <string>TextEdit</string> |
||||
Resources | |||||
English.lproj | |||||
InfoPlist.strings | CFBundleDisplayName = "TextEdit"; | ||||
Japanese.lproj | |||||
InfoPlist.strings | CFBundleDisplayName = "テキストエディット"; | ||||
German.lproj | |||||
InfoPlist.strings | CFBundleDisplayName = "TextEdit"; |
ローカライズの3つ目の機能は、既定のフォルダ名でもなく、アプリケーション名でもないフォルダの名前を、ローカライズする手法だ。
たとえば、あるフォルダAnyFolderがある。そのフォルダの名前に.localizedという拡張子をつける。そして、フォルダのルートの位置に、.localizedというフォルダを作成する。さらに、.localizedフォルダの中に、日本語なら「ja.strings」というファイルを作り、そこに以下に示すように、フォルダ名と日本語の名前を結び付けるプロパティの記述を行う。こうすれば、英語システムのときには、「English Name」フォルダとなり、日本語システムでは「日本語の名前」フォルダとなる。なお、ja.stringsファイルなどは、UTF-8でエンコードされる必要がある。
フォルダ階層 | ファイルの内容 | ||
AnyFolder.localized | |||
.localized | |||
en.strings | "AnyFolder" = "English Name"; | ||
ja.strings | "AnyFolder" = "日本語の名前"; |
ここでの「ja」の部分は、ISO 639として制定された、言語を識別するキャラクタを使う。(ちなみに余談だが、国を識別するのは、ISO 3166で、日本だと「JP」となる。)
ただ、こうしたファイルを作成するのは、手作業では面倒である。そこで「ローカライズ名の設定」というアプリケーションを作成した。
この汎用ローカライズにはやや問題がある。それは、システムレベルのフォルダ名を変更することだ。つまり、.localizedという拡張子を付けてしまうことで、名前自体が変わってしまうのである。もちろん、何も他の意図のないフォルダではかまわないとは思われる。だが、たとえば、ライブラリフォルダにあるPrerenrecesフォルダを、この手法で英語だとPreferences、日本語だと「初期設定」にしたいと思ったとしよう。そのためには、Preferences.localizedフォルダというふうに名前を変えないといけない。しかしながら、Preferencesフォルダの名前を変えてしまうと、各種のプログラムの動作が正しく行われなくなる可能性が非常に高い。基本的には、システムが利用するフォルダだとか、アプリケーションがその名前で参照しそうなフォルダ名には使えないということになる。
もっとも、アプリケーション作成者がそれを意図していたら、特に問題はないかもしれない。たとえば、Microsoft Office v.X for Macは、Documents(書類)フォルダに「Microsoft ユーザー」というフォルダを作成して、Entourage Xのデータを保存する。このフォルダ名が「Microsoft User.localized」であって、言語ごとに表示名が上記の手法で定義されていれば、たとえば、英語システムでは「Microsoft User、日本語システムでは「Microsoft ユーザー」といった表示ができる。アプリケーション側は、「Microsoft User.localized」というふうに、拡張子がついているのがわかっているので、そのことを想定してプログラムを作ればいいわけだ。
こうしたフォルダ名のローカライズの使い道となると、一般のユーザよりも、開発者がデータフォルダなどをローカライズする手法として位置づけられるだろう。
ところで、なぜ、フォルダ名に、localizedをつけないといけないのかは若干腑に落ちない。こんなことをしなくても、フォルダ内のルートに、.localizedフォルダがあれば、ローカライズされると言うことにした方がいいのではないかと思われるが、こうした場合に何が矛盾するのか、ご存じの方がいらっしゃったら、教えてもらいたい。
ファイルそのものはローカライズできないと思われる。できないというのは語弊があるが、素直な方法はないだろう。唯一成功しそうな方法は、Mac OSからあるリソースを使うことなのだが、Appleはリソースはレガシーなもとしている。
可能性があるとすると、上記の手法のうち、2つ目のアプリケーションをローカライズする方法だろう。この方法で、一般的にバンドルをローカライズできると考えられる。ただし、文書ファイルとして見えるフォルダの場合に適用してみたことがないので、今後、検証できたらお知らせしたい。
Mac OS X 10.2 Developer Release Notes:
Cocoa Application Framework