Next: gettextize Invocation, Previous: Flat and Non-Flat, Up: Maintainers [Contents][Index]
パッケージにたいしてGNU
gettext
を使用するためには、準備が少し必要です。これらの作業は、要点の説明だけだと肝心な部分がわからなくなってしまうある種の一般性をもっているので、このチャプターを読んで後から見返せるように、ここで大まかに説明しておきましょう。
gettextize
を使う前に、最初に他のパッケージをインストールする必要があります。最新のバージョンのGNU m4
、GNU
Autoconf、GNU
gettext
がインストールされていることを確認してください。もしインストールされていない場合、それらを最初にインストールします。GNU
Autoconfをインストールする前に(たとえconfigured済みだとしても)、GNU
m4
が完全にインストールされていなければならないことに注意してください。
パッケージautomake
は、メンテナーのタスクを楽にするためにデザイン・実装されています。現在のGNU
gettext
もこれらのツールを使用しているので、intl/やpo/にあるMakefileは、1つのプロジェクトでautomake
とlibintlを使う場合に必要なものです。
これら4つのパッケージはメンテナーにとって必要なだけです。パッケージを正常にインストールして翻訳されたメッセージを正しく表示するだけなら、インストールする人やパッケージのエンドユーザーには、GNU
m4
、GNU Autoconf、GNU gettext
、GNU
automake
は必要ありません。しかしパッケージにインターナショナライズされたシェルを含めて配布する場合、これは完全に真実とはいえなくなります:
ユーザーがシェルスクリプトの翻訳されたメッセージを見たいときは、GNU gettext
のインストールが必要になります。
POファイルが投稿されたとき、メンテナーとしてどのように振る舞うのが理想的なのか、少し説明をしておきましょう。メンテナーとしてのあなたの役割は、その投稿が翻訳プロジェクト内の対応する翻訳チーム(わからないときはcoordinator@translationproject.orgに転送してください)によるものであることを証明し、POファイルのフォーマットが壊れていてインストールできないくなっていないか確認し、それらのPOファイルを配布物のpo/ディレクトリーに配置することです。
メンテナーとしては、翻訳が十分なのか、または完璧なのかをチェックする責任を負う必要はないので、語学に関する事柄については無視するべきです。翻訳チームは、チーム自身の運営と翻訳プロジェクトでの言語学的な選択について完全な責任を負います。翻訳チームがメンテナーにより運営されるのではないことを覚えておいてください。ユーザーからの言語上の指摘や報告などを、適切な翻訳チームに転送したり、ユーザーが翻訳チームに参加する方法を説明するような手助けをすることはできます。もっとも簡単なのはABOUT-NLSファイルを送ることでしょう。
メンテナーが翻訳チームを介さずに、自分でPOファイルに関するバグ報告を受けるのは決して行うべきではないことです。ある問題について翻訳者が彼女のチームと一致した見解をもつのが困難なとき、彼女が直接メンテナーと交渉するようなオプションが存在するべきではありません。どんな問題にせよ、彼らは問題をチーム自身で解決するべきです。メンテナーとしては、もしチームに本当に問題があると思えるときでも、あなた自身がチームの問題を解決しようとはしないでください。