TODO: 用語データベース用のテンプレートを作成の上で対訳定義集を用意する

取りあえず超古いページも参照: http://www.mozilla-japan.org/jp/l10n/term/

ローカライズセンターで公開する 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

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

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

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

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

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

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

日本語版を使っていてお気づきの点があれば、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/

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

作業に必要なもの

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

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

• devpack.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 の記述など調整が必要になります。

このページでは 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 がグリーンになることを確認してください(少なくともリリース前は)。

• http://hg.mozilla.org/releases/l10n/mozilla-aurora/ja
• http://hg.mozilla.org/releases/l10n/mozilla-aurora/ja-JP-mac/
• http://l10n.mozilla.org/dashboard/?locale=ja
• http://l10n.mozilla.org/dashboard/?locale=ja-JP-mac
• http://tinderbox.mozilla.org/Mozilla-l10n-ja/
• http://tinderbox.mozilla.org/Mozilla-l10n-ja-JP-mac/

問題なければ 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 パッケージのディレクトリからダウンロードして、差分を生成してください。

このページでは 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

このページでは Firefox, Thunderbird, Seamonkey などの日本語リソースを修正する手順を説明します。

はじめに

Mozilla アプリケーションの日本語化では大きく分けて次の 2 つの作業をすることになります。

1. 日本語版の修正、更新
   日本語訳の間違いを修正したり、訳語の変更、より分かり易い表現への変更などを随時行います。
2. 英語リソースとの同期
   最新の開発版では随時新しい文字列(エンティティ)の定義が追加、削除、変更されます。新バージョンに対応するには、最新の英語版に合わせて日本語リソースを同期する必要があります。

後者ついては、話が少々複雑になるので、別途「最新の英語リソースと同期させるには」ページで説明します。
ちょっと typo を修正したり翻訳を改善する程度なら簡単にできるので、ここでは簡単な修正に必要なことだけ説明します。

作業手順 (Google Code 上で行う場合)

多数のファイルを修正する場合には向きませんが、mozja リポジトリの書き込み権限があり、ちょっとした typo の修正程度であれば、ブラウザだけで Google Code 上で直接作業できます。

Google Code に Sign in したら該当するファイルを Browse 配下から探し、ファイルを選択、画面上部の Edit file をクリックします。例えば作業メモを残す ja.status ファイルであればこの URL を開くことになります。

中央のテキストエリアで修正し、Preview diff リンクで差分を確認し、画面下部の “Describe your change” と書かれたテキストエリアにコミットログを書き込んだら Commit ボタンを押してください。

作業手順 (自分でリポジトリに反映させない場合)

1. 最新の日本語リソースファイル (Aurora 対応) は mozja リポジトリ で管理されています。次の hg コマンドでリポジトリの clone を取得するか、日本語リソースファイル の zip をダウンロードしてください。

   hg clone https://code.google.com/p/mozja/

2. 気になった日本語ラベルの文字列を検索し、UTF-8 対応のテキストエディタで適切に書き換えてください。
3. 手順 1 で hg コマンドを使用した場合は hg diff コマンドで生成される差分ファイルを、zip をダウンロードした場合は diff -ru コマンドで前後の差分を生成するか、修正済みの全ファイルを zip にまとめ、mozja リポジトリの書き込み権限のある人に送付してください。

差分ファイルの送付はやりやすい方法で構いません。何処かにアップロードしたり、Pastbin に差分ファイルを貼り付けてその URL をフォーラムに書いていただくなど、差分が正しく伝わればどんな方法でも構いません。

作業手順 (自分で mozja リポジトリに push する場合)

Google Code の mozja リポジトリ の書き込み権限を持っていない場合、L10N フォーラムなどで既存のプロジェクトリーダーにコンタクトして権限申請してください。この場合は Mercurial (hg) が必須になります。

1. まずは mozja リポジトリを clone してください

   hg clone https://code.google.com/p/mozja/

2. 気になった日本語ラベルの文字列を検索し、UTF-8 対応のテキストエディタで適切に書き換えてください。
3. 書き換えた内容に間違いがないか、他の人との作業重複がないか確認してください。

   hg pull -u
   hg status
   hg diff

4. ローカルに clone したレポジトリに修正を commit する

   hg commit -m "コミット内容を簡単に説明したコミットログ"

5. リモートリポジトリ (mozja) に変更をプッシュする

   hg push

6. プッシュされた内容を確認する
   サーバにコミットすると変更した内容が Google Code の Updates にチェンジセットとして表示されるので、リンクを開いて差分を確認してください。

注意事項

日本語リソースの修正作業を行う上でよくある問題について書いておきます。必要に応じて「よくある質問」ページもご覧ください。

• 修正した内容をすぐに実際のアプリで確認したい場合には言語パックを作ってください。詳しくは Localization Tools の使い方をご覧ください。
• http://ftp.mozilla.org などで公開されているビルドは mozja リポジトリではなく hg.mozilla.org の L10N リポジトリのリソースを元にビルドされています。mozja リポジトリに入った修正は hg.mozilla.org のアカウントを持ったスタッフが後日反映させるまでしばらくお待ちください。
• 一部のエディタには円記号 “¥” と バックスラッシュ “\”、全角チルダ “～” (U+FF5E) と波ダッシュ “〜” (U+301C) といった OS 依存文字をいずれかに自動変換する機能が備わっています。設定でオフにするか、そのような意図しない自動置き換えが行われないエディタをご利用ください。
  note: 全角チルダと波ダッシュはフォントによっては同一字形で表示されますが、Unicode 上では異なる文字です。
• 初めて hg をお使いの場合は環境設定ができているか事前にご確認ください。username が未設定のままでコミットするとコミットユーザ名にローカルマシンのユーザ名などが使われてしまいます。
• Google Code に hg push する際のパスワードは Google アカウントのログインパスワードではありません。Google Code 用のパスワードは乱数生成されており、ユーザ設定画面で確認できます。Google アカウントのログインパスワードを許可する設定もありますが、Google Code 専用アカウントでない限り同じパスワードを使うことはお薦めしません。
• Google Code への push 時に毎回ユーザ名とパスワードを入力するのが面倒な場合は src/trunk/.hg/hgrc ファイルで次のように default-push を設定してください。ドメイン名の前にアカウント名とパスワードを設定しますが、メールアドレスの @ は %40 とエスケープする必要があるので注意してください。

  [paths]
  default = https://code.google.com/p/mozja.lot/
  default-push = https://username%40example.jp:パスワード@code.google.com/p/mozja.lot

Firefox や Thunderbird などの L10N をレビューする際の手順や注意点を書きます。

日本語リソースファイルは Github で管理されており、その更新記録は Github の Commits や hg.mozilla.org の mozilla-aurora リポジトリ で確認できます。

更新作業をレビューする

ファイルが更新されると、Github の Commits に新しいリビジョンが追加されます。コミット時のコメントや日付が書かれた各行をクリックするとそのリビジョンで変更されたファイル一覧と差分を確認できます。最新の更新作業をレビューするにはこの差分の内容を確認してください。

お気づきの点があれば、L10N Forum にコメントするか、Github 上のコードレビュー機能でコメントしてください。

言語リソースファイルをレビューする

日本語リソースファイルは、Github のディレクトリツリーの /ja ディレクトリ以下 で確認できます。そこで各ファイルを確認していただくこともできますし、git clone してローカルで確認していただくこともできます。

各アプリケーションのディレクトリと更新記録は、ja.status ファイルを参照してください。

特に、後で再確認が必要な点などは言語リソースファイル中に “(^^;”, “(^a^)”, “(^^h” などといった顔文字付きのコメントが書かれています。これらの顔文字を grep することで特に注意が必要なもののリストが確認できるので、その部分を集中的にレビューしていただくこともできます。