このサイトの記事更新は2019年11月に終了されました。過去記事アーカイブを公開しています。

投稿されたすべてのトピック

DomainTab version 0.1.4 公開

皆様こんにちは。私は yasusato といいます。

私の作った Firefox の拡張機能 DomainTab が version 0.1.4 になりましたので、この場を借りて宣伝をさせていただきます。

DomainTab は選択したリンクのリンク先がリンク元のサイトと異なるドメインのサイトの時に、新しいタブを開いて表示します。単機能アドオンなので、リンク先が別ドメインの場合に新しいタブで開くという機能を得るために使用しない他の機能をインストールする必要がありません。さらに、単機能でありながら、ステータスバーへのアイコンの表示 / 非表示、新しいタブを前面に表示するかどうかという細かい設定ができるので、各ユーザのブラウジングスタイルに合わせてお使いいただけると思います。

今回のバージョンアップでは、locale ファイルを追加した（hu-HU, mk-MK, sr-RS, tr-TR, zh-CN）だけですが、興味をもたれた方がいらっしゃいましたら、ぜひ使っていただけたらと思います。

https://addons.mozilla.org/ja/firefox/addon/13906

それでは、失礼しました。

投稿者

yasusato

投稿日時

拡張機能開発テクニック

このページでは拡張機能開発の Tips やツールなどの情報を集めています。

このサイトの殆どのページは誰でも自由に編集できます。他にもいい記事があればいわゆる「まとめサイト」の感覚で皆さんどんどん編集していってください。

note: Firefox 4 に向けた拡張機能開発情報はこちらのページでまとめています

拡張機能開発の基本ツール

デバッグテクニック

サンプルコード集

  • MDC – Code snippets
    • MDC には拡張機能などで利用できるコードサンプル集ページが用意されています。
  • jslibs – JavascriptTips
    • JavaScript 一般の Tips としては jslibs の Tips 集ページのコードが参考になります。

開発 Tips/Hacks

modest の投稿記事

投稿者

dynamis

投稿日時

Jetpack Tips

自分の Jetpack Feature の変更をすばやく反映させる方法

まず、自分の Feature をローカルファイルとしてインストールします。(Feature インストール html ファイルをドラッグ＆ドロップすれば良いです。)次に about:jetpack ページの Installed Features を開いてください。該当する Feature の横に refresh というリンクがあります。Feature Javascript を変更したあとこのボタンを押せば、その変更が反映されます。ただし、この機能が有効なのは、該当 Feature をローカルからインストールした場合に限ります( URLが file: でスタート)。

alert を出したい

jetpack 名前空間内には  alert 関数はありません。そこで、以下のように、現在表示中の contentWindow の alert を利用します。

jetpack.tabs.focused.contentWindow.alert("何か");

jetpack.storage.simple の実体のありか

profileディレクトリ/jetpack/xxxxxxxxxxxx/storage/simple.json がそれです。
※xxxxxxxxxxxx は、各 Jetpack Feature のユニークな識別子です。

投稿者

dadaa

投稿日時

ファイル名規則

ローカライズセンターで公開する Mozilla 製品の日本語版や JLP のファイル名は mozilla.org の規定するファイル名規則(bug 257117) をベースに、必要な独自項目を追加したものに従っています。ここではそのファイル名規則について解説します。

原則

ローカライズセンターで公開するパッケージのファイル名は mozilla.org のものに合わせることを原則としています。

現在 mozilla.org のファイル名が自身の規定するものに従っていないため多少混乱しておりますが、ローカライズセンターの開発リリースでは全て次に説明するファイル名規則を使用し、公式リリースについては mozilla.org がそのバージョンで採用しているディレクトリ構造およびファイル名に合わせます。

