言語リソース使用箇所の探し方(中級編)

登録日: 2003年10月 05日 記事: 1744

言語リソースのローカライズに際して、英語リソースファイルだけを見てもその意味が理解できないことがあります。そのような場合、使用箇所のコードを特定することで解決し、文脈に応じた適切な訳にできることが多くあります。具体例を挙げて、そのための手順を簡単に紹介します。
# 単純なものはすぐにできると思うので中級編です。
# DTD の実体参照を使用する XUL を探すのが初級編ですが、書くかどうかは未定です。(^^;

css.properties

Code:

PESkipAtRuleEOF=end of unknown at-rule
PECharsetRuleEOF=charset string in @charset rule
PEGatherMediaEOF=end of media list in @import or @media rule

全体的に css.properties はエラーメッセージが定義されているファイルのようですので、これらをエラーメッセージ風に直訳してみるとこのような感じになるかも知れません。

Code:

PESkipAtRuleEOF=未知の@ルールの終わりです。
PECharsetRuleEOF=@charsetルールに文字エンコーディング名が含まれています。
PEGatherMediaEOF=@importルールまたは@mediaルールのメディアリストの終わりです。

悪い例ですので若干意図的にデフォルメしていますが、これではエラーメッセージとしてよくわからないものになってしまっていますね。
特に PECharsetRuleEOF は意味的に間違っています。@charsetルールはそもそも文字エンコーディング(文字コード)を指定するためのものであり、それが入っていることをエラーとするなんてあり得ません。

そこで、これらのリソースがどのように使われているか調べて、適切な訳を考えてみましょう。
Mozilla 1.8 Branch 用の LXR で PECharsetRuleEOF の使用箇所をテキスト検索すると、このリソースの定義ファイルである css.properties の他に nsCSSParser.cpp の 1224 行目で使用されていることが分かります(2005/08/18現在)。

REPORT_UNEXPECTED_EOF という関数の引数に使用されているようですので、その関数を調べてみましょう。勿論、今度はLXR で識別子 REPORT_UNEXPECTED_EOF を検索するのです。結果、これは実際には関数ではなくマクロであり、次の 4 箇所で定義されていることが分かります。

これはマクロですし使用箇所と同じ nsCSSParser.cpp ファイル中のものを確認すると、490行目のマクロでは何もせず破棄しているので、ここでは 469行目で定義しているマクロに注目しましょう。

Code:

469 #define REPORT_UNEXPECTED_EOF(lf_) \
470 mScanner.ReportUnexpectedEOF(#lf_)

どうやら mScanner クラスの ReportUnexpectedEOF メソッドに引数として渡されているようです(469行目の末尾は改行がエスケープされています)。そこで、続けて ReportUnexpectedEOF メソッドの定義箇所を検索すると、次のメソッド定義が見つかります。

Code:

378 void nsCSSScanner::ReportUnexpectedEOF(const char* aLookingFor)
379 {
380 ENSURE_STRINGBUNDLE;
381
382 nsXPIDLString innerStr;
383 gStringBundle->GetStringFromName(NS_ConvertASCIItoUTF16(aLookingFor).get(),
384 getter_Copies(innerStr));
385
386 const PRUnichar *params[] = {
387 innerStr.get()
388 };
389 nsXPIDLString str;
390 gStringBundle->FormatStringFromName(NS_LITERAL_STRING("PEUnexpEOF").get(),
391 params, NS_ARRAY_LENGTH(params),
392 getter_Copies(str));
393 AddToError(str);
394 }

ざっと見たところ 389行目で引数で指定した名前から文字列の定義を innerStr に収め、それを param 配列の要素として収めています。更に、390行目では PEUnexpEOF 中の変数の置き換え文字列として渡しています。
C 言語の書けない人でも、言われてみればそんな気がするって感じのコードになっていますよね。因みに私も C は本格的なコードを書けません。(笑)

され、これであと一歩です。代入先である PEUnexpEOF を LXR で検索しましょう。 css.properties で定義されていることが分かります。そう、もとのファイルに戻ってきたのです。

Code:

PEUnexpEOF=Unexpected end of file while searching for %1$S.

これを訳すとこんな感じでしょうか。

Code:

PEUnexpEOF=%1$Sを検索中にファイル終端に達してしまいました。

テンプレートとなる文字列と代入する文字列を同じファイルで定義していて、PECharsetRuleEOF はその中で使われる代入文字列だったのです。文脈としては検索対象のものということですから、名詞形で訳せば良かったのです。
これを踏まえて他の2つと一緒に直訳してみたらこんな感じでしょうか。

Code:

PESkipAtRuleEOF=未知の @ルール部の終わり
PECharsetRuleEOF=@charset ルールの文字エンコーディング名
PEGatherMediaEOF=@import ルールまたは @media ルールのメディアリストの終わり

最初の訳では実際にユーザが見るエラーメッセージは

Quote:

@charsetルールに文字エンコーディング名が含まれています。を検索中にファイル終端に達してしまいました。

などという意味不明なものになってしまうところでしたが、修正後のものであれば次のようになメッセージになります。

Quote:

@charset ルールの文字エンコーディング名を検索中にファイル終端に達してしまいました。

これで意味が通じるエラーメッセージが生成されるようになりました。;-)

なお、PESkipAtRuleEOF については "Unknows~" を "未知の～" とか "不明な～" というのは直訳丸出しであまり気持ちよくないことから、更にエラーが生成される条件などをコードを調べて、

Code:

PESkipAtRuleEOF=無視される @ルール部の終わり

のようにしているのが現在の JLP です(Unicode エスケープでエンコードされているので LXR で見ても意味分かりませんが)。

今回は言語リソースの定義からその使用箇所を探しましたが、画面上の UI 文字列からその定義としよう箇所を探すには、まず UI 文字列を言語リソースから検索してから上記と同じような手順で XUL 等の箇所を探すことになります。
因みに、これについては Firefox Hacks の「77. Firefoxのインターフェイスをカスタマイズする」(の訳者注記)で簡単に説明しています。
Firefox Hack では、こういった雰囲気で(もう少し丁寧に)、102 のネタについて解説しています。来週末には出版される予定ですので、書店で見つけたら取り敢えず立ち読みでもしてみてくださいませ。
# Firefox Hacks の読者には C 言語の知識は要求されません。
# と、ついでに少し宣伝してみるテスト。(笑)