- 追加された行はこの色です。
- 削除された行はこの色です。
ｆ[[FireVox]]にもどる
#freeze
[[FireVox]]にもどる
このコンテンツは現在執筆中です。
* 目次 [#o870cb0c]
#contents
* 目的 [#x6e30939]
FireVoxを日本語化したときの工程や、資料をまとめます。
日本語ロケールファイルを付け加える作業だけではなく、
ローカリゼーション機構のない拡張にlocalフォルダを作り多言語対応にする方法です。
一からローカリゼーション対応の拡張を作るときにも役に立つでしょう。
なお、この文書はWindows上での作業をまとめたものです。
これは私がこのようにやったという報告であって、正攻法ではないかもしれません。
実際にやるときは、概略だけを参考にして、自分でスクリプトを書いて自動化したり、いろいろやってみてください。
自分でスクリプトを書いて自動化したり、いろいろやってみてください。
* 参考ページ [#c74ae3a7]
主に以下のサイトを参考にしました。他にも記録していないページを参考。
主に以下のサイトを参考にしました。他にも記録していないページを参考にしています。
ここにあるページの情報を見れば、自分がまとめる必要もないかもしれない。
ここにあるサイトは古い情報が含まれている可能性があります。事実そのために手こずったところもあります。
-Firefoxまとめサイト
--[[拡張の作成:http://firefox.geckodev.org/index.php?%B3%C8%C4%A5%A4%CE%BA%EE%C0%AE]]
-[[How to create Firefox extensions:http://roachfiend.com/archives/2004/12/08/how-to-create-firefox-extensions/]]
上記の原文
-Mozilla Japan
--[[ローカライズセンター:http://www.mozilla-japan.org/jp/l10n/]]
-[[もじふぉ:http://forums.firehacks.org/l10n/index.php]]
日本語化に関する総合フォーラム
--[[拡張の日本語版:http://forums.firehacks.org/l10n/viewtopic.php?t=41&start=0&postdays=0&postorder=asc&highlight=&sid=6243ddc810a4d2c73d13f336ac81d05a]]
--[[ 拡張の日本語化に挑戦したい！？:http://forums.firehacks.org/l10n/viewtopic.php?t=355&start=0&postdays=0&postorder=asc&highlight=&sid=2675915a0faf56621f2234926077ec8c]]
-takanory.net
--[[拡張機能の日本語化:http://takanory.net/firefox/japanize/]]
-[[XULplanet.com:http://www.xulplanet.com/]]
--[[Localization:http://www.xulplanet.com/references/xpcomref/group_Localization.html]]
-[[Creating Applications with Mozilla:http://books.mozdev.org/html/]]
* 準備するソフト [#odffead2]
**UTF8N形式で読み書き可能なエディタ [#rf06da34]
いろいろありますが、フリーで使えておすすめなのは、
-[[サクラエディタ:http://sakura-editor.sourceforge.net/]]
-[[xyzzy:http://www.jsdlab.co.jp/~kamei/]]
両者ともちゃんと検索には正規表現が使えます。
**ユニコードエスケープシーケンスに変換するソフト [#s652af3b]
JDK付属の[[native2ascii:http://java.sun.com/j2se/1.5.0/ja/docs/ja/tooldocs/windows/native2ascii.html]]を使う方法もありますが、読み書き可能なテキストエディタがあります。
-[[プロパティエディタ:http://propedit.sourceforge.jp/]]
jarファイルなので、J2REやJ2SDKが必要です。詳しくは上記のリンク。
**ZIP形式対応の解凍圧縮ソフト [#gc5c93c6]
いろいろありますが、
-[[7-zip:http://www.7-zip.org/ja/]]
この文書の中にある圧縮解凍のバッチファイルは、この7-ZIPを前提に書かれています。
* パッケージの展開 [#i03a14cc]
拡張機能のファイルはxpiという拡張子の付いたファイルですが、実はこれはいくつかのファイルをZIP形式で圧縮したものです。展開することで内容を見ることができます。
ZIPが解凍できるソフトならば何でもいいのですが、Windowsで7-ZIPをインストールしてあり、パスの通っているところに7z.exeがあることを前提ですすめます。
マイドキュメント内などに作業フォルダを決め、そこに拡張名のフォルダを作ります。そこに展開したい拡張機能を置き、右クリックメニューのExtract Hereコマンドを実行します。するとinstall.rdfファイルとchromeフォルダなどが解凍されます。
chromeフォルダの中を見ると、拡張機能名に拡張子jarがついたファイルが見つかります。
このJARファイルも、複数のファイルを集めてZIPでまとめたファイルです。
同じように右クリックでメニューを出し、Extract Hereコマンドで展開します。このJARファイルは解凍が終われば削除してもかまいません。
解凍後content
フォルダなどが現れるはずです。このときlocaleフォルダも見つかれば、この拡張機能にはローカリゼーションの機能があります。日本語で表示されないならば、日本語化ができていないだけなので、[[ローカライズ>Firefox拡張のローカライズ#ie062245]]を参考にして、日本語化してください。この文書の大部分で説明しようとしているのは、localeフォルダそのものが存在しない場合です。
上記の作業をバッチファイル(extract.bat)で書くと、
7z x "*.xpi"
cd chrome
7z x "*.jar"
del *.jar
cd ..
* ローカリゼーションへの対応 [#d85861c3]
結局これから何をするのかというと、翻訳対象となる文字列をXULファイルとJSファイルから切り出し、その文字列に約束事に従った名前をつけ、その名前と文字列との対応表を作ります。簡単にいうとそういうことです。
この対応表を別の言語用を用意することで、ローカリゼーションができるようになるわけです。
** パッケージのローカリゼーション対応 [#g6009011]
ローカリゼーションを実現するために、拡張機能のパッケージにいくつかの新しいファイルやフォルダを追加し、既にあるファイルにいくつかの記述を追加していく必要があります。
*** フォルダの構成 [#z78b5a5e]
XULファイルとJSファイルから切り離した文字列を格納するためのフォルダを作ります。
localフォルダはchromeフォルダ内に作ります。そしてその中にその言語のロケール名のフォルダを作ります。ここにその言語の文字列ファイルを置きます。ここに置かずにさらにこの中に拡張名のフォルダを作りその中に置く流儀もあるようです。
例えば、英語ロケールを作る場合
chrome/locale/en-US/
というフォルダを作り、その中に文字列ファイルを置きます。
別な流儀だと、拡張機能hogeとすると、
chrome/locale/en-US/hoge
となります。
*** install.rdfの記述 [#nbe6b58b]
*** フォルダの構成 [#z78b5a5e]
これはパッケージの構成を記述してあるファイルです。firefoxの拡張機能マネージャーは、このファイルの記述を利用して、自動的に拡張機能を組み込んでいきます。なおこのファイルはXMLで書かれています。
このファイルにはロケール要素を追加します。追加する場所は、em:file要素のjarファイルを指定しているDescription要素内です。追加する行は、その言語の文字列を納めたファイルが置かれるフォルダをem:localeタグで挟んだものになります。
拡張機能hogeに、chromeフォルダからの相対位置locale/en-USのフォルダに英語の文字列情報を置くときは、
<em:file>
<Description about="urn:mozilla:extension:file:hoge.jar">
<em:locale>locale/en-US/</em:locale>
</Description>
</em:file>
となります。
いろいろ拡張機能の内部を見てみましたが、どういう理由か分かりませんが、中にはinstall.rdf内の構造が違うものもありました。その場合はその構造に合わせてください。
*** contents.rdf [#w2742035]
パッケージ内のファイルがあるフォルダには、contens.rdfファイルを用意する必要があります。新しくlocaleフォルダを作ったので、この中にもcontents.rdfファイルを作らないといけません。なおlocaleフォルダに直に置くのではなく、各ロケールのファイルの置いてあるフォルダに置きます。
ロケールフォルダに入れるcontents.rdfのテンプレートは次の通りです。
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:chrome="http://www.mozilla.org/rdf/chrome#">
<RDF:Seq about="urn:mozilla:locale:root">
<RDF:li resource="urn:mozilla:locale:en-US"/>
</RDF:Seq>
<RDF:Description about="urn:mozilla:locale:en-US"
chrome:displayName="My Application"
chrome:author="name"
chrome:name="en-US">
<chrome:packages>
<RDF:Seq about="urn:mozilla:locale:en-US:packages">
<RDF:li resource="urn:mozilla:locale:en-US:myapplication"/>
</RDF:Seq>
</chrome:packages>
</RDF:Description>
</RDF:RDF>
上記の、My Application、name、myapplicationと書かれている部分を、拡張に合わせて書き換えます。
また違う言語を対象とする場合は上記のen-USの部分を置き換えます。
なお、このファイルに非ASCII文字が含まれる場合はUTF8形式で保存します。chrome:displayNameの値が非ASCII文字列になる可能性があります。
** XULのローカリゼーション対応 [#b570dcd9]
拡張機能のユーザーインターフェイス部分、つまりメニューの項目やウィンドウ上のボタンの配置、そして処理の指定など、そういうものを記述してあるのが、XULファイルです。
このXULファイルには、ウィンドウのラベルやメニューの項目など、翻訳の対象となる文字列があります。
*** XULファイル中の翻訳箇所 [#i1826ed8]
このファイルはXMLで書かれています。
ウィンドウ上の言葉や、メニューの項目名がどのような形でXULファイル上に記載されているかは、XML言語の文法、XUL言語の要素や属性についての知識が必要になってきます。
翻訳の可能性があるのは、次の箇所です。
-要素の label 属性
-要素の accesskey 属性
-window 要素の title 属性
-label 要素の value 属性
-textbox 要素の value 属性
-description 要素の内容
-html 要素が使用できるなら適宜その内容もしくは属性
accesskey 属性は、日本語においては英語のものを訳に関係なくそのまま利用していますが、ヨーロッパの言語などでは、訳に伴い置き換えられる可能性がありますので、置き換え可能な対象にしておく必要があります。
上記の属性を眺めてみて、翻訳の必要なものを探していきます。
そしてその文字列をDTDファイルに記述していきます。
*** DTDファイルの作成 [#gdb76ad2]
DTDは日本語で文書型定義と呼ばれるもので、XMLでの要素や属性を定義しているファイルです。詳しくはXMLの入門書などを参考にしてもらうとして、ここではXULファイルで使われる文字列を定義するファイルとして使われています。
DTDファイルはlocaleフォルダ内に作成します。install.rdfで記述されているその言語のロケール指定の階層にファイルを作ります。
次の記述がinstall.rdfファイル内にあるならば、
<em:locale>locale/en-US/</em:locale>
この場合は、localeフォルダ内のen-USフォルダに作ります。
次の場合ならば、
<em:locale>locale/en-US/hoge/</em:locale>
localeフォルダ内のen-USフォルダのhogeフォルダに作ります。
DTDファイルの名前はその拡張の名前に、".dtd"を付けたものが分かりやすいでしょう。
XULファイルが複数あるときはXULファイルに合わせ分割する方法もわかりやすいでしょう。
なお、DTDファイルは、非ASCII文字列を含む場合、UTF-8形式を指定して保存します。
なお、DTDファイルは、非ASCII文字列を含む場合、UTF-8N形式を指定して保存します。
DTDファイルを作成したら、その内容を参照するXULファイル内には DOCUTYPE宣言を追加しておきます。
拡張foo で foo.dtd というDTDファイルを指定する場合、
<!DOCTYPE hoge SYSTEM "chrome://foo/locale/foo.dtd">
のようになります。hogeの文書タイプ名には、このあとに記述される window, overlay, dialog, wizard 要素名のどれかがきます。
<!DOCTYPE window SYSTEM "chrome://foo/locale/foo.dtd">
のようになります。上記の文書タイプ名は、その後に記述されるトップレベル要素です。windowの他に、overlay, dialog, wizard となるかもしれません。
*** DTDファイルの記述と、XULファイルの修正 [#jbbb1fb5]
各翻訳対象の文字列は、次の実体宣言形式で書いていきます。
<!ENTITY 名前 "文字列">
文字列が実際に表示される文字列そのもので、名前がその文字列を参照するための名前です。この文字列の部分を別の言語に翻訳したDTDファイルを用意することで、ウィンドウやメニューに現れる言葉を各言語に対応させていくことができます。
ここで宣言された名前をXULファイル中で参照するには、その名前を &と;で挟んで指定します。
DTDファイルで次のように定義された場合、
<!ENTITY hoge "click me">
XULファイル内のとある部分では、次のように参照できます。
<button label="&hoge;"/>
このENTITY名には、'.'を入れた記法が使えるので、拡張名、XUL要素名、要素のidなどを組み合わせて、わかりやすい一意の名前を付けていきます。
このENTITY名には、'.'を入れたドット記法が使えるので、拡張名、XUL要素名、要素のidなどを組み合わせて、わかりやすい一意の名前を付けていきます。
このようにして、XULファイルをローカリゼーション対応にします。
** Javascriptのローカリゼーション対応 [#f08a5c51]
拡張の動作内容を記述しているのがJS拡張子を持つJavascriptファイルです。このJavascriptで出力される文字列もローカリゼーションの対象となります。
作業の対象は、以下の３種類のファイルです。
-XULファイル
-JSファイル
-PROPERTIESファイル
おおまかな手順は次の通りです。
-localeフォルダに、PROPERTIESファイルを作成する。
-対象となるJavascriptを呼び出しているXULファイルにPROPERTIESファイルを登録する。
-Javascript内の文字列を見渡し、翻訳の対象とすべき文字列がどれかを調べる。
-翻訳対象の文字列に英数字で名前をつけ、それをPROPERTIESファイルに後述の書式に従って、その名前と文字列との対応表を作る。
-JSファイル内の文字列をPROPERTIESファイルの文字列を参照する形式に置き換える。
それでは、細かな手順を示します。
*** PROPERTIESファイルはどこに作るのか。 [#k5f3ea78]
PROPERTIESファイルはlocaleフォルダ内に作ります。これはJavascript内で記述されている文字列の言語のロケールフォルダ内です。例えば英語で記述してありメッセージが英語で出力されるプログラムを作業の対象にする場合は英語ロケールとなり、その言語のinstall.rdfで記述しているロケール指定の階層にファイルを作ります。
例えば、以下のような記述がinstall.rdfファイル内にあるとき、
<em:locale>locale/en-US/</em:locale>
この場合は、localeフォルダ内のen-USフォルダに作ります。次の場合は、
<em:locale>locale/en-US/hoge/</em:locale>
localeフォルダ内のen-USフォルダ内のhogeフォルダ内に作ります。
*** PROPERTIESファイルに名前を付ける。 [#wb34d6c9]
名前は任意ですが、その拡張機能の名前にしたほうがわかりやすいでしょう。そして拡張子にpropertiesを付けます。
例えば、拡張機能hogeを作っているときは、hoge.properites とします。
またXULファイル毎にPROPERTIESファイルを用意したり、わかりやすいように複数に分類してもかまわないでしょう。
*** XULファイルへ登録する。 [#f20a8266]
PROPERTIESファイルの登録はそれが使われるXULファイル内で、stringbundleset要素とstringbundle要素を使って登録します。
以下のように登録することで、Javascriptのプログラム内からPROPERTIESファイルの内容を参照することができるようになります。
利用するPROPERTIESファイル毎にわかりやすい任意のidを決めてstringbundle要素を作ります。
例えば、idがhoge-bundle、PROPERTIESファイルがhoge.propertiesのときは、
<stringbundle id="hoge-bundle" src="chrome://hoge/locale/hoge.properties"/>
となります。
これを、PROPERTIESファイルの数だけ用意して（通常は一つでOK）、全体をstringbundleset要素で囲みます。このstringbundleset要素にも任意のid属性を指定しておきます。
<stringbundleset id="hoge-bundle-set">
<stringbundle id="hoge-bundle" src="chrome://hoge/locale/hoge.properties"/>
</stringbundleset>
*** どの文字列を翻訳対象にするか。 [#z25063be]
Javascriptの書かれているjsファイル内から、文字列の部分を探し出します。これにはJavascriptの文法が分かっていなくてはいけません。また文字列をすべて抜き出してしまえばいいというものでもありません。表示もしくは音声による出力に関連するものや、外部からの入力に対するものなど、プログラムの動作を詳しく分析しながら、判断していきます。
このとき便利なのは、Javascriptの構文を認識し着色してくれるエディタですね。文字列部分を容易に見つけ出せます。もしくは検索で該当箇所を着色してくれる機能があるエディタです。検索には次のような正規表現を使えばいいでしょう。
("[^"]*"|'[^']*')
*** PROPERTIESファイルの書き方 [#l3b4882e]
XULファイル内で呼び出されているJavascriptファイルに対して、一つずつ翻訳対象の文字列がないか調べていきます。見つかったら、その情報を先ほどXULファイルに登録したPROPERTIESファイルに、記述していきます。
記述の仕方ですが、文字列を見つけたらそれを指し示す名前を決めます。万人のために英語的な名前にします。この名前の後に'='記号を置いて、さらにその文字列そのものを置きます。文字列を囲む引用符はいりません。
例えば、"Hello,World!"という文字列が見つかったら、PROPERTIESファイルに、
HelloWorld=Hello,World!
という行を追加します。
既に同じ文字列を示しているものがある場合は追加する必要はありません。ただし、同じ文字列だからといって、同じ意味で使われていないこともあります。
文字列の名前はそのXULファイルに登録してある複数のPROPERTIESファイル間で重複がないように決めていきます。
さて、このときの各行の細かな記法ですが（mozillaのコードを読んだわけでなく経験則です）、
左辺=右辺
とおくと、
左辺は
-行頭以降で空白以外の文字から始まり、=の左側で空白以外の文字で終わる文字列です。
-この文字列の内部（文字列の最初、最後以外）に空白を含むことができます。
-この文字列に=を含むことはできません。
-この文字列にエスケープコードを含むことはできません。
-左辺がない場合（=が行頭、もしくは左側に空白文字以外無いとき）は、左辺は""と見なされます。
右辺は、
-=以降で空白以外の文字から始まり、空白を含んでもよく、空白以外の文字で終わる文字列です。
-この文字列の内部（文字列の最初、最後以外）に空白を含むことができます。
-この文字列には=を含むことができます。
-行末に\がこない場合は、行末が終端になります。
-行末に\がくる場合は次の行へ継続します。継続されるのは先頭の空白以外の文字からとなります。
-この文字列にはエスケープコードを含むことができます。
-右辺が無い場合、右辺は""と見なされます。
コメント行も作ることができます。
コメント行
-継続されていない行の、行頭（もしくは行頭のいくつかの空白文字のあと）に#のある行はコメント行になります。
-それ以外の場所の#は文字と見なされます。
-コメント行の行末に\を置いても、次の行に継続はされません。
右辺の文字列には変換指定を含むことができます。オリジナルのJSファイルで文字列の足し算を使って処理している部分などをこれを使って表現します。
*** PROPERTIESファイル内の変換指定について [#a5babf10]
文字列中に含むことができる変換指定は、%S です。%dや%xなども用意されているようですが、思い通りの値は出力されないようです。
%S は、文字列の式の値も、数値の式の値も表示してくれますので、実用上問題ないでしょう。なお小文字sを使った %s は最初の一文字だけを表示しました。
翻訳をする上で問題となるのは、語順の問題です。
原文と同じパラメータの順序で文章を作ることはできなくもありませんが、素直な翻訳文を作るためにはパラメータの順序を変えたいなという場面も多々あります。
そんなときは、%とSとの間に「数値$」を入れ、何番目のパラメータを対象にするのかを指定します。
%S, %S
は
%1$S, %2$S
と同じです。
これの逆に並べたものは、
%2$S, %1$S
となります。
変換指定ではありませんが、mozillaのソース内で見つけたgetStringメソッドを用いた手法があります。それは、PROPERTIESファイルの右辺文字列中に%title%というふうな部分を作っておき、Javascriptのソースの方でそれをgetStringで取り込んだ後、文字列のreplaceメソッドを使って置き換えて使用する方法です。
例えば、プロパティ定義ファイルで
title=新規ファイル
message=%title%を作りました。
と定義して、Javascriptファイルで次のように使います。
var ttl = document.getElementById("foo").getString("title");
var mes = document.getElementById("foo").getString("message").replace(/%title%/,ttl);
プロパティ定義ファイルで何度も出てくる文字列に名前を付け定数化したり、いろんな応用法が考えられます。
プロパティ定義ファイルで何度も出てくる文字列に名前を付け定数化したり、いろんな応用が考えられます。
*** PROPERTIESファイルでの漢字等非ASCII文字の保存形式 [#z93e9f54]
現在、この手順は英語のプログラムの改造を書いているので問題はないのですが、
日本語のプログラムなど非ASCII文字の言語をローカリゼーション対応にしているときは、PROPERTIESファイルの保存形式が問題になってきます。
PROPERTIESファイル内の文字には非ASCII文字は使えません。
では、どうやってASCII文字列だけを使いながら、非ASCII文字列を表示するのかというと、
ユニコードエスケープシーケンスという表記法を使います。各文字に割り当てられた文字コードを直接表記していく方法です。
例えば
文書
は
\u6587\u66F8
となります。
ではこの変換はどうするのか、対応表を手に入れて手作業で置き換えるのは大変です。これには、RsoureceEditorというJavaで書かれたエディタを使うと便利です。保存するときにASCII（UNICODE\uxxxx）を選べば、この形式で保存できます。
再び編集するときも、ちゃんとした文字の形に自動的に変換して見せてくれるので、人間はまったくこの変換に気をつかう必要はありません。
*** JSファイルの文字列を置き換える。 [#m9d33417]
PROPERTIESファイルに文字列の対応リストができたら、この文字列を参照するようにJSファイルの内容を書き換えていきます。
注意：この作業はJavascriptの内容を直接書き換えていくので、より慎重におこなってください。引用符を消し間違えただけで、この拡張機能は使い物にならなくなってしまいます。一度に多くの文字列を書き換えずに、少しずつ動作を確認しながら、おこなった方が賢明です。
単純な文字列の場合と、文字列や数値のパラメータを実行時に組み込む文字列の場合があります。
***まず、単純な文字列の場合 [#ac8394b1]
getStringメソッドを使います。このメソッドは文字列を引数としてとり、stringbundle内から名前としてさがし、対応する値を文字列で返します。
stringbundleを特定するためにgetElementByIdメソッドを利用して、次のような式になります。
document.getElementById("foo").getString("bar")
stringbundleのidがfooで、PROPERTIESリスト内の要素名がbarであるときの例です。
これを対象の文字列と置き換えていきます。
PROPERTIESリスト内で次のように名前と文字列が対応しているとき、
bar=Hello,World！
そしてオリジナルのコードが次のとき、
shout("Hello,World！")
書き換え後はこのようになります。
shout( document.getElementById("foo").getString("bar") );
同じ文字列が繰り返し現れるときなどは、エディタについている確認付きの置換コマンドを利用したりしながら、丁寧にやっていきます。しかし一文字違っただけでプログラムは動かなくなったり望んでいる動作ができなくなりますので、とにかく慎重にします。
また、行が長くなるので、document.getElementById("foo")を大域変数に代入しておき、それを活用するなど適宜自分のスタイルに書き換えてください。
***パラメータ付き文字列の場合 [#l7b87d10]
パラメータ付きの文字列の場合、メソッドgetFormattedString利用します。配置の仕方はgetStringと同じで、対象の文字列と置き換えるのですが、引数が一つ多くなります。第二引数に文字列に対するパラメータの配列がきます。パラメータは文字列もしくは数値をとることができます。
***変換指定付き文字列の場合 [#l7b87d10]
変換指定付きの文字列の場合、メソッドgetFormattedString利用します。配置の仕方はgetStringと同じで、対象の文字列と置き換えるのですが、引数が一つ多くなります。第二引数に文字列に対するパラメータの配列がきます。パラメータは文字列もしくは数値をとることができます。
PROPERTIESファイルにおいて
message = %S means %S.
JSファイルにおいて次のように用います。
var number = 3;
var word = "three";
shout( document.getElementById("foo").getFormattedString("message",[number,word]) );
*** プログラムの変更 [#jfd6a860]
プログラムによっては文字列の置き換えだけでは対応しきれない場合もあるかもしれません。その場合はロケールで条件分岐できるようにプログラムを作りかえて対処します。しかしこの方法だと新たにロケールを追加する毎に、プログラムを書き換えていかなくてはいけないので、あまりおすすめはできません。
PROPERTIESファイルの項目に、ロケールを表す文字列をフラグとして定義することで、簡易的に現在のロケールを獲得できます。
以上のようにローカリゼーション対応が済んだら、パッケージをまとめて一つのXPIファイルを作ります。
すでに一つのオリジナル言語ではローカライズが済んでいますが、必要に応じて下の方法によりローカライズしてください。
* ローカライズ [#ie062245]
以上の手順でローカリゼーション対応の機能拡張パッケージを作成できたら、翻訳したい言語（今回は当然日本語）で、ローカライズをしていきます。
以上の手順でローカリゼーション対応の機能拡張パッケージを作成できたら、翻訳したい言語で、ローカライズをしていきます。
何をなすべきかが分かっていれば、上記のローカリゼーション対応作業の中で同時並行で、以下の作業をおこなってもかまいません。
**install.rdfへの追加 [#jcd283b4]
**ロケールフォルダの作成 [#a5c56de7]
**DTDファイルの作成 [#x55735a1]
**PROPERTIESファイルの作成 [#w6d33fa5]
* パッケージの仕方 [#be313edc]
既にen-USロケールが用意されており、新たにja-JPロケールを追加していく例を示します。
**install.rdfの修正 [#o5865140]
既に英語のロケールが用意されているはずなので、その行をコピーして次の行に貼り付けます。そしてen-USのところをja-JPで置き換えます。
このようになっているとき、
<em:file>
<Description about="urn:mozilla:extension:file:hoge.jar">
<em:locale>locale/en-US/</em:locale>
</Description>
</em:file>
次のように行を追加します。
<em:file>
<Description about="urn:mozilla:extension:file:hoge.jar">
<em:locale>locale/en-US/</em:locale>
<em:locale>locale/ja-JP/</em:locale>
</Description>
</em:file>
そのほか、完全に日本語専用にするならば、em:description要素の内容を日本語に翻訳します。同様な翻訳は、contents.rdfファイル内のchrome:displayName、chrome:description属性の値に対してもおこないます。
**ロケールフォルダの作成 [#j0b0ab1c]
localeフォルダを開き、その中にあるen-USというフォルダをコピーし、それにja-JPという名前を付けます。
**DTDファイルの翻訳 [#w0fc494d]
ja-JPフォルダの中には英語で書かれたDTDという拡張子を持つファイルがあるはずです。このファイルを日本語化します。
このファイルの各行は、
<!ENTITY 名前 "文字列">
という形式をしています。
この文字列の部分を翻訳していきます。
そしてこのファイルをUTF8N形式で保存します。
**PROPERTIESファイルの翻訳 [#jb03c142]
ja-JPフォルダの中にはproperties拡張子を持ったファイルもあるでしょう。
これはJavascript内で使用する翻訳対象の文字列のリストです。
各行は次のような形式で書かれています。
「文字列名」=「文字列」
この文字列の部分を翻訳していきます。
文字列中に%Sがあるときは、プログラム側でパラメータを渡しそれをその場所に文字列として表示するものです。このとき、2つ以上の%Sがあって、日本語に翻訳するとどうしてもパラメータの順序を変えないといけないときは、%2$S、%1$Sのようなパラメータの番号を指定して使います。
このファイルは保存の時に注意があります。非ASCII文字列はユニコードエスケープシーケンス(\uxxxx)で表現しなくてはいけません。そのため、普通にファイルを作り変換するフィルタを通すか、最初からRsoureceEditorなど記録形式にユニコードエスケープシーケンスが選べるエディタを使って編集します。
* XPIファイルの作り方 [#h7a632ef]
以上の作業が終わったら、それを一つのXPIファイルにします。
これには、[[How to create Firefox extensions:http://roachfiend.com/archives/2004/12/08/how-to-create-firefox-extensions/]]で紹介されているバッチファイルを利用します。
ただし、このバッチファイルを利用するには7-zipがインストールされ、パスが通っている必要があります。
set v=「バージョンなどの記述」
set x=%cd%
md build\chrome
cd chrome
7z a -tzip "%x%.jar" * -r -mx=0
move "%x%.jar" ..\build\chrome
cd ..
if not exist components\*.* goto skip
md build\components
copy components\*.* build\components
:skip
copy install.* build
cd build
7z a -tzip "%x%%v%.xpi" * -r -mx=9
move "%x%%v%.xpi" ..\
cd ..
rd build /s/q
このスクリプトにはバージョン情報が付け加えられるようにちょっと変更してあります。
この内容で新しいファイルを作り、build.batという名前を付けて保存します。
保存先は、install.rdfがある場所にします。
このbuild.batをダブルクリックするとXPIファイルが自動的に作られます。
これで新しいロケールに対応した拡張機能の完成です。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