なお、ファイル名規則に従っていない件について MLP スタッフに問い合わせたところ、Firefox や Thunderbird についてはその開発担当者達の判断により公式リリースのみ簡単で短いファイル名とされているとのことです。英語版の Mozilla Suite については単にビルドスクリプトのコードを誰も修正していないために旧ファイル名規則のままリリースされているということです。残念ながら英語版の Mozilla Suite だけは旧ファイル名規則のまま放置されるようです。(^^;

詳細

ローカライズセンターで公開するパッケージに使用するファイル名規則は次のようになります。但しテスト用のファイルや修正パッチ、あるいは独自に用意しているツールなどについてはこの限りではありません。

appname-version[-buildid].langcode.platform[-special][.type][-contributor][-revision][.misc].extension

ドットやハイフンが何を区切っているのかなどの規則性がやや不明瞭ですが、バージョン番号の中で使用されているのを例外として、ドット区切りの基本構成単位をハイフンで更に細かく分けるという感じです。多分。(^^;

appname

appname ではアプリケーションの名前を小文字だけで表記します。この中にドットやハイフンを含めてはなりません。

  • firefox
  • thunderbird
  • mozilla
  • seamonkey
  • xulrunner
  • sunbird
  • venkman
  • inspector
  • Firefox (大文字不可)

version

バージョン番号はドット区切りで表現されます。各部分は 1 つ以上の数字で始まる必要があります。なお、通例 Mozilla 製品のバージョン番号は 4 つの部分からなり、それぞれ次のようになっています。

major.minor[.micro[.build]][stage]

  • 1.0
  • 1.0PR
  • 1.7.5
  • 1.8a
  • 1.8a5
  • 0.9.24b.7
  • 1.5.a (数字で始まっていない)

buildid

これはローカライズセンターの独自項目です。

言語パックなどを除くすべての Nightly 対応開発リリースと多くの公式リリース候補に付加します。ビルドは一日に複数回作成されることもあるため、ビルド日付ではなく、一律ビルドID を付加します。

  • -1982030303
  • -2005031323
  • -2010010100
  • -19820303 (日付のみは廃止)
  • .1982030303 (ドットでなくハイフン)

langcode

langcode は言語コードと国コードの 2 つの部分からなります。これは rfc 2070 で規定されているものになります。複数の言語リソースを含むパッケージについてはこれは省略されるというのが mozilla.org のファイル名規則ですが、英語と日本語だけを含めているパッケージについてはそれと分かり易いように en-US+ja のように表すことがあります。

Firefox/Thunderbird 1.0.x の Mac OS X 用言語リソースでは、rfc には違反しますが諸般の事情により国コード部に JPM を使用していました。Firefox/Thunderbird 1.5 以降では rfc 3066 の dialect を用いて ja-JP-mac とすることになりました。

  • ja
  • ja-JP-mac
  • en-US
  • fr
  • en-US+ja
  • ja-JP
  • ja-JPM
  • fr-FR
  • chr-US

platform

バイナリパッケージが依存するオペレーティングシステム、プロセッサー、ツールキットなどを表します。プラットフォームに依存しないパッケージではこのフィールドは省略します。通常、このフィールドは autoconf で $(TARGET_OS)-$(TARGET_CPU) として取得する値になりますが、一部の値は規定であるとして省略されます。

  1. Windows プラットフォームのパッケージは “win32″ とします。 64ビット Windows では “win64″ となる予定(？)
  2. Macintosh (OSX) プラットフォームのパッケージでは “mac” とします。
  3. “linux-gnu” は単に “linux” とだけ表記します。

special

ライブラリなどが非標準のビルドについてはそれを special として付記します。

  1. Linux プラットフォームでは GTK2 が標準のツールキットです。 GTK 用のバイナリビルドでは “-gtk1″ と明記します。
  2. 以前の標準ビルドでは SVG は無効となっていました。 SVG を有効にしたビルドではそれを区別できるよう -svg-cairo, -svg-libart または -svg-gdiplus を付記していました。
  • win32
  • mac
  • linux-i386
  • win32-svg-gdiplus
  • mac-svg-cairo
  • linux-i686-gtk1
  • linux-i386-gtk1-svg-libart

type

パッケージ種別を表します。バイナリのアーカイブパッケージについてはこれを省略します。

  • installer
  • langpack
  • src

contributor

これはローカライズセンターの独自項目です。

各パッケージの主担当者以外が作った貢献リリースについては、貢献者の名前を英数小文字で入れています。

  • -asa
  • -bsmedberg
  • -dynamis
  • -rebron

revision

これはローカライズセンターの独自項目です。

mozilla.org による同一ビルドに対応する多数の開発リリースなどを用意するため、それを区別するためのリビジョンを最後に付記します。表記規則としては version と同様に最大 4 つの部分からなります。

Firefox/Thunderbird の言語パックではすべてのリリースを通して一意の番号としています。

Firefox/Thunderbird 1.0.x では 4 つの部分のうち JLP のリビジョンに通常 3 つを使用し、最後の部分は同一 JLP に対して複数のパッケージを作成する場合や非標準パッケージを作成するときなどに使用していました。

  • -1
  • -3
  • -1.0rc7
  • -1.0.3
  • -0.7.7
  • -0.6.10

misc

これもローカライズセンターの独自項目です。

同一 revision に対して試験的に設定や構成の異なる複数のパッケージを作成する場合などに、ローカライズセンターで独自に作成した特別なパッケージを区別できるようにします。

英数字だけであれば任意の文字列を使用できますが、これ以外の部分で表現できる場合には使わないでください。例えば fix, fix2… は公式リリースを修正して再リリースした際に明確に区別がつくように付加したもので、通常は単に revision 番号を上げます。

  • test (試験的と強調)
  • fix (修正版と強調)
  • fix2 (更なる修正版と強調)
  • nordf (RDF ファイル無し)
  • noinspector (DOM Inspector 無し)
  • withvenkman (Venkman 同梱)
  • release (今後使用禁止)

extension

ファイル種別を表す拡張子。拡張子だけが異なるパッケージは圧縮方式以外は同一のパッケージになります。

  • firefox-1.0PR.en-US.linux-i386.tar.gz
  • firefox-1.0PR.en-US.linux-i386.tar.bz2
  • firefox-1.0PR.en-US.linux-i386.7z

これらは全て同一のパッケージになります。

注意

開発リリースの名前規則はかなり複雑になっていますので、注意が必要です。以下、注意点を箇条書きします。

  • Firefox/Thunderbird 1.0.6 および Mozilla Suite 1.7.11 以前にはこのファイル名規則に従っていないものが多数あるため、それらは参考になりません。必ずこのページの用例を参考にし、不明な点は事後でも良いので L10N ML で問い合わせてください。
  • 言語パックなどを除く Nightly 対応開発リリースには buildid が必須です。リリース候補と指定された Nightly に対して作成する場合であっても付加します。これによりファイル名が非常に長くなりますが、ベースとなるビルドを明らかにするために必要です。
  • 先に en-US の Final リリースが出てから、それをベースに日本語版の公式リリース候補として作成する場合については、公式リリース候補と強調するために buildid を省略しても構いませんが、リリース候補についてビルド ID を省略するかどうかは製品毎に統一してください。テスト用の特殊なパッケージなどは Final リリースをベースにしている場合でも必ず buildid を付加します。
  • buildid は当初日付までの 8 桁だけとしていましたが、同日中に複数のビルドが作成されることも少なくないため、必ず時刻を含めた 10 桁のビルド ID を使います。
  • revision は必須ではありませんが、複数のパッケージを繰り返し作成する可能性が高い時は最初から -1 などを付加してください。
  • revision の決め方については、全リリースに対して一意につけても、対象バージョン毎に一意につけても構いません。製品毎に一定の規則に従って番号付けを行ってください。
  • misc は特別な修正を施した試験的バージョンなど、明確な意図がある場合にのみ使用してください。設定やファイル構成が異なるもの同時に複数作ってテストする場合などにはこれを使用しますが、単にミスを修正して更新した場合は revision を上げます。
  • ファイル名だけでは Trunk 対応版であるか Branch 対応版であるかは明確にならない期間がありますが、それは mozilla.org 同様パッケージを収めるディレクトリによって区別します。ファイル名に aviary, branch や trunk などといった文字列を含めることはしません。

用例

公式リリースと開発リリースそれぞれのパッケージの正しいファイル名の例です。既存のファイルにはこのファイル名規則に従っていないものが多数ありますので、既存ファイルではなくこれらの(殆どが架空の)用例を参考にしてください。

Firefox 1.0.x Relesease

Firefox 1.0.x 公式リリースのファイル名 (例外)

* Firefox Setup 1.0.5.exe
* firefox-1.0.5.tar.gz
* firefox-1.0.5.installer.tar.gz
* Firefox 1.0.5.dmg
* ja-JP.xpi
* ja-JPM.xpi

Thunderbird 1.0.x Relesease

Thunderbird 1.0.x 公式リリースのファイル名 (例外)

* Thunderbird Setup 1.0.6.exe
* thunderbird-1.0.6.tar.gz
* Thunderbird 1.0.6.dmg
* ja-JP.xpi
* ja-JPM.xpi

Mozilla Suite 1.7.x Relesease

Mozilla Suite 1.7.x 公式リリースのファイル名

* mozilla-1.7.9.ja-JP.win32.installer.exe
* mozilla-1.7.9.ja-JP.win32.zip
* mozilla-1.7.9.ja-JP.linux-i686-gtk1.tar.gz
* mozilla-1.7.9.ja-JP.linux-i686.tar.gz
* mozilla-1.7.9.ja-JP.linux-i686.installer.tar.gz
* mozilla-1.7.9.ja-JP.mac.dmg
* mozilla-1.7.9.ja-JP.langpack.xpi

Firefox 1.5.x Relesease

Firefox 1.5.x 公式リリースのファイル名

* 未定

Thunderbird 1.5.x Relesease

Thunderbird 1.5.x 公式リリースのファイル名

* 未定

Firefox Devlopment Relesease

Firefox 開発リリースのファイル名

* firefox-1.0.5-2005071119.ja-JP.win32.installer.exe
* firefox-1.0.1.ja-JP.langpack-0.8.10.xpi
* firefox-1.0.1.ja-JPM.langpack-0.8.10.xpi
* firefox-1.0+.ja.langpack-1.0.3.xpi
* firefox-1.0+.ja.langpack-1.0.3.1.xpi
* firefox-1.0+.ja.langpack-1.0.4-noinspector.xpi
* firefox-1.0+.ja.langpack-1.0.5-withvenkman.xpi
* firefox-1.0+.ja-JP-mac.langpack-1.0.5.xpi

Thunderbird Devlopment Relesease

Thunderbird 開発リリースのファイル名

* thunderbird-1.0.6-2005071616.ja-JP.win32.installer.exe
* thunderbird-1.0.6-2005071604.ja-JP.linux-i686.tar.gz
* thunderbird-1.0.6-2005071604.ja-JP.linux-i686-test.tar.gz
* thunderbird-1.0.6-2005071605.ja-JPM.mac.dmg
* thunderbird-1.0.2.ja-JP.langpack-0.6.10.1.xpi
* thunderbird-1.0.2.ja-JPM.langpack-0.6.10.1.xpi
* thunderbird-1.0+.ja.langpack-1.0.3.xpi
* thunderbird-1.0+.ja-JP-mac.langpack-1.0.3.xpi

Mozills Suite Devlopment Relesease

Mozilla Suite 開発リリースのファイル名

* mozilla-1.7.9.ja-JP.win32.installer.exe
* mozilla-1.7.9.ja-JP.win32.installer-1.exe
* mozilla-1.7.9.ja-JP.win32.zip
* mozilla-1.7.9.ja-JP.win32-2.zip
* mozilla-1.7.9.ja-JP.linux-i686.installer.tar.gz
* mozilla-1.7.9.ja-JP.linux-i686.installer-3.tar.gz
* mozilla-1.7.9.ja-JP.mac.dmg
* mozilla-1.7.9.ja-JP.mac-4.dmg
* mozilla-1.7.9-2005030300.ja-JP.win32.installer.exe
* mozilla-1.7.9-2005030301.ja-JP.win32.zip
* mozilla-1.7.9-2005030302.ja-JP.linux-i686-gtk1.tar.gz
* mozilla-1.7.9-2005030304.ja-JP.linux-i686.tar.gz
* mozilla-1.7.9-2005030308.ja-JP.linux-i686.installer.tar.gz
* mozilla-1.7.9-2005030316.ja-JP.mac.dmg
* mozilla-1.7.9.ja-JP.langpack-1.xpi
* mozilla-1.7.9.ja-JP.langpack-3.xpi
* mozilla-1.7.9.ja-JP.langpack-dynamis-3.1.xpi

Other Products and Tools

その他のファイル名

* lot-1.0.zip
* lot-1.0rc7.2005081506.zip
* venkman-0.9.85.ja.xpi
* venkman-0.9.85.en-US+ja.xpi
* sunbird-0.2+-2005060708.ja.win32.zip
* sunbird-0.2+-2005060708.ja.linux-i686.tar.gz
* xulrunner-1.9a1-2005080910.ja.win32.zip
* xulrunner-1.9a1-2005080910.ja.linux-i686.tar.gz
* seamonkey-1.0a-2005080706.ja.win32.installer.exe
* seamonkey-1.0a-2005080706.ja.linux-i686.tar.gz

投稿者

dynamis

投稿日時

ガイドライン

ローカライズセンターでは Mozilla 製品が日本語化されたソフトであることを感じさせることなく、日本語で自然に使ってもらえるようにと意識してローカライズを行っています。Mozilla 製品の日本語を統一感のある高品位なものとするため、用語の対訳表などと合わせて日本語化のガイドラインを作成・公開しています。
このガイドラインについてご意見がある場合やガイドラインに反する箇所を見つけた場合は L10N フォーラム までお知らせください。

本ガイドラインは現在草稿段階のものです。随時修正していきますのでご了承ください。

文体と表記規則

ローカライズセンターでは製品全体を通して、自然で柔らかな分かり易い日本語となるように心がけています。そのために文体や表記規則などについて以下のような指針を定めています。

言語差と意訳
  • 英語と日本語の語順や主述の違いに注意して、逐語訳ではなく自然な日本語表現とする。
  • 特に、英語構文に対応した英語直訳特有の言い回しなどは出来る限り避ける。
  • 英語は主語が必須の言語だが日本語は省略する言語であり、余分な主語は遠慮無く削除する。
  • その他英語との日本語との違いによる表現や説明の過不足を適時調整する。
  • 原文の表現が不適切あるいは不明瞭なところは独自表現に変えることも厭わない。
original: Update Succeeded.
bad ex. 更新成功
bad ex. 更新に成功しました。
good ex. 更新を正常に完了しました。
original: You can click on this icon to see which sites Firefox blocked and to allow those sites to open popups if they are required for the site to function correctly.
bad ex. あなたは Firefox がどのサイトでのポップアップをブロックしているか見たり、サイトが正常に機能するためにポップアップが必要とされる場合にそのサイトがポップアップを開くことを許可するためには、このアイコンをクリックすることができます。(問題外(^^;)
bad ex. Firefox がどのサイトでのポップアップをブロックしているか確認したり、正常に機能するために必要なサイトでポップアップを開くことを許可するためには、このアイコンをクリックしてください。(単なる直訳例)
bad ex. どのサイトでのポップアップがブロックされているか確認したり、サイトの閲覧にポップアップが必要なサイトを指定するためには、このアイコンをクリックしてください。(まだ不自然)
good ex. このアイコンをクリックすると、ポップアップが禁止されているサイトを確認したり、必要に応じて特定サイトでのポップアップを許可したりできます。
文体と表現
  • 文体は敬体(ですます調)で統一する。
  • 日本語が堅くならないよう必要以上の漢字は使用しない。
  • 固有名詞や専門用語あるいは慣例的なものを除き英語表記は使用しない。
  • カタカナ語についても同様に、自然な日本語に可能な限り置き換える。
bad ex. Plug-in が Install されているかチェックして下さい。
good ex. プラグインがインストールされているか確認してください。
exception: Web, Cookie, DOM, Find As You Type などは英語表記
コンテクスト
細部の表現については英語との対応に拘ることなく、以下のようにコンテクストに応じて表現を揃えるようにしています。

ウィンドウ
タイトル名は体言止めを原則とする。全体のバランスに注意する。
メニュー項目
OS の慣用表現に従う他は簡潔な体言を基本とする
カテゴリ名
体言止めを原則とし、コロンをつけたり設定項目の説明と続けて文にしたりはしない。
ボタンラベル
動作や目的などを簡潔な体言で表す。可能であれば語数を揃える。
ツールチップ
動作だけでなく目的語も含め、何をどのように処理するのか分かるものとする。
チェックボックス
末尾では体言ではなく動詞を原則とする。コロンと入力欄が続くはこの限りではない。
やむを得ずラベルが複数の文になる場合を除き、句点は使用しない。
ラジオボタン
前後の文脈に注意して簡潔で分かり易い表現とする。末尾の品詞は問わない。 止む終えずラベルが複数の文になる場合を除き、句点は使用しない。
プルダウンメニュー
可能であれば共通部は前後の説明部に表記し、各項目は簡潔で分かり易いものとする。
テキスト
その他の部分のテキストについては文脈判断。文になるところでは句点を使用する。
英数記号と全角半角
  • 英数字や記号を使用する場合は特別な理由のない限り半角を使用する。
  • 日本語文中での句読点および疑問符や感嘆符については全角記号を使用する。
  • 英数字と日本語との間には半角空白を入れることを原則とする。
  • 記号と日本語の間については文脈や記号に合わせて空白の有無を決める。
  • メニュー項目やボタンラベルなどを表すときは二重引用符を使用する。
  • 全角空白および半角カナは使用しない。
bad ex. Firefox　は Mozillaプロジェクト（mozilla.org）による次世代Ｗｅｂブラウザです!
good ex. Firefox は Mozilla プロジェクト(mozilla.org) による次世代 Web ブラウザです！
類似表現とかな漢字
  • 本動詞では文脈に応じて漢字、補助動詞についてはひらがなとする。
  • “すべて” はすべてひらがなとする。
  • “～することが～” はひらがなとする。
  • “～することができます” はなるべく “～できます” と簡潔にする。
  • 条件節で用いる “～するとき” はひらがな、”～する場合” は漢字とする。
  • “～するとき” と “～する場合” は時間的か条件的かである程度使い分ける。
  • 限定を表す副助詞 “～のみ” と “～だけ” は順に文語調、口語調である程度使い分ける。
  • 訳語の選択については訳語の選択基準として後述する。
  • その他表現に揺れのあるところは順次検討して使い分けの明確化や統一を行う。
カタカナ語と長音
残 念ながらカタカナ語に於ける発音表記や長音の扱いには明確かつ適切な判断基準というものは存在しませんが、製品内での用語統一は必須であるためローカライ ズセンターでは以下のような表記で統一しています。概してコンピュータ関係の用語は仕様書などで多く使用される慣例に従って長音を使用しないことが多いで す。

ブラウザ、メーラ、ユーザ、サーバ、コンピュータ、プロバイダ、プロキシ、マネージャ、インスペクタ、デバッガ、フォルダ、ディレクトリ、フィルタ、ヘッダ、プレーン、ビュー

その他
  • OS によって訳語の異なるものはそれに応じて訳し分ける。
  • 初心者の目にするところは特に説明的に分かり易く心がける。
  • 可能な限り技術的に正確で正しい表現となるよう心がける。

訳語の選択基準

特別な知識のない人でもヘルプを参照したりすることなく自然に利用できるソフトウェア。ローカライズセンターではこれを目指して Mozilla 製品のローカライズに取り組んでおります。
そのため、固有名詞や技術的な用語として用いられる場合を除き英語表記は使用しません。カタカナ語についてもそれが既に広く認知されているものや日本語に 適切なものがない場合以外、日本語を用いて表すことにしています。また、技術的で知らない人に分かりにくい用語については一部説明的・補足的な訳語とする ようにしています。

実際の語句については個別に検討していくことになりますのでここに明確な基準を書くことは出来ません。その代わりといっては何ですが、代表的な用語についてはL10N 指定訳語一覧を公開しておりますので参考にしてください。

投稿者

dynamis

投稿日時

よくある質問

このページは準備中です。

日本語化に協力したいんだけど、どうすればいいの？

ありがとうございます。普段使っていて気づいたところを報告するなど簡単なところから、日本語化にはいろいろなスタイルでご参加頂けます。まずは「参加するには」ページをご覧ください。

日本語化の問題を見つけたら、何処に報告すればいいの？

日本語版を使っていてお気づきの点があれば、L10N フォーラム (ユーザ登録不要)にお知らせください。

その他のフィードバック方法については「フィードバックするには」ページをご覧ください。

Aurora, Nightly って何？

Firefox 開発版 (プレビューリリース) の開発チャンネル名です。製品版 (Release)になる前は Beta、その前は Aurora、更に前には Nightly で開発が行われています。日本語化は基本的に Aurora チャンネルにおいて英語版との同期作業を行います。

リポジトリ (ソースコード) は何処にあるの？

日本語化に関連するリポジトリについては「Mozilla のリポジトリ」ページにまとめています。

Mercurial の使い方が分からない

Mercurial 公式サイトのチュートリアルなどが参考になります。svn を使ったことがあるのであれば、svn up の代わりに hg pull と hg up を、svn ci の代わりに hg ci と hg push を使うと覚えておけば大丈夫です。

分からないことは既存のプロジェクトメンバーに聞いてください。

また「日本語化環境の準備」ページもご確認ください。

Google Code に push できない

ユーザ名とパスワードは正しく入力(または hgrc ファイルで設定)できていますか？ パスワードはユーザ設定画面で確認できます。 Google アカウントのログインパスワードとは異なるので注意してください。

push するには mozja リポジトリの write 権限が必要です。権限のない方は権限を申請するか、権限のある人にパッチを送付するなどしてください。

Localization Tools (ant) で問題がある

Localization Tools については別途 FAQ ページを用意しておりますのでそちらをご参照ください。

その他

このページに記載のない疑問については、超古いですが次のページも参照してください:

http://www.mozilla-japan.org/jp/l10n/faq/

投稿者

dynamis

投稿日時

カスタム言語パックの作り方

このページでは、標準の言語リソースを元に、方言版やひらがな版のような、カスタム言語パックを作成する手順を説明します。

作業に必要なもの

  • Java 1.5 以降 (?)
  • Apache Ant 1.7.0 以降
  • Perl
  • Subversion
  • UTF-8 対応テキストエディタ
  • 理想(謎)

Linux では適当に、Mac では MacPorts などを使用して必要なコマンドを揃えてください。
Windows では Cygwin を導入するか、Java, Ant 以外については Cygwin のバイナリを ZIP にまとめた次のファイルをダウンロードし、ご利用ください。

note: devpack をご利用になる場合は展開したディレクトリを環境変数 %PATH% に追加してください。

作業概要

カスタム言語パックは標準の日本語パックを地道に書き換えていけば作成できますが、それではオリジナルの日本語版が更新されるたびに追従していく必要があります。特に新しいバージョンに対応するときには多大なメンテナンスコストがかかってしまいます。

そこで、標準の言語リソースを元にどのように書き換えるか定義する文字列置き換え表を用意すれば、最新の言語リソースを元にしたカスタム言語パックをいつでも生成できるようにしています。

語尾を書き換えて方言版、漢字を置き換えてひらがな版、OS 依存用語を置き換えて Soralis 版、その他何でも自由に作成してみてください。

環境構築

作業開始時には作業用スクリプトと言語リソースを取得してください。

  1. L10N SVN から Localization Tools (lot) を export 
    svn export http://svn.mozilla.l10n.jp/trunk/lot
cd lot
  2. L10N SVN から日本語リソースファイルを checkout 
    svn checkout http://svn.mozilla.l10n.jp/trunk/ src/l10n/

    但し、L10N SVN のアカウントを持っており、サーバにコミット予定がある場合は svn+ssh で checkout

    svn checkout svn+ssh://username@svn.mozilla.l10n.jp/usr/local/var/svn/l10n/trunk/ src/l10n/

ここまでは初回のみ必要な準備であり、同期作業をする毎に繰り返す必要はありません。

作業手順

カスタム言語パックのロケール名を ja-JP-example とします。各自作成する言語パックに合わせて読み替えてください。

  1. 文字列置き換え表ファイル ja.example.replace を作成(更新)する

次のように、各行に置き換え前後の文字列をカンマ “,” 区切りで定義して、src/l10n/ja.example.replace ファイルとして保存してください。

# # で始まる行はコメント行
# 置き換え前の文字列,置き換え後の文字列
Mozilla,もじら
Firefox,Shiretoko
既定値,デフォルト
既定の,デフォルト
既定,デフォルト
プライベートブラウジング,こそこそモード
# 必要に応じて正規表現置き換えも行える
# /置き換え前の正規表現/置き換え後の文字列/
/(ENTITY\s+addons.label\s+)"アドオン"/\1"アドオンマネージャ"/
/^(nv_done\s*=\s*)完了$/\1読み込み完了/

すべての言語リソースに対して、上から定義された順に置き換え処理を行っていきます。文脈に依存する場合は前後の文字列を含めて置き換えるように定義して ください。前後の文字列だけでは求めるエンティティだけを特定できない場合、上の例のようにエンティティ ID も含めて指定してください。

  1. カスタム言語パックを生成する

次のコマンドで ja-JP-example ロケールの言語パックを生成できます。

ant auto buildfx -Ddoreplace=true -Dreplace.file=l10n/ja.example.replace -Dlocale=ja -Dlangpack.locale=ja-JP-example

毎回多数のプロパティをコマンドラインの引数で指定するのが面倒な場合は、次のような config/user.conf ファイルを作成してください。

doreplace       = true
replace.file    = l10n/ja.example.replace
locale          = ja
langpack.locale = ja-JP-example

言語パックを配布する際には langpack.conf で定義されている package.guid, package.name, package.description.em などといったプロパティについても設定するか、テンプレートファイル src/langpack/firefox/install.rdf を直接書き換えてください。特に package.guid を設定しなければ標準の言語パックを上書きインストールすることになるので注意が必要です。

  1. カスタム言語パックをインストールして UI を確認する

about:config で general.useragent.locale の設定値を ja-JP-example に変更し、生成された言語パックをインストール、再起動します。
UI を確認して意図通りに変更されているか確認してください。まだ書き換えたいところや、意図通りになっていないところがあれば、手順 1 に戻って文字列置き換え表に定義を追加や修正してください。

注意事項

Firefox 以外のアプリケーションの言語パックについて::

Thunderbird などのカスタム言語パックについても buildfx ターゲットを buildtb に読み替えるなどするだけで、ほぼ同様にして作成できます(説明割愛)。

自動ロケール切り替え機能などについて::

標準で作成される言語パックは最小限の機能(ロケールファイルを追加する)しかないパッケージです。
インストールしただけでロケールを切り替える機能などが欲しい人は各自追加してください。標準機能として追加される予定はありません。

特定ファイルだけを置き換えたい::

現在のところファイル名を指定して置き換える機能は実装していません(一応可能ですが複雑なので手順割愛)。
需要が高ければ実装も検討しますが、そのような高度な処理が必要な場合は別途スクリプトを書いて処理する方が適していると思います。

Firefox 3.0 用の言語パックを作成したい::

現在の lot では Firefox 3.0 以前をサポートしていません。また、Firefox 3.0 以前をサポートしていた古い lot にはカスタム言語パック作成のための機能が備わっていません。
l10n/ja, l10n/ja-JP-mac のファイルを

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/l10n checkout l10n/ja
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/l10n checkout l10n/ja-JP-mac

コマンドで取得できる言語リソースファイルに置き換え、

ant auto clean prepare modify errorcheck pack

といったコマンドを実行することで一応生成できるハズですが、install.rdf の記述など調整が必要になります。

投稿者

dynamis

投稿日時

製品リリースに向けて

このページでは Mozilla アプリケーションの日本語版をリリースするまでの手順を解説します。これは Mozilla 製品の日本語 L10N をリードするメンバーのためのドキュメントであり、hg.mozilla.org にアカウントを持っていて直接製品リリースに sign-off する人のためのものです。

日本語版の問題を修正したり新しいバージョンに向けて更新する場合には 日本語リソースを更新するには ページや 最新の英語リソースと同期させるには ページを参照してください。修正、更新された言語リソースは適当なタイミングで日本語版の公式リリースに反映されるようになります。

作業概要

Mozilla アプリケーションの日本語版をリリースするには以下の作業が必要になります

  • 日本語リソースを英語リソースに同期させる
  • 同期した日本語リソースを L10N HG に PUSH する
  • Tinderbox/Dashboard をグリーンにする
  • Dashboard で Opt-in する
  • 作成されたビルドに問題がないか確認する

作業手順

まず L10N HG ファイルのステータスと差分を確認します:

cd l10n/aurora/ja
hg pull -u
hg status
hg diff

L10N HG にコミット、(プッシュされるチェンジセットを確認してから) プッシュします:

hg commit -m "sync with en-US rev$MOZ_NEWREV+$COMM_NEWRE"
hg outgoing
hg push

ja-JP-mac についても同様に L10N HG リポジトリにプッシュします:

cd ../ja-JP-mac
hg pull -u
hg status
hg diff
hg commit -m "sync with en-US rev$MOZ_NEWREV+$COMM_NEWRE"
hg outgoing
hg push

L10N HG, Dashboard, Tinderbox を確認
Dashboard ではエンティティの過不足が確認できますが、中身の確認はされません。必ずコミット後に Tinderbox がグリーンになることを確認してください(少なくともリリース前は)。

問題なければ Dashborad の Sign-off 列のリンクを開き、最新のチェンジセットで Sign-off します。

注意事項

  • Mercurial の push 時によくあるトラブルとしてよく聞くのは、tip が複数になるという旨のエラーが表示されて push できないという問題です。これはコミット前に pull するのを忘れていて、他の人が既に push したものとマージしなければブランチが増えてしまう場合に表示される警告です。
    その場合は先にローカルリポジトリに他の人のチェンジセットを pull で取り込み、新しくできたブランチを head で確認し、自分のチェンジセットと merge, commit でマージした上で、改めて push してください。マージコマンドがイヤであれば手元のコミットを(単一チェンジセットなら hg rollback で、複数なら clone し直しで)破棄してやり直すのもありです。
  • “hg pull” と “hg update” は、”hg pull -u” でひとまとめで実行することもできますが、リポジトリ上にブランチが作成されたときには同時実行できません(警告が出て停止します)。よく分からなければ、”hg pull” と “hg update” をそれぞれ分けて実行してください。
  • Mac OS X 10.4 などで lot (Java, Ant) の日本語出力が文字化けすることがあります。それは Ant (Java) の出力メッセージが Shift_JIS となっており、ターミナル側の設定と異なるからです。
    ターミナルの文字セットエンコーディング設定を “Unicode(UTF-8)” と指定した上で、~/.bash_profile, ~/.bashrc などに UTF-8 で出力するように指定してください:

    export ANT_OPTS=-Dfile.encoding=UTF8
  • 英語のリソースを取得するには Mozilla のリポジトリ全体を hg clone して ant en-US-to-l10n する以外にもフランス語のチームが用意している http://hg.frenchmozilla.fr/ のリポジトリを利用することもできますが、元の Mozilla のリポジトリとはリビジョン番号が異なっていて比較しにくいとか、Venkman/Chatzilla などが含まれていないといった問題があるため、hg clone して ant en-US-to-l10n する方が確実です。
  • ディスク容量やネットワーク帯域の制約により hg clone したくない場合は、英語のリソースファイルを参照用に zip にまとめたパッケージを毎日自動生成しているので、比較元の古いリビジョンより少し古いファイルと、最新のファイルを ダウンロードページ からリンクしている、参照用 zip パッケージのディレクトリからダウンロードして、差分を生成してください。

投稿者

dynamis

投稿日時

最新の英語リソースと同期させるには

このページでは Mozilla アプリケーションの日本語リソースを、新バージョンの製品用に更新する手順について説明します。

はじめに

新バージョン対応ではなく、既存バージョンの翻訳を修正するだけならもっと簡単です。日本語リソースを修正するには ページを参照してください。製品リリースに向けて hg.mozilla.org のリポジトリへプッシュし、リリース用リソースとして Sign-off する場合には「製品リリースに向けて」ページを参照してください。

Mozilla アプリケーションの新バージョンに対応するため、英語リソースの差分を元に日本語リソースを最新のビルド用に更新する場合にこのページの手順に従って作業してください。日本語化作業環境として Mercurial と Ant が使用できることを前提としています。

新バージョン対応を始める前に旧バージョンのブランチが切られていない場合、先に「ブランチの切り方」に従ってブランチを作成してから作業してください。

作業概要

同期作業の流れは大まかに次のようになります。

  1. 現在の日本語リソースが対応する英語リソースのリビジョンを確認する
  2. 前回同期時(以前)の英語リソースと最新のものを取得し、差分ファイルを生成する
  3. 英語リソースの差分ファイルを見ながら日本語リソースを書き換える
  4. 更新後の日本語リソースに過不足や構文ミス、用語ミスがないか確認する
  5. 同期作業が完了したら同期対象リビジョンを明記してリポジトリにコミットする

日本語リソースの同期作業は、対象となるアプリケーションのディレクトリ単位で行われることが多いです。異なるリビジョンに同期した複数のディレクトリのファイルを同期する場合、ここに書かれた手順をそれぞれ繰り返してください。

なお、ここで言及するディレクトリパスは、lot のディレクトリ(build.xml を含む)に対する相対ディレクトリとします。

作業環境の準備または更新

初回であれば日本語化作業環境の準備にあるとおり、Localization Tools (lot) と言語リソースファイルを取得します:

hg clone https://code.google.com/p/mozja.lot/ lot; cd lot
ant setupl10n

このとき英語版のファイルについて、mozilla/comm リポジトリ (約1GB) を clone するか、取りあえず zip ファイル (約2MB) をダウンロードするか確認されます。今後英語の任意のバージョン間差分を取得するには clone してください。

次回からは次のように Localization Tools (lot) と日本語リソース、英語版ファイルを最新のものに更新します:

hg pull -u
ant pull-src pull-mozilla pull-comm
# または直接 hg コマンドで:
# hg -R src/trunk pull -u
# hg -R hg/mozilla-aurora pull -u
# hg -R hg/comm-aurora pull -u

英語リソースの差分を生成する

英語リソースとの同期作業時にはどのディレクトリを en-US ファイルのどのチェンジセット(リビジョン)と同期したか ja.status ファイルに記録していますので、それを見て確認してください。適切に記録されていない場合は Changes のコミットログなどを参照して前回同期時のリビジョンを調べてください。ここで確認した changeset id (12桁英数字)を $MOZ_OLDREV, $COMM_OLDREV とします。

現在同期している古いリビジョンの英語リソースと、最新英語リソースの差分は次のコマンドで生成できます:

ant diff-revisions -Dmozrev1=$MOZ_OLDREV -Dcommrev1=$COMM_OLDREV

l10n/aurora ディレクトリ配下に指定したリビジョンと最新の英語リソースファイルを含むディレクトリが作成され、それらの差分ファイルが生成されます。ファイル名中の番号はそれぞれ mozilla/comm リポジトリの新旧リビジョン番号です。

日本語リソースを更新する

英語リソースの差分ファイルを確認しながら src/l10n/trunk/ja ディレクトリの日本語リソースを更新していってください。エンティティの値の変更だけでなく、エンティティ名やコメント行の追加削除についても忘れず反映してください。

日本語リソースを更新したら、次のコマンドで src/l10n/trunk/ja の共通日本語リソースから ja.filters の定義に従い l10n/aurora/ja, l10n/aurora/ja-JP-mac ディレクトリに個別の言語リソースを生成します:

ant convert

途中の上書き確認などをスキップして自動実行する場合は auto ターゲットを先に実行させます:

ant auto convert

このとき同時に構文エラーや用字用語違反など基本的な問題がないか確認されます。問題なければ BUILD SUCCESSFUL と表示され完了します。重大なエラーが見つかった場合はその旨表示してから BUILD FAILED と出力されます。

用語エラーや使用文字エラーについては検出された用語や文字が [WORDERROR[使用禁止語句]WORDERROR] のようにマークされるので、その部分を適切や用語や文字に変更するか、プラットフォーム依存用語の変数 @@VARNAME@@ で置き換えるなどしてください。PluralForm エラーについては問題ないものもあります(ビルド停止しません)。分からなければ無視してください。

エラーがなければ、次は英語リソースと比較してエンティティの過不足がないか確認します:

ant compare
ant compare -Dlocale=ja-JP-mac

ファイルやエンティティの過不足を確認し、追加すべきエンティティと削除すべきエンティティが表示される他、アクセスキー比較や重複エンティティの確認などが行われます。出力されたメッセージを参照しながら同期作業の抜け落ちやミスを修正してください。

構文エラーや用語エラー、あるいは過不足比較の結果はコンソールに出力されるだけでなく、log ディレクトリのファイルにも出力されます。必要に応じて参照してください。

言語パックを生成して確認する

Localization Tools では Firefox の言語パックは buildfx、Thunderbird は buildtb、Seamonkey は buildsm などのターゲットで生成できます:

ant auto buildfx

重大なエラーが検出されなければ dest/aurora/langpack ディレクトリに言語パックが生成されるので、それを Aurora ビルドにインストールして動作確認してください。英語版にインストールする場合は about:config で general.useragenet.locale を ja に変更してから再起動してください。

新しい日本語リソースをリポジトリに反映する

L10N SVN ファイルのステータスと差分を確認するまずは他の人のコミットと競合していないか、自分の修正は意図した通りか最終確認してください。

cd src/trunk
hg pull -u
hg status
hg diff

問題なければ最後に、新しく同期している英語リソースが分かるように、ja.status ファイルにどのディレクトリをどのリビジョンと同期したか書き残してください。

ディレクトリ全体ではなく途中まで同期した段階で push する場合、英語リソースの差分ファイルのうち、未処理部分だけを ja.todo ファイルに残してください。その続きを作業するときや引き継いだときには ja.todo ファイルの差分から完了部分を削除してください。

それでは、コミット、プッシュして完了です:

hg commit -m "sync toolkit with en-US rev$MOZ_NEWREV+$COMM_NEWREV"
hg push
cd ../..

mozilla, comm リポジトリを clone していない場合

mozilla-aurora, comm-aurora リポジトリを clone していなければ ant diff-revisions コマンドが使えません。ant clone-mozilla clone-comm コマンドで clone してから差分を生成するか、以下のように新旧の英語リソースを含んだ zip ファイルをダウンロードして手動で差分を生成してください(これはあくまでも非常手段で、clone することを推奨します)。

上記同様に、ja.status ファイルを見て現在同期している英語リソースのチェンジセット(リビジョン)を確認したら、新旧英語リソースの zip パッケージをダウンロードします。

mozilla/comm リポジトリから言語リソースファイルだけを抜き出し、L10N リポジトリと同じディレクトリ構造に整理したものを zip パッケージにして定期自動生成しています。

元の mozilla-central リポジトリのリビジョンを $MOZ_REV、comm-central リポジトリのリビジョンを $COMM_REV として、en-US-${生成日時}-rev$MOZ_REV+$COMM-REV というファイル名になっています。最新のファイルと、先ほど確認した$MOZ_OLDREV, $COMM_OLDREV 以前のファイルを含む zip パッケージをダウンロードします。

changeset id を http://hg.mozilla.org/releases/mozilla-aurora 右上のテキストボックスに入力すると、該当 changeset 以前のログが表示されます。これを使って changeset id の新旧が比較できます。前回同期した changeset の日時を調べ、その前の日付の zip を探してください。

zip ファイルが見つかったら両方展開し、diff コマンドで差分を生成してください:

unzip en-US-rev$MOZ_OLDREV+$COMM_OLDREV.zip -d l10n
mv l10n/en-US l10n/en-US-rev$MOZ_OLDREV+$COMM_OLDREV
unzip en-US-rev$MOZ_NEWREV+$COMM_NEWREV.zip -d l10n
mv l10n/en-US l10n/en-US-rev$MOZ_NEWREV+$COMM_NEWREV
diff -ru l10n/en-US-rev$MOZ_OLDREV+$COMM_OLDREV l10n/en-US-rev$MOZ_NEWREV+$COMM_NEWREV > en-US-rev$MOZ_OLDREV+$COMM_OLDREV-rev$MOZ_NEWREV+$COMM_NEWREV.diff

もちろん実際に同期していたリビジョンより古いものとの差分になるため、一部の差分は既に日本語リソースに反映されていることになります。その部分については作業済みとして単に無視すれば OK です。

注意事項

  • lot を使っていて文字化けやエラーが発生するなども問題が生じる場合は、lot の FAQ ページをご覧ください。
  • 日本語リソースに過不足がある場合、別バージョンの Firefox にインストールしてしまった場合、XML パースエラーで Firefox が起動しなくなることがあります。その場合はセーフモードでアドオン(言語パック)を無効化して起動するか、プロファイルディレクトリの extensions ディレクトリ配下にインストールされた言語パックファイルを削除してください。
  • 日本語ファイルの過不足を英語ファイルでマージした言語パックを作りたい場合は ant convert insertnew buildfx などとします。詳しくは Localization Tools のページの説明をご覧ください。
  • JDK 環境によっては compare 時に StackOverflowError? が発生することがあります。そのような場合はスタックサイズを大きくして実行してみてください: 
    export ANT_OPTS=-Xss10M

投稿者

dynamis

投稿日時