自分は、未だに Mac OS X 10.5 Leopard を使っていて、アプリケーションのローカライズには AppleGlot といくらかの自作の補助スクリプトで行っている。

Mac OS X 10.7 Lion がリリースされて大分経つけど、いまさらながら Snow Leopard へのアップデートを計画している。Leopard に満足しちゃっているのだけど、Snow Leopard じゃないと動かないアプリケーションがちらほらと目立ってきたり、Mac App Store が使えないことを不便をほんのちょっとだけ感じるから、Snow Leopard への移行を決断した。決断したけど、実行するのはいつの日になる事やら。

さて、Snow Leopard では、AppleGlot が動かないらしい。というわけで、他のローカライズの仕方を検討してみた。

ところで、まずは Mac OS X アプリケーションにおけるローカライズとは？AppleGlot とは？という根本的な事をついでに紹介する。

Mac OS X アプリケーションの GUI 設計はアプリケーションバンドル内の .nib もしくは .xib ファイルに納められている。これらのファイルは Nib ファイルと呼ばれ、Inferface Builder (Xcode 4 では、Xcode に統合されたらしい）で生成/編集され、GUI のレイアウトや表示する文字列、実行コードとのつながり等が定義されている。ローカライズ作業とは、言語ごとに文字列を翻訳した Nib ファイルを用意する事である。ちなみに、GUI と直接つながっていないNib ファイルに含まれない言語リソースを納める strings ファイルと言う物もある。strings ファイルも言語ごとに用意する必要がある。このような事情は iPhone アプリケーションでも同じかと思う。

さて、ローカライズ作業で問題になるのは、アップデートするときだ。多くの場合、英語版（もしくは母国語版）の Nib ファイルだけを相手して開発を行うと思う。それを各国版のローカライズされた Nib ファイルに展開するのに、Nibファイルをコピーして文字列を翻訳する・・・ということを手動でやるのはばからしいですね。自動で、一次 Nibファイル（開発に使った言語版）を各国版のNib ファイルとしてコピーして、過去のローカライズ作業を参考にして文字列を置き換えてくれよ、というのが人情でしょう。そういう事をしてくれるのが AppleGlot です。AppleGlot には、過去のローラライズ作業だけでなく、他のアプリケーションのローカライズ作業も参照してくれる機能があります。自分のように、こまめに多くのアプリケーションのアップデートを行う人にとっては大助かりです。

AppleGlot にも一つ不満な点はあって、ビルドしたアプリケーションバンドルに対してローカライズを行う仕様である事。すなわち、ローカライズされたリソースをXcode プロジェクトに含むことができない。すなわち、Subversion などを使ったバージョンコントロールの管理下に置けない、という不満はありましたが、それでも有ると無しでは雲泥の差です。ところが、Snow Leopard で AppleGlot は動かなくなっているそうで、Apple からは他の方法は提示される様子もなく、皆さんどうされているんだろうと常々思っておりました。

AppleGlot に不満をもったサードパーティからいくつかのローカライズ用のアプリケーションがリリースされています。

• iLocalize
  • 一番機能が充実していそうで、サポートもしっかりしていそうなお高いシェアウェア。
  • フリーウェア、オープンソースのためなら無料で使えるライセンスがある。
  • Snow Leopard でしか動かないので、試せていない。
• Localization Suite
  • フリーで十分な機能を持っていそうだけど、ドキュメントが整備されていない模様。
  • 使い方がわからない。
• iLingual
  • 過去の/他のアプリケーションのローカライズ結果を自動的に参照する等、翻訳作業を省力化する基本的な機能がシンプルにまとめられている。
  • ローカライズした結果の書き出し場所をダイアログで毎回指定しなければいけないとか、オリジナルの Nib ファイルがアップデートされても、読み込み直してくれないとか、ローカライズ作業の自動化を支援する概念が欠落している。翻訳自体はそう頻繁に行う物ではないけど、Nib ファイルのアップデート（コードへの接続を変更したりとか）は頻繁に発生する。したがって、一次 Nib ファイルを各言語に展開する作業は頻繁に発生するので、iLingual だけではやってられない。作者さんには、この辺の機能に関してリクエストをしてみたけど操作が複雑になるからと取り合ってもらえず。

ところで、Nib ファイルの中の文字列の置き換えだったら、実行時に Nib ファイルのロードしたタイミングで行ってもいいじゃないかと思いますね。実際にそのような取り組みは存在します。

• https://github.com/tcurdt/localizer
• http://wilshipley.com/blog/2009/10/pimp-my-code-part-17-lost-in.html

これは、アプリケーションバンドルの中には英語版の Nib ファイルだけを用意し、言語リソースは strings ファイルとして用意しておく。Nib のロード時に strings ファイルの内容に従って文字列の置き換えを行う、という物です。これでいいなら、なんで各言語ごとに Nib ファイルを用意することになっているのかというと、翻訳にしたがって文字列の長さが変わったりするので GUI のレイアウトの微調整が必要になることがあるからでしょう。でもね、実際のところ、各言語ごとにレイアウトを調整するかというと、そんな事はしない。まあ、開発とローカライズが分業体制になってたりする大手の商用プロダクトの場合は、そういうことをやるのかもしれませんが、自分のような日曜プログラマは、ローカライズしてもレイアウトが破綻しないように一次 Nib ファイルのレイアウトを調整しちゃう。

だから、実行時の Nib ファイルのローカライズでもいいのだけど、いろいろコードを追加しなければいけないしパフォーマンスへの影響も気になる。より保守的には、実行時ではなく、ビルド時に行うというアイデアもある。

• http://developer.casgrain.com/?p=94

これは、ビルドフェーズとして ibtool をつかって strings ファイルから Nib ファイルのローカライズを行うスクリプトを実行するという物。

一見、良さそうに見えるけど、これらの方法では他のアプリケーションのローカライズ作業を参照するなどの翻訳作業の支援がない。新しいアプリケーションを構築するときなど、お決まりの翻訳がたくさんに発生するのだけど、決まりきったところは自動的に処理して欲しい。

などなど、いろいろ考えて、iLingualとビルド時に strings ファイルから Nib ファイルを構築する方法を組み合わせることにした。すなわち、

1. iLingual を使って、ローカライズを行った Nib ファイルを生成。
2. ローカライズした Nib ファイルから、ibtool を使い文字列を strings ファイルとして抽出。
3. ローカライズした Nib ファイルは破棄する。
4. Xcode で strings ファイルからローカライズされたNib ファイルするビルドフェーズを追加する。

この方法なら、iLingual での翻訳作業の支援を受けられるし、翻訳作業の必要がない Nib ファイルのアップデートは自動で行うことができる。これでしばらく運用して不満がなかったら、iLingual のシェアウェアフィーを支払おう。

他によい方法や、支援ツールがあったら教えてください。