2015年02月22日

ローカライズが反映されない (2)

昨日のはXcodeの問題でしたが、意外とあるのが自分のミスでローカライズが反映されないこと。

開発の初期とにかく動くか確認しながら実装する時に、「仮」実装のつもりで文字列をソースコード中に埋め込んで置く。そして本格的に実装する時に、NSLocalizedString()で書き換えるのだが、それを忘れることがある。

はじめからNSLocalizedString()でローカライズする準備が出来ている文字列は、Localizable.stringsファイルに入っているので忘れずに各国語に翻訳できるが、それをしなかった文字列は忘れられる。実際に動作させて確認するときにも、テストケースが各文字列リソースが正しく表示されているかどうかという視点で作ると、そのテストケースに入らなかった文字列は確認できない。ちゃんと全画面、全機能を全言語に対して実行しなければならない。

同じような間違いだが、GUI上のUILabelの文字列をコードで設定するようにしていた。これはカスタムのUITextFieldCellでラベル部分の文字列は当然行によって違うのでコードで設定するしかない。

ところが、試しに実装してみようと思ってやっぱりNSLocalizedString()を使わずに、ソースコード中に直接表示する文字列を書いてしまった。だが、実装を進めるうちにそのセルは1回しか使わない。他の行ではまた別のカスタムセルを使うことになったのだ。

実装が終わって、国際化するときにカスタムセルは1箇所でしかつかっていないので最初に外部から文字列を設定するという設計を忘れてしまい。xibファイルを国際化してしまう。そして作られた.stringsファイルを翻訳。だが、全然表示が変わらない。昨日書いた方法でクリーンビルドしても変わらない。おかしいなあ、おかしいなあ。と思っていると、直接UILabelに文字列を設定しているコードを見つけるというわけだ。

途中で設計や実装方針が変わったせいもあるが、結局のところ仮実装だろうがなんだろうが、GUIやファイルなど外部に出力する可能性のある文字列をプログラムコード中に各場合には手を抜かず必ずNSLocalizedString()を経由する。後で忘れてしまう可能性があるし、全体を探す手間もあるし。これを徹底すれば今回のような翻訳し忘れは起こらない。

これにつきる。

Localizable.stringsにも転記する手間を考えたら、2カ所入力する手間がかかると思うかもしれないが、NSLocalizedString()はもしLocalizable.stringsファイルに対応する文字列がなければ第一引数そのものを返すので、場合によってはLocalizable.stringsファイルへは何も書く必要がない。

翻訳し忘れるかも?NSLocalizedString()関数が使われている箇所を抽出することはそれほど難しくないので、忘れた文字列があるかどうかはすぐに見つけ出せる。

Appleが提供している genstrings というコマンドを使うとソースコードから簡単に.stringsファイルを作成できる。

$ genstrings *.m


上記コマンドはカレントディレクトリにあるObjective-Cソースコード中のNSLocalizedString()から文字列を抽出して、カレントディレクトリにLocalized.stringsというファイルを作って書き出してくれる。

なお、私は時々

NSString *aString;
if ( flag ) {
aString = @"on";
} else {
aString = @"off";
}
return NSLocalizedString(aString, nil);


みたいなコードを書いてしまうことがあるのだが、こういうのは抽出できない。それにコメントもちゃんと書いておかないと抽出したファイルでの文字列の用途がわからないので翻訳を他の人に依頼する場合などに困ってしまう。だから上記例のnilもよくない。
posted by 永遠製作所 at 16:29| 東京 ☁| Comment(0) | TrackBack(0) | iPhone/iPod touch | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック