Copyright (C) 1999, 2000, 2002 IIDA Yosiaki
何人も、以下の内容を変更しないでそのまま複写する場合に限り、 本文書を複製したり頒布したりすることができます。

序

この文書は、 Translation Project日本語チームのコーディネータが書いたものです。 内容については注意をはらって書いたつもりですが、 誤りのないという保証は一切ありません。 著作権者やその他の第三者は全く無保証で「そのまま」の状態で、 且つ、明示か暗黙であるかを問わず一切の保証をつけないで提供するものとします。

初級編1 -- メーリングリストに加入するまで

まず色々な略語について聞くが、まずJAとは?

日本語という言語を表わすISOの2文字符号です。

JPではなくて?

はい、JPではありません。 なぜならJPは日本国という国を表わすISOの2文字符号だからです。

POとは?

メッセージの翻訳をCPU(機械)と無関係な形式で格納したファイルのことです。 ``Portable Object''の頭文字です。

MLとは?

「メーリング・リスト」(mailing list)の略で使う人もいます。 英語圏では単に``list''(リスト)としているのは時々みかけますが、 MLと略していることはあまりみかけないので、 もしかしたら和製英語かもしれません。

MOとは?

メッセージの翻訳をCPU(機械)によって違う形式で格納したファイルのことです。 ``Machine Object''の頭文字です。

TPとは何の略?

``Translation Project''の略です。 あまり一般的な略語ではありません。

Translation Projectについて、もう少し知りたいのだが。

gettextのマニュアルに詳しく出てますが、 フリー・ソフトウェアの作者、利用者、 訳者との橋渡しをする目的で作られたプロジェクトです。 フリー・ソフトウェアのPOファイルを中心とした翻訳作業や、 コーディネートをしています。

Translation Projectについて書いたウェブ・ページを紹介してほしい。

とても簡単ですが、GNUダイジェスト http://www.sra.co.jp/public/doc/gnu/Bull24j/Bull24j_2.html#SEC18 に、紹介文の和訳があります。 プロジェクト全体の英文公式ページは、

http://www.iro.umontreal.ca/contrib/po/HTML/

Free Translation Projectとか GNU Translation Projectとかの関係は?

皆多分同じです。 ときどきFree Translation Projectとも呼ばれています。 GNU Translation Projectと呼んでいた人が昔いた(今でもいる?)らしい。

プロジェクトで扱っているフリー・ソフトウェアは?

一覧が

http://www.iro.umontreal.ca/contrib/po/HTML/domains.html

<ja@li.org> があるのか?

ありました (すでに過去形)。 <ja@li.org>は、 Translation Projectの日本語チームのメーリング・リストでした。 同様のプロジェクトのリストである<japo@linux.or.jp>と、 <ja@li.org>の両方に加入している人もいました。 このプロジェクトが<japo@linux.or.jp>と違うのは、 <ja@li.org>が原作者への成果物の還元をかなり積極的に推進していることです。 このページをご覧になっていただければすぐわかりますが、 まだ成果は多くありません。 日本語チームも数年前から存在だけは一応していました (信じられないかもしれませんが)。 立て直し作業が、 1999年初頭から始まりました。

日本語チームについて、詳しく知りたいのだが。

日本語チームのメーリング・リストは、

translation-team-ja@lists.sourceforge.net

http://www.iro.umontreal.ca/contrib/po/HTML/team-ja.html

日本語チームに加入したいが、どうすれば?

https://lists.sourceforge.net/lists/listinfo/translation-team-ja/

このページに英語で書いてあるとおり、 ここで大事なパスワードは使わないでください。 確認のためと称して、 平文のメールで自動返送されてくるからです。

ja@li.orgは?

それは前のリストでした。

ここにはPOしかないようだが。 PO以外の翻訳、たとえば、 ドキュメント、マニュアル、PO以外のリソース等の翻訳はしてないのか?

そうしたいのはやまやまですが、 そこまで至っていないのが実状です。 実際、このFAQリストの著者も別のマニュアルの翻訳は、 別のメーリング・リストで作業しています。

FSFのフリー・ソフトウェアについては、 FSFのgnujdocプロジェクトがあつかっています。

ここにないフリー・ソフトウェアの翻訳についてはどうしたらよいのか? 翻訳プロジェクトとしては報告して欲しいのか?

義務は全くありませんが、 報告していただければ嬉しいです。 もし後からそういう問合せがあれば、 それに応じることもできるので。

ここにないフリー・ソフトウェアの翻訳について、 作者に直接交渉してしまって構わないのか?

はい、構いません。

初級編2 -- メーリングリストに加入してから

<ja@li.org>に参加しようと思ってメールを出してみたが、 何の返事もない。

ja@li.orgは、 配信していません。

<ja@li.org>メーリング・リストの過去の記事がないようだが、 まさか今までに投稿が全然ないのか?

このメーリング・リストでは、 記事を保管していません。 もちろん投稿は前からあります。

ではどんな機能があるのか?

加入、 記事の配信、 脱退はできました。 他のことができたかどうかは知りません。

なぜどんな機能があるか知らなかったのか?

このFAQ文書を書いている 「Translation Project日本語チームのコーディネータ」 は、 メーリング・リストの管理者ではなかった (過去形) からです。

中級編1 -- 権利放棄声明文書を出すまで

誰でも自由に使用、改変して構わない、というのは、 コピーレフトというのか? それともGNU GPLか?

一般的にいうとコピーレフトです。 GNU GPLは、 プログラムという限られた場合について、 法律の上で有効にコピーレフトにする方法の1つです。 マニュアルや論文のような文書をGNU GPLで保護しようとするのは、 エリック・レーモンドやブルース・ペレンスのような確信犯的な例外を除けば、 GNU GPLとコピーレフトの違いをまだよく理解できていない人のすることでしょう。

公開するにあたり、著作権関係の宣言もしなければならないのか?

義務はありません。 コピーレフトになっているものを誰かが翻訳なさったのなら、 普通公開するにあたって宣言するしないを決める権利はその訳者にあり、 そうしようと、そうしまいと、それは訳者の自由です。
ただ、 たとえばもしコピーレフトになっているものの訳が2種類あって、 片方はちゃんと許可告知を明記していて、 もう片方は許可告知をあいまいにしていたときに、 私が片方を利用するとしたなら、 多分、許可告知の明記されている方をとります。
なぜか? 許可告知をあいまいにした方を使ってしまってから訳者に 「そんな使い方をしたら、私の著作権を侵害したことになるから、 慰謝料を払え」などと請求されたりしては困るからです。
許可告知が明記してあれば、 その許可告知の範囲内で安心して使用できますから、 私ならそちらを選ぶわけです。
人に使ってもらいたくて公開するのでしょうから、 その意図を明確にすれば、 より多くの人に使ってもらえるようになると思います。
GNUプロジェクトをはじめとした多くのフリー・ソフトウェアで、 成果物を「自由にコピー可能」と明記しているのは、 そういう理由もあるはずです。

翻訳はGNU GPLで保護するのか?

一般に、GNU GPLの保護するものは、プログラムです。 ときたま辞書や純粋な数値データもGPLで保護されていることがあります。 が、それらもあくまでプログラムとして保護されています。 プログラムでないもの、たとえばTexinfoで書いたマニュアル (やその翻訳) は、 GNU GPLでは保護されていません (GnuPG Privacy Handbookを除く)。 Texinfoで書いたマニュアルの冒頭には、 たいてい許可告知(permission notice)があって、 そこにどういう条件でコピーしてよいか悪いかが、 書いてあります。 最近は、 GNU Free Documentation Licenseで保護されていることもあります。 少なくとも私の知る限り、 FSFの発売する本の許可告知で「GPLで保護する」というふうに書かれたものは、 (GnuPG Privacy Handbookを除けば) ありません。 Texinfoの原稿には、 GNU GPL自体が含まれていることがあります。 しかしそのことだけでは、 マニュアルをGNU GPLで保護することにはなりません。 マニュアルはマニュアルの許可告知のとおりに保護されているだけです。 それに、 GNU GPL自体の許可告知は、 「変更は不可で、変更しなければ配布は可」という単純なものです。 GNU GPL自体、 GNU GPLで保護されてはいないのです。 それはGNU GPL自体が、 プログラムではないからです。 このことは非常に微妙で、誤解されやすい部分です。 実際、FSFのスタッフ中にさえ、 指摘されるまで誤解をしていた人がいたくらいです。

ではPOの翻訳は?

POファイルの場合、一見、グレーな部分かもしれません。 ですが、POの元になるPOTファイルは、 GNU GPLで保護されたプログラムから、 なかば自動的に抽出、生成できるので、 私見ですが、 GNU GPLで保護すべきプログラムの派生物 (したがってGNU GPLで保護される) とみなされるのだと思います。 実は私はGNU Emacs Lisp Reference Manualの訳者(のひとり)でもあります。 これは完全にプログラムとは独立したマニュアルだったせいか、 FSF発行のCD-ROMに収録される際もdisclaimerは要求されませんでした。

自由にコピーしてよいという意図を明確にするには、 どこで宣言したらよいのか? ファイルの中なのか、 あるいはメーリングリストでなのか?

ファイルの中に書くのが、一番良い考えかもしれません。

どうも fr.po, de.po などをみても、配布形態についての記述は見かけぬし……。

確かにそうですね。 他のPOファイルに何も書いてない、というのは気になります。 保守が面倒だ、というのがそうなっていない理由のようです。

修正の度に権利放棄声明文書を送らなければならないのか?

いいえ、その必要は全くありません。 もしどうしてもそうしたければ、 「これこれこういうバージョンについてのみ権利を放棄します」 などと権利放棄証明書に特定して書けば、 そうできるかもしれません。 前に紹介したページでは 「これこれこういう『言語』の翻訳についての権利を放棄します」 というふうになっているので、 最初、 日本語「だけ」権利を放棄しておいて、 後から(たとえば)ロシア語のPOを (ロシア語チーム経由で) 送りたくなったような場合は、 また郵送してあげないといけません。 自分が何語で貢献できるかは、 前もって自分でわかっているはずですから、 最初から全部について権利を放棄しておく手もあります。 あと、 いったん放棄した権利を取り消すことは、 不可能であるか、 あるいは非常に面倒です。 それも考慮に入れておいてください。

声明文書を送った後でPOを修正したくなったら、修正は可能ですか?

はい、可能です。

disclaimer内の自分の住所の書き方で、とても悩んだのですが。

この場合、国名を書くのさえ忘れなければ、どんな順序で書いたっ て大抵はOKです。 本当はフランス語でJAPONと書くのが正式なのかもしれませんが、 JAPANでもOKです。 外国の郵便局員は、国名「だけ」を読んで適当な国(日本)に回して、 国内の住所を実際に読むのは、国内の(日本の)郵便局員のはずですから。 極端な話、国名さえ忘れずにアルファベットで書いておけば、 日本宛ての国内の宛名や宛所を漢字で書いても、ちゃ〜んと届きます。 もっともFSFに出すdisclaimerの場合、仮に住所を使う人が居た としたらそれはおそらく日本人じゃないでしょうから、 誰でもつづれるように全部アルファベットで書いておく、 というだけの話。

Air mail っていくら?

110円。意外と安い。

担当訳者ではない、と怒られてしまった。どうする?

日本語チームのコーディネータ経由で、 プロジェクト全体のコーディネータに知らせればよい。 遠い将来、直にロボットに伝えられるようになる予定。

−−−−−−−−−−−−−−−ここから−−−−−−−−−−−−−−−
* Notes about the Translation Project Robot

.* Checks

. + Do not msgmerge PO files if the POT file is not the latest.
. + Refuse to upload a POT file we already have.

.* Authentification

. + Meant for package maintainers submitting POT files, or URLs.
. + Meant for team leaders altering the registry.
. + Meant for translators to declare aliases, or envelope aliases.

.* Missing POT files

. + Attempt automatic download and extraction.
. + Handle irregular archive names, not unpacking expectedly.
. + Maybe check all URLs for when they change?

.* Submissions decoding

. + Accept compression.
. + Accept MIME.
. + Accept PGP validation.
. + Accept various end of line codings.

.* Validation

. + Try fuzzy matching on names and address, and diagnose matches.
. + Ignore case within the domain.
. + Ignore trailing whitespace differences.
. + Have special envelope aliases to ignore.
. + Validate the registry for no double assignment.
. + Record that the initial translator is different and do not complain.
. + Process date intervals and precise packages for assignment validity.
. + Reject a submission if PO-Revision-Date has not been modified since last.

.* Versioning

. + Be uniform with the Web site about finding the best one.
. + Allow some per-package specifities.
. + Better documents problems for people wanting to lie:
.  - Maintainers wanting to use advanced versions for incoming releases
.  - Translators wanting to use advanced versions for incoming releases
. + Branch processing.

.* Emailing

. + `formail -r' uses Sender instead of From.  Make this all more regular.
. + Make sure all messages have a From indicating the robot.
. + Ease Gnus threading for various log and debugging messages.

.* Incoming features
. + Maintainers should be able to handle POT files themselves:
.  - Set the pretest URLs.
.  - Force POT file uploads.
.  - Process and announce.
. + No multiple successive messages announcing uploads to all members.
. + Redirection of rejects and difficulties directly to team leaders.
. + Capability to send yet unmerged POT files to translators.
. + Internationalisation of the full robot suite, itself.

.* Formatting details
. + Do not refill when quoting URLs lists.
. + Tidy up processing of \007 and other control characters.
. + Replace "probably someone is assigned" with registry information.

.* Other internal details
. + Handle the registry in binary form, use SGML to debug only.
. + Cross-validate AUTHORS with the registry, once in a while.

.* Web details
. + Do not list mailto for those not wanting them there.
. + Reestablish mailtos for people having home Web pages.
−−−−−−−−−−−−−−−ここまで−−−−−−−−−−−−−−−

copyright disclaimer の話ですが、

• プロのprogrammer が code を FSF に GPL で contribute する時に必要
• プロの翻訳家が 翻訳を contribute する時に必要

上の「copyright disclaimer」ですが、 これはcontributeする人の所属組織の発行するdisclaimerのことですね。 プロアマ問わず、 FSFはcontributeする訳者の書いたdisclaimerを要求すると思います (というか、現在、実際に要求しています)。 どうしてFSFはdisclaimerを要求するのか? それは、 他人に著作権のあるものをFSFが勝手に配布して著作権者がFSFを訴えたりすることを、 防止するためですよね。 ですから本人のdisclaimerはアマプロ問わず必要で、プロの場合、 さらに所属からもdisclaimerも必要になる、ことがある、というわけです。 Translation Projectは、 FSFのものを中心とするフリー・ソフトウェアの作者とPOファイルの訳者の間を、 仲介しています。 上で「中心とする」と書いたのは、いいかえると、 全部が全部FSFのフリー・ソフトウェアとは限らない、ということです。 詳しくは

http://www.iro.umontreal.ca/contrib/po/HTML/domains.html

http://www.iro.umontreal.ca/contrib/po/HTML/domain-lynx.html

http://ring.gr.jp/pub/doc/gnu-info-j/po/welcome.html.ja

著作権放棄(disclaimer)の書面はどうしても出さないとダメなのか?

GNUのフリー・ソフトウェアの場合は、 FSFが告訴されても証拠が出せるように、 著作権者が「私(であれ他の誰であれ)は著作権を放棄します」 というような英文の書面をFSFに出さないと、 入れてくれません。

この書面は、 あなたのご職業が何であれ、 あなたがはたらいていようがいまいが、 出す必要があります。

ご職業が翻訳であれば、勤務先からもこの書面を取って FSFに送る必要があるかもしれません。 そうでない場合でも、 万が一のために 勤務先からこういった書面をあらかじめ取っておくことは良いことだと思います (最近になって私は事業部の責任者から署名入りの書面を貰いました)。 著作権放棄の書面がFSFに届いてはじめて翻訳を正式に登録できます。 TP Robotという特別なメールのアドレスにメールを送ると、 翻訳が登録できます(他の方法もあるのかもしれないが、知らない)。 TP Robot は、訳者が Japanese Team のメンバーかどうか、 disclaimer が出ているかどうかなどの細々したチェックしています。

著作権譲渡(assignment)の書面というのを聞いたことがあるが。

著作権譲渡はあなたの著作物を、 あたかも最初からFSFの著作物であったかのようにするためのものです。 POの翻訳の場合、そこまでは求められていません。

中級編2 -- 権利放棄声明文書を出してから

POの1行目は英語じゃないとダメなのか?

言語は英語、用字系はラテン・アルファベット、文字集合はASCIIというPOが、 多いし、私はそうすることをすすめるが、 何語でも、どんな用字系や文字集合でもかまわないことになっている。

日付の形式がPOTとEmacsのpo-modeで違うようだが。

「+09:00」のように時差にコロンのある方が、国際標準。

POのLast-Translatorは?

あなたの名前とメールのアドレスです。 訳者登録したときと同じように書くこと。 姓名の順序やつづりを訳者登録したときと変えて書くと、 受け付けられません。

FSFのあるアメリカに合わせて、名姓の順序に逆転しなくてもよいのか?

姓名の順でかまいません。名姓の順にしたければ、それでもかまいません。 あなたのお好きなようにすればよろしい。 ちなみに私は日本人なので、いつもどおりの姓名の順にしています。 自分の好きなようにできるということは、 インドネシアなどの人のように姓や名という区別のない名前をもった人も、 日本語チームに参加できる、ということです (まだそういう人はいませんが)。

FSFの担当者が、名姓の順序に逆転するように言ってきた。

FSF担当者は、 米国政府やマサチューセッツ州政府の事務手続きでの担当官吏の話を、 おうむ返しにしているだけです。 GNUやTranslation Projectは国際的ですが、 (残念ながら) 米国政府はそうではないので、 その米国官吏の都合のいいように処理させるしかないでしょう (日本人は逆転させるくせ、 中国人や朝鮮人はMao ZedongやKim Ilsongの順だったり、 結構いい加減な気がするのは私だけ?)。

FSFのあるアメリカに合わせて、ヘボン式つづりにしなくてもよいのか?

これもあなたのお好きなようにすればよろしい。 幸い日本人の名前のつづりに詳しい米国官吏は多くはないようだ。 ちなみに私はISO 3602準拠のつづりにしている。 これは日本式や内閣訓令式と大体同じ。

de.poにはLanguage-Team: German <de@li.org>、it.poには Language-Team: Italian <it@li.org>の記述があるのですが、 日本語の場合はどうしたらよいのでしょう? 何を書けばよいのですか?

公開したPOをフリー・ソフトウェアの作者に還元したいかどうかによります。 作者に還元するつもりがなければ、何を書いてもかまいません。

では作者に還元するつもりなら?

Language-Team: Japanese <translation-team-ja@lists.sourceforge.net> と書いてください。

printf 系の可変引数の型と文字列内の型との整合チェックの方法は?

msgfmt -c --strict -v -v -v -o FOOBAR.mo FOOBAR.po

POTがない、とロボットに言われたが、どうする?

POTがないと投入はできません。

charsetの指定が間違っている、とロボットに言われるのだが?

今のところ、 日本語むきなcharsetとしては、 ISO-2022-JPとEUC-JPだけがサポートされています。 ISO-2022-JPは実験段階です。

msgfmtコマンドがぶつぶつ文句を言うのは、 どうもPOがEUCではなく勝手にJISになってしまっているためのような気がしますが?

POファイルをロボットに送るときGNU EmacsのPOモードでMキーに割り当ててある po-send-mail コマンドを実行する前に

(setq default-process-coding-system '(euc-jp . euc-jp))

;;; po-mode
(autoload 'po-mode "po-mode")
(setq auto-mode-alist (cons '("\\.po[tx]?\\'\\|\\.po\\." . po-mode)
                            auto-mode-alist))
(autoload 'po-find-file-coding-system "po-mode")
(modify-coding-system-alist 'file "\\.po[tx]?\\'\\|\\.po\\."
                            'po-find-file-coding-system)

「EUCというcharsetの指定は聞いたことあるがFOOBARという指定は変だよ」 などとロボットに言われてしまいました。何が有効であるべきでしょう?

charsetとしてはEUCではなく IANA に登録されているEUC-JPが正解のはず。

$Id: faql.html,v 1.4 2002/03/13 10:20:56 iida Exp $