developers-reference - en to ja translation catalogue (209 entries)

en: Best Packaging Practices
ja: パッケージ化のベストプラクティス

en: This chapter provides some best practices for Debian developers. All recommendations are merely that, and are not requirements or policy. These are just some subjective hints, advice and pointers collected from Debian developers. Feel free to pick and choose whatever works best for you.
ja: この章では、Debian 開発者へのベストプラクティスをいくつか提供します。すべての勧めは単に勧めであり、要求事項やポリシーではありません。Debian 開発者らからの主観的なヒント、アドバイス、ポインタです。あなたにとって一番うまくいくやり方を、どうぞご自由に選んでください。

en: Best practices for ``debian/rules``
ja: ``debian/rules`` についてのベストプラクティス

en: Helper scripts
ja: ヘルパースクリプト

en: The rationale for using helper scripts in ``debian/rules`` is that they let maintainers use and share common logic among many packages. Take for instance the question of installing menu entries: you need to put the file into ``/usr/share/menu`` (or ``/usr/lib/menu`` for executable binary menufiles, if this is needed), and add commands to the maintainer scripts to register and unregister the menu entries. Since this is a very common thing for packages to do, why should each maintainer rewrite all this on their own, sometimes with bugs? Also, supposing the menu directory changed, every package would have to be changed.
ja: ``debian/rules`` でヘルパースクリプトを使う根拠は、多くのパッケージ間でメンテナらに共通のロジックを利用・共有させるようになるからです。メニューエントリのインストールについての問いを例にとってみましょう: ファイルを ``/usr/share/menu`` (必要であれば、実行形式のバイナリのメニューファイルの場合 ``/usr/lib/menu``) に置き、メンテナスクリプトにメニューエントリを登録・解除するためのコマンドを追加する必要があります。これはパッケージが行う、非常に一般的なことです。なぜ個々のメンテナがこれらのすべてを自分で書き直し、時にはバグを埋め込む必要があるでしょう? また、メニューディレクトリが変更された場合、すべてのパッケージを変更する必要があります。

en: Helper scripts take care of these issues. Assuming you comply with the conventions expected by the helper script, the helper takes care of all the details. Changes in policy can be made in the helper script; then packages just need to be rebuilt with the new version of the helper and no other changes.
ja: ヘルパースクリプトがこれらの問題を引き受けてくれます。ヘルパースクリプトの期待するやり方に従っているならば、ヘルパースクリプトはすべての詳細について考慮をします。ポリシーの変更はヘルパースクリプト中で行えます; そして、パッケージを新しいバージョンのヘルパースクリプトでリビルドする必要があるだけです。他に何の変更も必要ありません。

en: :ref:`tools` contains a couple of different helpers. The most common and best (in our opinion) helper system is ``debhelper``. Previous helper systems, such as ``debmake``, were monolithic: you couldn't pick and choose which part of the helper you found useful, but had to use the helper to do everything. ``debhelper``, however, is a number of separate little ``dh_*`` programs. For instance, ``dh_installman`` installs and compresses man pages, ``dh_installmenu`` installs menu files, and so on. Thus, it offers enough flexibility to be able to use the little helper scripts, where useful, in conjunction with hand-crafted commands in ``debian/rules``.
ja: :ref:`tools` には、複数の異なったヘルパーが含まれています。もっとも一般的で (我々の意見では) ベストなヘルパーシステムは ``debhelper`` です。\ ``debmake`` のような、以前のヘルパーシステムはモノリシックでした: 使えそうなヘルパーの一部を取り出して選ぶことはできず、何を行うにもヘルパーを使う必要がありました。ですが、\ ``debhelper`` は、いくつもの分割された小さな ``dh_*`` プログラムです。たとえば、\ ``dh_installman`` は man ページをインストールして圧縮し、\ ``dh_installmenu`` は menu ファイルをインストールするなどします。つまり、\ ``debian/rules`` 内で使える部分では小さなヘルパースクリプトを使い、手製のコマンドを使うといった十分な柔軟性を与えてくれます。

en: You can get started with ``debhelper`` by reading debhelper 1, and looking at the examples that come with the package. ``dh_make``, from the ``dh-make`` package (see :ref:`dh-make`), can be used to convert a vanilla source package to a ``debhelper``\ ized package. This shortcut, though, should not convince you that you do not need to bother understanding the individual ``dh_*`` helpers. If you are going to use a helper, you do need to take the time to learn to use that helper, to learn its expectations and behavior.
ja: debhelper 1 を読んで、パッケージに付属している例を参照すれば、\ ``debhelper`` を使い始めることができます。 ``dh-make`` パッケージ (:ref:`dh-make` 参照) の ``dh_make`` は、素のソースパッケージを ``debhelper``\ 化されたパッケージに変換するのに利用できます。ですが、この近道では個々の ``dh_*`` ヘルパーをわざわざ理解する必要がないので、満足できないでしょう。ヘルパースクリプトを使おうとするのであれば、そのヘルパーを使うこと、つまり前提と動作を学ぶのに時間を割く必要があります。

en: Multiple binary packages
ja: 複数のバイナリパッケージ

en: The second case can be easily managed in ``debian/rules``. You just need to move the appropriate files from the build directory into the package's temporary trees. You can do this using ``install`` or ``dh_install`` from ``debhelper``. Be sure to check the different permutations of the various packages, ensuring that you have the inter-package dependencies set right in ``debian/control``.
ja: 二つ目の例は、\ ``debian/rules`` で簡単に扱うことができます。ビルドディレクトリからパッケージの一時ツリーへ、適切なファイルを移動する必要があるだけです。これは、\ ``install`` または ``debhelper`` の ``dh_install`` を使ってできます。パッケージ間の依存関係を ``debian/control`` 内で正しく設定したのを忘れずに確認してください。

en: Best practices for ``debian/control``
ja: ``debian/control`` のベストプラクティス

en: The following practices are relevant to the ``debian/control`` file. They supplement the `Policy on package descriptions <https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions>`__.
ja: 以下のプラクティスは、\ ``debian/control`` ファイルに関するものです。\ `パッケージ説明文についてのポリシー <https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions>`__\ を補完します。

en: The description of the package, as defined by the corresponding field in the ``control`` file, contains both the package synopsis and the long description for the package. :ref:`bpp-desc-basics` describes common guidelines for both parts of the package description. Following that, :ref:`bpp-pkg-synopsis` provides guidelines specific to the synopsis, and :ref:`bpp-pkg-desc` contains guidelines specific to the description.
ja: パッケージの説明文は、\ ``control`` ファイルの対応するフィールドにて定義されている様に、パッケージの概要とパッケージに関する長い説明文の両方を含んでいます。\ :ref:`bpp-desc-basics` では、パッケージ説明文の双方の部分についての一般的なガイドラインが記述されています。それによると、\ :ref:`bpp-pkg-synopsis` が概要に特化したガイドラインを提供しており、そして :ref:`bpp-pkg-desc` が説明文 (description) に特化したガイドラインを含んでいます。

en: General guidelines for package descriptions
ja: パッケージ説明文の基本的なガイドライン

en: The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user.
ja: パッケージの説明文は平均的なユーザーに向けて書く必要があります。平均的な人というのは、パッケージを使って得をするであろう人のことです。例えば、開発用パッケージであれば開発者向けですし、彼ら向けの言葉でテクニカルに記述することができます。より汎用的なアプリケーション、例えばエディタなどであれば、あまり技術的ではないユーザ向けに書く必要があります。

en: Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem.
ja: パッケージ説明文のレビューを行った結果、ほとんどのものがテクニカルである、つまり、技術に詳しくはないユーザに通じるようには書かれてはいないという結論に達しました。あなたのパッケージが、本当に技術に精通したユーザ用のみではない限り、これは問題です。

en: How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — GNOME or KDE is fine, since users are probably familiar with these terms, but GTK is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them.
ja: どうやって技術に詳しくはないユーザに対して書けばいいのでしょう? ジャーゴンを避けましょう。ユーザが詳しくないであろう他のアプリケーションやフレームワークへの参照を避けましょうー GNOME や KDE については、おそらくユーザはその言葉について知っているでしょうから構いませんが、GTK はおそらくダメです。まったく知識がないと仮定してみましょう。技術用語を使わねばならない場合は、説明しましょう。

en: Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about.
ja: 客観的になりましょう。パッケージ説明文はあなたのパッケージの宣伝場所ではありません。あなたがそのパッケージをどんなに愛しているかは関係ありません。その説明文を読む人は、あなたが気にすることと同じことを気にはしないであろうことを覚えておいてください。

en: References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, use X Window System, X11, or X; not X Windows, X-Windows, or X Window. Use GTK, not GTK+ or gtk. Use GNOME, not Gnome. Use PostScript, not Postscript or postscript.
ja: 他のソフトウェアパッケージ、プロトコル名、標準規格、仕様の名前を参照する場合には、もしあれば正規名称を使いましょう。X Windows や X-Windows や X Window ではなく、X Window System あるいは X11 または X を使いましょう。GTK+ や gtk ではなく GTK を使いましょう。Gnome ではなく GNOME を使いましょう。Postscript や postscript ではなく PostScript を使いましょう。

en: If you are having problems writing your description, you may wish to send it along to ``debian-l10n-english@lists.debian.org`` and request feedback.
ja: 説明文を書くことに問題があれば、\ ``debian-l10n-english@lists.debian.org`` へそれを送ってフィードバックを求めるとよいでしょう。

en: The package synopsis, or short description
ja: パッケージの概要、あるいは短い説明文

en: Policy says the synopsis line (the short description) must be concise, not repeating the package name, but also informative.
ja: ポリシーでは、概要行 (短い説明文) はパッケージ名を繰り返すのではなく、簡潔かつ有益なものである必要がある、となっています。

en: The synopsis functions as a phrase describing the package, not a complete sentence, so sentential punctuation is inappropriate: it does not need extra capital letters or a final period (full stop). It should also omit any initial indefinite or definite article — "a", "an", or "the". Thus for instance:
ja: 概要は、完全な文章ではなくパッケージを記述するフレーズとして機能します。ですので、句読点は不適切です: 追加の大文字や最後のピリオドは不要です。また、最初の不定冠詞や定冠詞 — "a", "an", or "the" を削る必要があります。つまり、例えば以下のようになります:

en: Technically this is a noun phrase minus articles, as opposed to a verb phrase. A good heuristic is that it should be possible to substitute the package *name* and *synopsis* into this formula:
ja: 技術的に言えば、動詞のフレーズに対して、これは名詞のフレーズから文章を差し引いたものです。パッケージ\ *名*\ と\ *要約*\ をこの決まり文句に代入できるのがよい見つけ方です:

en: The package *name* provides {a,an,the,some} *synopsis*.
ja: パッケージの\ *名前*\ は\ *概要*\ を提供します。

en: Sets of related packages may use an alternative scheme that divides the synopsis into two parts, the first a description of the whole suite and the second a summary of the package's role within it:
ja: 関連パッケージ群は、概要を 2 つに分けた別の書き方をした方が良いでしょう。最初はその組一式の説明文で、その次はその組内でのパッケージの役割のサマリにします:

en: These synopses follow a modified formula. Where a package "*name*" has a synopsis "*suite* (*role*)" or "*suite* - *role*", the elements should be phrased so that they fit into the formula:
ja: これらの要約が、手が加えられた決まり文句に続きます。パッケージ "*名*" が、"\ *プログラム一式* (*役割*)" あるいは "*プログラム一式* - *役割*" という要約を持つ場合、要素はフレーズにすべきで、決まり文句に合うようになります:

en: The package *name* provides {a,an,the} *role* for the *suite*.
ja: パッケージ\ *名*\ は、\ *プログラム一式*\ に対する\ *役割*\ を表しています。

en: The long description
ja: 長い説明文 (long description)

en: The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis.
ja: 長い説明文は、ユーザーがパッケージをインストールする前に利用可能な最初の情報です。ユーザーがインストールするか否かを決めるのに必要な情報を、すべて提供する必要があります。ユーザーがパッケージの概要を既に読んでいると仮定してください。

en: The long description should consist of full and complete sentences.
ja: 長い説明文は、完全な文章から成る必要があります。

en: The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical.
ja: 長い説明文の最初の段落は、以下の質問に答えている必要があります: このパッケージは何をするの? ユーザが作業を完了するのに、どのタスクが役に立つの? ─ 技術寄りではない書き方でこれを記述するのが重要です。もちろんパッケージの利用者が必然的に技術者ではない限り、です。

en: Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check it. Both ``ispell`` and ``aspell`` have special modes for checking ``debian/control`` files:
ja: スペルミスや文法の間違いを避けるよう、注意してください。スペルチェックを確実に行ってください。\ ``ispell`` と ``aspell`` の双方に、\ ``debian/control`` ファイルをチェックするための特別なモードがあります:

en: Users usually expect these questions to be answered in the package description:
ja: 通常、ユーザは以下のような疑問がパッケージ説明文で答えられることを期待しています:

en: What does the package do? If it is an add-on to another package, then the short description of the package we are an add-on to should be put in here.
ja: パッケージは何をするの? 他のパッケージのアドオンだった場合、パッケージがアドオンであるということを概要文に書く必要があります。

en: Why should I want this package? This is related to the above, but not the same (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).
ja: なぜこのパッケージを使うべきなの? これは上記に関連しますが、同じではありません (これはメールユーザーエージェントです; クールで速く、PGP や LDAP や IMAP のインターフェイスがあり、X や Y や Z の機能があります)。

en: If this package should not be installed directly, but is pulled in by another package, this should be mentioned.
ja: パッケージが直接インストールされるべきではないが、他のパッケージから引っ張ってこられる時には、付記しておく必要があります。

en: If the package is ``experimental``, or there are other reasons it should not be used, if there are other packages that should be used instead, it should be here as well.
ja: パッケージが\ ``実験的``\ である、あるいは使われない方が良い他の理由がある場合、同様にここに記載する必要があります。

en: Upstream home page
ja: 開発元のホームページ

en: We recommend that you add the URL for the package's home page in the ``Homepage`` field of the ``Source`` section in ``debian/control``. Adding this information in the package description itself is considered deprecated.
ja: ``debian/control`` 中の ``Source`` セクションの ``Homepage`` フィールドへ、パッケージのホームページの URL を追加することをお勧めします。この情報をパッケージ説明文自身に追加するのは推奨されない (deprecated) であると考えられています。

en: Version Control System location
ja: バージョン管理システムの場所

en: There are additional fields for the location of the Version Control System in ``debian/control``.
ja: ``debian/control`` には、バージョン管理システムの場所についての追加フィールドがあります。

en: Value of this field should be a ``https://`` URL pointing to a web-browsable copy of the Version Control System repository used to maintain the given package, if available.
ja: このフィールドの値は、指定したパッケージのメンテナンスに使われているバージョン管理システムのリポジトリのコピーがもしあれば、それを指し示す ``https://`` URL である必要があります。

en: The information is meant to be useful for the final user, willing to browse the latest work done on the package (e.g. when looking for the patch fixing a bug tagged as ``pending`` in the bug tracking system).
ja: この情報は、パッケージに行われた最新の作業を閲覧したいエンドユーザにとって有用であるのが目的です (例: バグ追跡システムで ``pending`` とタグがつけられているバグを修正するパッチを探している場合)。

en: The information is meant to be useful for a user knowledgeable in the given Version Control System and willing to build the current version of a package from the VCS sources. Other uses of this information might include automatic building of the latest VCS version of the given package. To this end the location pointed to by the field should better be version agnostic and point to the main branch (for VCSs supporting such a concept). Also, the location pointed to should be accessible to the final user; fulfilling this requirement might imply pointing to an anonymous access of the repository instead of pointing to an SSH-accessible version of the same.
ja: この情報は、そのバージョン管理システムについて知識があり、VCS ソースから現在のバージョンパッケージを生成ユーザにとって有益であるよう意図されています。この情報の他の使い方としては、指定されたパッケージの最新の VCS バージョンを自動ビルドするなどがあるかもしれません。このため、フィールドによって指し示される場所は、バージョンに関係なく、(そのようなコンセプトをサポートしている VCS であれば) メインブランチを指すのが良いでしょう。また、指し示される場所は一般ユーザがアクセス可能である必要があります; この要求を満たすには SSH アクセス可能なリポジトリを指すのではなく、匿名アクセスが可能なリポジトリを指すようにすることを意味します。

en: Best practices for ``debian/changelog``
ja: ``debian/changelog`` のベストプラクティス

en: The following practices supplement the `Policy on changelog files <https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs>`__.
ja: 以下のプラクティスは `changelog ファイルに対するポリシー <https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs>`__\ を補完します。

en: Writing useful changelog entries
ja: 役立つ changelog のエントリを書く

en: The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version.
ja: パッケージリビジョンに対する changelog エントリは、そのリビジョンでの変更それだけを記載します。最後のバージョンから行われた、重要な、そしてユーザに見える形の変更を記述することに集中しましょう。

en: Focus on *what* was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches).
ja: *何が*\ 変更されたかについて集中しましょう — 誰が、どうやって、何時なのか通常あまり重要ではありません。そうは言っても、パッケージ作成について明記すべき手助けをしてくれた人々 (例えば、パッチを送ってくれた人) を丁寧に明記するのを忘れないようにしましょう。

en: There's no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don't be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the ``README.Debian`` file.
ja: 些細で明白な変更を詳細に書く必要はありません。複数の変更点を一つのエントリにまとめることもできます。逆に言えば、大きな変更をした場合には、あまりに簡潔にしすぎないようにしましょう。プログラムの動作に影響を与える変更がある場合には、特に確認しておきましょう。詳細な説明については、\ ``README.Debian`` ファイルを使ってください。

en: Use common English so that the majority of readers can comprehend it. Avoid abbreviations, tech-speak and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear.
ja: 平易な英語を使いましょう。そうすれば読者の大半が理解できます。バグをクローズする変更を説明する際には略語や、テクニカルな言い方やジャーゴンを避けましょう。特に、技術的に精通していないと思われるユーザによって登録されたバグを閉じる際には気をつけましょう。礼儀正しく、断言をしないように。

en: It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards.
ja: 時折、changelog エントリに変更したファイルの名前を頭に付けたくなることがあります。ですが、個々のすべての変更したファイルを一覧にする必要性はありません。特に変更点が小さくて繰り返される場合です。ワイルドカードを使いましょう。

en: When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the closes: #nnnnn string. See :ref:`upload-bugfix` for more information.
ja: バグに触れる際には、何も仮定しないようにしましょう。何が問題だったのか、どうやってそれが直されたのかについて言い、closes: #nnnnn の文字列を追加しましょう。詳細については :ref:`upload-bugfix` を参照してください。

en: Common misconceptions about changelog entries
ja: changelog のエントリに関するよくある誤解

en: The changelog entries should **not** document generic packaging issues (Hey, if you're looking for foo.conf, it's in /etc/blah/.), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file.
ja: changelog エントリは、一般的なパッケージ化の事柄 (ほら、foo.conf を探しているなら /etc/blah にあるよ) を記載するべきでは\ **ありません**\ 。何故なら、管理者やユーザは少なくとも Debian システム上でそのようなことがどのように扱われるかを多少は知らされているでしょうから。ですが、設定ファイルの場所を変更したのであれば、それは一言添えておくべきです。

en: The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See :ref:`upload-bugfix`.
ja: changelog エントリでクローズされるバグは、実際にそのパッケージリビジョンで修正されたものだけにすべきです。changelog で関係ないバグを閉じるのは良くない習慣です。\ :ref:`upload-bugfix` を参照してください。

en: The changelog entries should **not** be used for random discussion with bug reporters (I don't see segfaults when starting foo with option bar; send in more info), general statements on life, the universe and everything (sorry this upload took me so long, but I caught the flu), or pleas for help (the bug list on this package is huge, please lend me a hand). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See :ref:`bug-answering` for more information on how to use the bug tracking system.
ja: changelog エントリは、バグ報告者との各種の議論の場 (foo をオプション bar 付きで起動した際にはセグメンテーションフォルトは見られません; もっと詳しい情報を送ってください)、生命、宇宙、そして万物についての概要 (すいませんが、このアップロードに時間がかかったので風邪をひきました)、手助けの求め (このパッケージのバグ一覧は巨大です、手を貸してください) に使うべきでは\ **ありません**\ 。そのようなことは、大抵の場合対象としている読者は気づくことが無く、パッケージで実際にあった変更点の情報について読みたい人々を悩ますことでしょう。どの様にバグ報告システムを使えばいいのかについて、詳細な情報は\ :ref:`bug-answering`\ を参照してください。

en: It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload. As we have version tracking now, it is enough to keep the NMUed changelog entries and just mention this fact in your own changelog entry.
ja: 正式なメンテナによるアップロードの changelog エントリの最初で、non-maintainer upload で修正されたバグを承認するのは、古い慣習です。今はバージョン管理を行っているので、NMU された changelog エントリを残しておいて自分の changelog エントリ中でその事実に触れるだけで十分です。

en: Common errors in changelog entries
ja: changelog のエントリ中のよくある間違い

en: The following examples demonstrate some common errors or examples of bad style in changelog entries.
ja: 以下の例で、changelog エントリ中のよくある間違いや間違ったスタイルの例を挙げます。

en: This doesn't tell readers anything too useful, obviously.
ja: これは、全く読み手に何も有用なことを教えてくれません。

en: What was the patch about?
ja: 何についてのパッチですか?

en: Overhaul which accomplished what? Is the mention of late night supposed to remind us that we shouldn't trust that code?
ja: 何をオーバーホールしてどうなったのですか? 深夜というのに言及しているのは、私たちにこのコードを信用するなと言いたいのですか?

en: First of all, there's absolutely no need to upload the package to convey this information; instead, use the bug tracking system. Secondly, there's no explanation as to why the report is not a bug.
ja: まず初めに、この情報を伝えるためにパッケージをアップロードする必要は、全くありません; 代わりにバグ追跡システムを使ってください。次に、何故この報告がバグではなかったのかについての説明がありません。

en: Where's the description? If you can't think of a descriptive message, start by inserting the title of each different bug.
ja: 説明はどこ? 説明文を考えられないのなら、それぞれのバグのタイトルを入れるところから始めてください。

en: Supplementing changelogs with ``NEWS.Debian`` files
ja: ``NEWS.Debian`` ファイルで changelog を補足する

en: Important news about changes in a package can also be put in ``NEWS.Debian`` files. The news will be displayed by tools like ``apt-listchanges``, before all the rest of the changelogs. This is the preferred means to let the user know about significant changes in a package. It is better than using ``debconf`` notes since it is less annoying and the user can go back and refer to the ``NEWS.Debian`` file after the install. And it's better than listing major changes in ``README.Debian``, since the user can easily miss such notes.
ja: パッケージの変更に関する重要なニュースは ``NEWS.Debian`` ファイルにも書くことができます。このニュースは ``apt-listchanges`` のようなツールで、残りすべての changelog の前に表示されます。これは、ユーザにパッケージ内の著しい変更点について知らせるのに好ましいやり方です。インストール後にユーザが一旦戻って ``NEWS.Debian`` ファイルを参照できるので、\ ``debconf`` の notes を使うより良いです。そして、目立った変更点を ``README.Debian`` に列挙するより良いです。何故ならば、ユーザは容易にそのような注意書きを見逃すからです。

en: The file format is the same as a debian changelog file, but leave off the asterisks and describe each news item with a full paragraph when necessary rather than the more concise summaries that would go in a changelog. It's a good idea to run your file through ``dpkg-parsechangelog`` to check its formatting as it will not be automatically checked during build as the changelog is. Here is an example of a real ``NEWS.Debian`` file:
ja: ファイル形式は debian changelog ファイルと同じですが、アスタリスク (*) を取って各ニュースを changelog に書くような簡潔な要約ではなく、必要に応じて完全な段落で記述してください。changelog のようにビルド中に自動的にはチェックされないので、ファイルを ``dpkg-parsechangelog`` を実行してチェックするのは良い考えです。実際の ``NEWS.Debian`` ファイルの例が、以下になります:

en: The ``NEWS.Debian`` file is installed as ``/usr/share/doc/``\ *package*\ ``/NEWS.Debian.gz``. It is compressed, and always has that name even in Debian native packages. If you use ``debhelper``, ``dh_installchangelogs`` will install ``debian/NEWS`` files for you.
ja: ``NEWS.Debian`` ファイルは ``/usr/share/doc/``\ *package*\ ``/NEWS.Debian.gz`` ファイルとしてインストールされます。圧縮されていて、Debian ネイティブパッケージ中でも常にこの名前です。\ ``debhelper`` を使う場合は、\ ``dh_installchangelogs`` が ``debian/NEWS`` ファイルをインストールしてくれます。

en: Unlike changelog files, you need not update ``NEWS.Debian`` files with every release. Only update them if you have something particularly newsworthy that user should know about. If you have no news at all, there's no need to ship a ``NEWS.Debian`` file in your package. No news is good news!
ja: changelog ファイルと違って、毎回のリリースごとに ``NEWS.Debian`` ファイルを更新する必要はありません。何か特にユーザが知るべき目新しいことがあったときにのみ、更新してください。全くニュースがない場合、\ ``NEWS.Debian`` ファイルをパッケージに入れてリリースする必要はありません。便りが無いのは良い知らせ、です (No news is good news!)。

en: Best practices around security
ja: セキュリティに関するベストプラクティス

en: Best practices for maintainer scripts
ja: メンテナスクリプトのベストプラクティス

en: Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once.
ja: メンテナスクリプトは冪等でなければなりません。これは、通常は 1 回呼ばれるスクリプトが 2 回呼ばれた場合、何も悪いことが起きないのを保証する必要があるという意味です。

en: Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty.
ja: 標準入出力はログの取得のためにリダイレクトされることがあります (例: パイプへ向けられる)。ですので、これらが tty であることに依存してはいけません。

en: All prompting or interactive configuration should be kept to a minimum. When it is necessary, you should use the ``debconf`` package for the interface. Remember that prompting in any case can only be in the ``configure`` stage of the ``postinst`` script.
ja: 質問や対話的な設定はすべて最小限に止めておく必要があります。必要になった時は、インターフェイスに ``debconf`` パッケージを使いましょう。どのような場合でも、質問は ``postinst`` スクリプトの ``configure`` 段階にのみ、配置することができます。

en: Keep the maintainer scripts as simple as possible. We suggest you use pure POSIX shell scripts. Remember, if you do need any bash features, the maintainer script must have a bash shebang line. POSIX shell or Bash are preferred to Perl, since they enable ``debhelper`` to easily add bits to the scripts.
ja: メンテナスクリプトは、できる限りシンプルなものにしておきましょう。我々は、あなたは純粋な POSIX シェルスクリプトを使っているものだと考えています。覚えておいて欲しいのですが、何かしら bash の機能が必要になったら、メンテナスクリプトは bash のシェバン行にしておく必要があります。スクリプトへ簡単にちょっとした変更を追加するのに ``debhelper`` を使えるので、Perl より POSIX シェル、あるいは Bash の方が好まれます。

en: If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script.
ja: メンテナスクリプトを変更したら、パッケージの削除や二重インストール、purge のテストを確認してください。purge されたパッケージが完全に削除されたことを確認してください。つまり、メンテナスクリプト中で直接／間接を問わず作成されたファイルを削除する必要があるということです。

en: If you need to check for the existence of a command, you should use something like
ja: コマンドの存在をチェックする必要がある場合は、このような感じで行います

en: You can use this function to search ``$PATH`` for a command name, passed as an argument. It returns true (zero) if the command was found, and false if not. This is really the best way, since ``command -v`` is a shell-builtin for many shells and is defined in POSIX.
ja: コマンド名を引数として渡すことで、\ ``$PATH`` の検索するのにこの関数を使うことができます。コマンドが見つかった場合は true (ゼロ) を返し、そうでない場合は false を返します。\ ``command -v``\ は POSIX に定義されていて、多くのシェルで使えるので、これがもっとも汎用性の高いやり方です。

en: Configuration management with ``debconf``
ja: ``debconf`` による設定管理

en: Debconf is a great tool but it is often poorly used. Many common mistakes are listed in the debconf-devel 7 man page. It is something that you must read if you decide to use debconf. Also, we document some best practices here.
ja: debconf は素晴らしいツールですが、しばしば適当に扱われています。多くの共通する失敗は、debconf-devel 7 man ページに記載されています。これは、debconf を使うのを決めた時、あなたが読むべきものです。また、ここではベストプラクティスを記述しています。

en: These guidelines include some writing style and typography recommendations, general considerations about debconf usage as well as more specific recommendations for some parts of the distribution (the installation system for instance).
ja: これらのガイドラインは、ディストリビューションの一部 (例えば、インストールシステム) に関する、より明確な推奨と同様に、幾つかの書き方と体裁に関する推奨、そして debconf の使い方についての一般的な考慮すべき事柄を含んでいます。

en: Do not abuse debconf
ja: debconf を乱用しない

en: Since debconf appeared in Debian, it has been widely abused and several criticisms received by the Debian distribution come from debconf abuse with the need of answering a wide bunch of questions before getting any little thing installed.
ja: debconf が Debian に現れて以来、広く乱用され続けています。そして、debconf の乱用によって、ちょっとしたものをインストールする前に、大量の質問に答える必要があることに由来するいくつもの非難が Debian ディストリビューションに寄せられました。

en: General recommendations for authors and translators
ja: 作者と翻訳者に対する雑多な推奨

en: Write correct English
ja: 正しい英語を書く

en: Most Debian package maintainers are not native English speakers. So, writing properly phrased templates may not be easy for them.
ja: ほとんどの Debian パッケージメンテナはネイティブの英語話者ではありません。ですので、正しいフレーズのテンプレートを書くのは彼らにとっては容易ではありません。

en: Please use (and abuse) ``debian-l10n-english@lists.debian.org`` mailing list. Have your templates proofread.
ja: ``debian-l10n-english@lists.debian.org`` メーリングリストを利用してください (むしろ乱用してください)。テンプレートを査読してもらいましょう。

en: Badly written templates give a poor image of your package, of your work... or even of Debian itself.
ja: 下手に書かれたテンプレートは、パッケージに対して、そしてあなたの作業に対して、さらには Debian それ自体にすら対して、悪い印象を与えます。

en: Avoid technical jargon as much as possible. If some terms sound common to you, they may be impossible to understand for others. If you cannot avoid them, try to explain them (use the extended description). When doing so, try to balance between verbosity and simplicity.
ja: 可能な限り技術的なジャーゴンを避けましょう。いくつかの用語があなたにとっては普通に聞こえても、他の人には理解不可能かもしれません。避けられない場合には、 (説明文を使って) 解説してみましょう。その場合には、冗長さとシンプルさのバランスを取るようにしましょう。

en: Be kind to translators
ja: 翻訳者へ丁寧に接する

en: Please use gettext-based templates. Install ``po-debconf`` on your development system and read its documentation (``man po-debconf`` is a good start).
ja: gettext ベースのテンプレートを使ってください。開発用のシステムに ``po-debconf`` をインストールしてドキュメントを読みましょう (``man po-debconf`` が取っ掛かりとして良いでしょう)。

en: If you plan to do changes to your original templates, please use the notification system provided with the ``po-debconf`` package, namely the ``podebconf-report-po``, to contact translators. Most active translators are very responsive and getting their work included along with your modified templates will save you additional uploads. If you use gettext-based templates, the translator's name and e-mail addresses are mentioned in the PO files headers and will be used by ``podebconf-report-po``.
ja: 大本のテンプレートを変更する予定がある場合、\ ``po-debconf`` パッケージで提供されている、\ ``podebconf-report-po`` という名の通知システムを使って翻訳作業者にコンタクトを取ってください。ほとんどのアクティブな翻訳作業者たちはとても反応が良く、変更を加えたテンプレートに対応するための作業をしてくれ、あなたが追加でアップロードする必要を減らしてくれます。gettext ベースのテンプレートを使っている場合、翻訳作業者の名前とメールアドレスは PO ファイルのヘッダに表示されており、\ ``podebconf-report-po`` によって使われます。

en: A recommended use of that utility is:
ja: このユーティリティの使い方のお勧めの使い方:

en: Giving a deadline to translators is always appreciated, so that they can organize their work. Please remember that some translation teams have a formalized translate/review process and a delay lower than 10 days is considered as unreasonable. A shorter delay puts too much pressure on translation teams and should be kept for very minor changes.
ja: 翻訳作業者に締切りを伝えるのは常にお勧めです。それによって、彼らは作業を調整できます。いくつかの翻訳作業チームは形式化された翻訳／レビュープロセスを整えており、10 日未満の猶予は不合理であると考えられています。より短い猶予期間は強すぎるプレッシャーを翻訳チームに与えるので、非常に些細な変更点に対してのみに留めるべきです。

en: If in doubt, you may also contact the translation team for a given language (debian-l10n-xxxxx@lists.debian.org), or the ``debian-i18n@lists.debian.org`` mailing list.
ja: 迷った場合は、該当の言語の翻訳チーム (debian-l10n-xxxxx@lists.debian.org) か ``debian-i18n@lists.debian.org`` にも問い合わせましょう。

en: Unfuzzy complete translations when correcting typos and spelling
ja: 誤字やミススペルを修正する際に fuzzy を取る

en: When the text of a debconf template is corrected and you are **sure** that the change does **not** affect translations, please be kind to translators and *unfuzzy* their translations.
ja: debconf テンプレートの文章が修正されて、その変更が翻訳に\ **影響しない**\ と\ **確信している**\ 場合には、翻訳作業者を労って翻訳文を *fuzzy を取り除いて*\ ください。

en: If you don't do so, the whole template will not be translated as long as a translator will send you an update.
ja: そうしないと、翻訳作業者が更新をあなたに送るまでテンプレート全体は翻訳されていない状態になります。

en: To *unfuzzy* translations, you can use ``msguntypot`` (part of the ``po4a`` package).
ja: 翻訳を\ *fuzzy ではなくす*\ ために、(\ ``po4a`` パッケージの一部である)\ ``msguntypot`` を使うことができます。

en: Regenerate the POT and PO files.
ja: POT ファイルと PO ファイルを再生成する。

en: Make a copy of the POT file.
ja: POT ファイルのコピーを作成する。

en: Make a copy of all the PO files.
ja: すべての PO ファイルのコピーを作成する。

en: Change the debconf template files to fix the typos.
ja: debconf テンプレートファイルを誤字修正のために変更する。

en: Regenerate the POT and PO files (again).
ja: POT ファイルと PO ファイルを再生成する (もう一度)。

en: At this point, the typo fix fuzzied all the translations, and this unfortunate change is the only one between the PO files of your main directory and the one from the fridge. Here is how to solve this.
ja: この時点では、typo 修正はすべての翻訳を fuzzy にしており、この残念な変更はメインディレクトリの PO ファイルと fridge の PO ファイルのみに適用されている。ここではどの様にしてこれを解決するかを示す。

en: Discard fuzzy translation, restore the ones from the fridge.
ja: fuzzy になった翻訳を捨て、fridge から作り直す。

en: Manually merge the PO files with the new POT file, but taking the useless fuzzy into account.
ja: 手動で PO ファイルと新しい POT ファイルをマージするが、不要な fuzzy を考慮に入れる。

en: Clean up.
ja: ゴミ掃除。

en: Do not make assumptions about interfaces
ja: インターフェイスについて仮定をしない

en: String templates should also avoid mentioning the default values in their description. First, because this is redundant with the values seen by the users. Also, because these default values may be different from the maintainer choices (for instance, when the debconf database was preseeded).
ja: 文字列テンプレートは、説明文中でのデフォルト値について言及することも避けましょう。まず、ユーザによってそして、デフォルト値はメンテナの考え方によって違う場合があるからです (たとえば、debconf データベースが preseed で指定されている場合など)。

en: More generally speaking, try to avoid referring to user actions. Just give facts.
ja: より一般的に言うと、ユーザの行動を参照させるのを避けるようにしましょう。単に事実を与えましょう。

en: Do not use first person
ja: 一人称を使わない

en: Be gender neutral
ja: 性差に対して中立であれ

en: Templates fields definition
ja: テンプレートのフィールド定義

en: This part gives some information which is mostly taken from the debconf-devel 7 manual page.
ja: この章の情報は、ほとんどを debconf-devel 7 マニュアルページから得ています。

en: Results in a free-form input field that the user can type any string into.
ja: ユーザがどのような文字列でも記述可能な自由記述形式の入力フィールドの結果。

en: Prompts the user for a password. Use this with caution; be aware that the password the user enters will be written to debconf's database. You should probably clean that value out of the database as soon as is possible.
ja: ユーザにパスワードの入力を求めます。これを使う場合は注意して使ってください: ユーザが入力したパスワードは debconf のデータベースに書き込まれることに注意してください。おそらく、この値をデータベースから可能な限り早く消す必要があります。

en: A true/false choice. Remember: true/false, **not yes/no**...
ja: true/false の選択です。注意点: true/false であって、\ **yes/no ではありません**...

en: A choice between one of a number of values. The choices must be specified in a field named 'Choices'. Separate the possible values with commas and spaces, like this: ``Choices: yes, no, maybe``.
ja: 複数の値から一つを選びます。選択するものは 'Choices' というフィールド名で指定されている必要があります。利用可能な値をコンマとスペースで区切ってください。以下のようになります: ``Choices: yes, no, maybe``

en: If choices are translatable strings, the 'Choices' field may be marked as translatable by using ``__Choices``. The double underscore will split out each choice in a separate string.
ja: 選択肢が翻訳可能な文字列である場合、'Choices' フィールドは ``__Choices`` を使って翻訳可能であることを示しておくと良いでしょう。2つのアンダースコアは、各選択肢を分かれた文字列に分割してくれます。

en: The ``po-debconf`` system also offers interesting possibilities to only mark **some** choices as translatable. Example:
ja: ``po-debconf`` システムは、翻訳可能な\ **いくつかの**\ 選択肢のみをマークする面白い機能を提供してくれます。例:

en: In that example, only the 'Other' string is translatable while others are acronyms that should not be translated. The above allows only 'Other' to be included in PO and POT files.
ja: この例では、他は頭文字から構成されていて翻訳できませんが、'Other' 文字列だけは翻訳可能です。上記では 'Other' だけが PO および POT ファイルに含めることができます。

en: The debconf templates flag system offers many such possibilities. The po-debconf 7 manual page lists all these possibilities.
ja: debconf テンプレートのフラグシステムは、この様な機能をたくさん提供します。po-debconf 7 マニュアルページでは、これらの利用可能な機能をすべて列挙しています。

en: Like the select data type, except the user can choose any number of items from the choices list (or chose none of them).
ja: select データ型とそっくりですが、ユーザが選択肢一覧からいくつでも項目を選べる (あるいはどれも選ばないこともできる) 点だけが違います。

en: Rather than being a question per se, this datatype indicates a note that can be displayed to the user. It should be used only for important notes that the user really should see, since debconf will go to great pains to make sure the user sees it; halting the install for them to press a key, and even mailing the note to them in some cases.
ja: 本来質問ではありませんが、このデータ型が示すのはユーザに表示することができる覚え書きです。debconf はユーザが必ず参照するようにするため、多大な苦痛を与えることになる (キーを押すためにインストールを休止したり、ある場合にはメモをメールさえする) ので、ユーザが知っておく必要がある重要な記述にのみ使うべきです。

en: This type is now considered obsolete: don't use it.
ja: この type は現状では古すぎるものと考えられています: 使わないでください。

en: It is recommended to use this type for any message that needs user attention for a correction of any kind.
ja: 何かを補正するためにユーザの注意を引く必要があるメッセージに対し、この type を使うのがお勧めです。

en: Description: short and extended description
ja: Description: short および extended 説明文

en: Template descriptions have two parts: short and extended. The short description is in the Description: line of the template.
ja: テンプレート説明文は 2 つのパートに分かれます: short と extended です。短い説明文 (short description) はテンプレートの Description: 行にあります。

en: The short description should be kept short (50 characters or so) so that it may be accommodated by most debconf interfaces. Keeping it short also helps translators, as usually translations tend to end up being longer than the original.
ja: 短い説明文は、ほとんどの debconf インターフェイスに適用するように、短く (50 文字程度に) しておく必要があります。通常、翻訳はオリジナルよりも長くなる傾向にあるので、短くすることは翻訳作業者を助けます。

en: The short description does not necessarily have to be a full sentence. This is part of the keep it short and efficient recommendation.
ja: 短い説明文は完全な文章である必要はありません。これは文章を短くしておき、効率的に推奨を行うためです。

en: The extended description should not repeat the short description word for word. If you can't think up a long description, then first, think some more. Post to debian-devel. Ask for help. Take a writing class! That extended description is important. If after all that you still can't come up with anything, leave it blank.
ja: 拡張された説明文 (extended description) は、短い説明文を一語一句繰り返しをしてはなりません。長い説明文章を思いつかなければ、まず、もっと考えてください。debian-devel に投稿しましょう。助けを求めましょう。文章の書き方講座を受講しましょう! この拡張された説明文は重要です。もし、まったく何も思いつかなければ、空のままにしておきましょう。

en: The extended description should use complete sentences. Paragraphs should be kept short for improved readability. Do not mix two ideas in the same paragraph but rather use another paragraph.
ja: 拡張された説明文は完全な文章である必要があります。段落を短くしておくのは可読性を高めます。同じ段落で 2 つの考えを混ぜてはいけません。代わりに別の段落を書きます。

en: Don't be too verbose. User tend to ignore too long screens. 20 lines are by experience a border you shouldn't cross, because that means that in the classical dialog interface, people will need to scroll, and lot of people just don't do that.
ja: あまり冗長にしないようにしてください。ユーザは長すぎる画面を無視しようとします。経験からすると、20 行が越えてはならない境界です。何故ならば、クラシックなダイアログインターフェイスでは、スクロールする必要がでてくることになり、そして多くの人がスクロールなどしないからです。

en: The extended description should **never** include a question.
ja: 拡張された説明文では、質問を含めては\ **決していけません**\ 。

en: For specific rules depending on templates type (string, boolean, etc.), please read below.
ja: テンプレートの type (string、boolean など) に応じた特別なルールについては、以下を読んでください。

en: This field is optional. It contains the default answer for string, select and multiselect templates. For multiselect templates, it may contain a comma-separated list of choices.
ja: このフィールドはオプションです。これには、string、select あるいは multiselect のデフォルトでの答えが含まれます。multiselect テンプレートの場合、コンマで区切られた選択肢一覧が含まれます。

en: Type field
ja: Type フィールド

en: No specific indication except: use the appropriate type by referring to the previous section.
ja: 特別な指定はありません。一点だけ、その前のセクションを参照して適切な type を使ってください。

en: Description field
ja: Description フィールド

en: Below are specific instructions for properly writing the Description (short and extended) depending on the template type.
ja: 以下は、テンプレートの型に応じて適切な Description (short および extended) を書くための特別な指示です。

en: String/password templates
ja: String/password テンプレート

en: The short description is a prompt and **not** a title. Avoid question style prompts (IP Address?) in favour of opened prompts (IP address:). The use of colons is recommended.
ja: 短い説明文は、プロンプトであってタイトルでは\ **ありません**\ 。質問形式のプロンプト (IP アドレスは?) を避け、代わりに閉じていない形のプロンプト (IP アドレス:) を使ってください。コロン (:) の使用をお勧めします。

en: The extended description is a complement to the short description. In the extended part, explain what is being asked, rather than ask the same question again using longer words. Use complete sentences. Terse writing style is strongly discouraged.
ja: 拡張された説明文は、短い説明文を補足します。拡張の部分では、長い文章を使って同じ質問を繰り返すのではなく、何を質問されているのかを説明します。完全な文章を書いてください。簡潔な書き方は強く忌避されます。

en: Boolean templates
ja: Boolean テンプレート

en: Again, please avoid referring to specific interface widgets. A common mistake for such templates is if you answer Yes-type constructions.
ja: 繰り返しますが、特定のインターフェイスのウィジェットを参照するのを避けてください。このようなテンプレートで良くある間違いは、「はい」と答える形かどうかです。

en: The extended description will complete the short description. It may refer to the available choices. It may also mention that the user may choose more than one of the available choices, if the template is a multiselect one (although the interface often makes this clear).
ja: 拡張された説明文は、短い説明文を完備します。これでは、利用可能な選択肢に言及することがあります。テンプレートが multiselect なものの場合、ユーザが選べる選択肢が 1 つではないことについても言及するかもしれません (インターフェイスが大抵これを明確にはしてくれますが)。

en: Notes
ja: Note

en: The short description should be considered to be a **title**.
ja: 短い説明文は\ **タイトル**\ として扱われます。

en: The extended description is what will be displayed as a more detailed explanation of the note. Phrases, no terse writing style.
ja: 拡張された説明文では、note のより詳細な説明を表示します。フレーズで、簡潔過ぎない書き方です。

en: Choices field
ja: Choices フィールド

en: If the Choices are likely to change often, please consider using the \__Choices trick. This will split each individual choice into a single string, which will considerably help translators for doing their work.
ja: もし Choise が頻繁に変わるようであれば、__Choices という使い方をするのを検討してください。これは個々の選択項目を単一の文字列に分割するので、翻訳作業者が作業を行うのを助けてくれると考えられています。

en: Default field
ja: Default フィールド

en: Example, taken from the geneweb package templates:
ja: geneweb パッケージのテンプレートを例にとってみましょう:

en: Internationalization
ja: 国際化

en: Handling debconf translations
ja: debconf の翻訳を取り扱う

en: Like porters, translators have a difficult task. They work on many packages and must collaborate with many different maintainers. Moreover, most of the time, they are not native English speakers, so you may need to be particularly patient with them.
ja: 移植作業者同様に、翻訳作業者は難しい課題を抱えています。多くのパッケージについて作業を行い、多くの異なったメンテナと共同作業をする必要があります。さらには、ほとんどの場合、彼らはネイティブな英語話者ではないので、あなたは特に忍耐強くあらねばいけないでしょう。

en: Using ``po-debconf``, the translation is stored in ``.po`` files (drawing from ``gettext`` translation techniques). Special template files contain the original messages and mark which fields are translatable. When you change the value of a translatable field, by calling ``debconf-updatepo``, the translation is marked as needing attention from the translators. Then, at build time, the ``dh_installdebconf`` program takes care of all the needed magic to add the template along with the up-to-date translations into the binary packages. Refer to the po-debconf 7 manual page for details.
ja: ``po-debconf`` を使うと、翻訳は ``.po`` ファイルに収められます (``gettext`` による翻訳技術からの引き出しです)。特別なテンプレートファイルには、元の文章と、どのフィールドが翻訳可能かがマークされています。翻訳可能なフィールドの値を変更すると、\ ``debconf-updatepo`` を呼び出すことで、翻訳作業者の注意が必要なように翻訳にマークがされます。そして、生成時には ``dh_installdebconf`` プログラムが、テンプレートに加え、最新の翻訳をバイナリパッケージに追加するのに必要となる魔法について、すべての面倒を見ます。詳細は po-debconf 7 マニュアルページを参照してください。

en: Internationalized documentation
ja: ドキュメントの国際化

en: Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators.
ja: ドキュメントの国際化はユーザにとって極めて重要ですが、多くの労力がかかります。この作業をすべて除去する方法はありませんが、翻訳作業者を気楽にはできます。

en: If you maintain documentation of any size, it is easier for translators if they have access to a source control system. That lets translators see the differences between two versions of the documentation, so, for instance, they can see what needs to be retranslated. It is recommended that the translated documentation maintain a note about what source control revision the translation is based on. An interesting system is provided by `doc-check <https://salsa.debian.org/installer-team/installation-guide/blob/master/scripts/doc-check>`__ in the ``debian-installer`` package, which shows an overview of the translation status for any given language, using structured comments for the current revision of the file to be translated and, for a translated file, the revision of the original file the translation is based on. You might wish to adapt and provide that in your VCS area.
ja: どのようなサイズであれドキュメントをメンテナンスしている場合、翻訳作業者がソースコントロールシステムにアクセスできるのであれば、彼らの作業が楽になるでしょう。翻訳作業者が、ドキュメントの 2 つのバージョン間の違いを見ることができるので、例えば、何を再翻訳すればいいのかがわかるようになります。翻訳されたドキュメントは、翻訳作業がどのソースコントロールリビジョンをベースにしているのかという記録を保持しておくことをお勧めします。\ ``debian-installer`` パッケージ中の `doc-check <https://salsa.debian.org/installer-team/installation-guide/blob/master/scripts/doc-check>`__ では興味深いシステムが提供されています。これは、翻訳すべき現在のリビジョンのファイルに対する構造化されているコメントを使って、指定されたあらゆる言語の翻訳状況の概要を表示し、翻訳されたファイルについては、翻訳がベースにしているオリジナルのファイルのリビジョンを表示します。自分の VCS 領域でこれを導入して利用した方が良いでしょう。

en: Common packaging situations
ja: パッケージ化に於ける一般的なシチュエーション

en: Packages using ``autoconf``/``automake``
ja: ``autoconf``/``automake`` を使っているパッケージ

en: Keeping ``autoconf``'s ``config.sub`` and ``config.guess`` files up to date is critical for porters, especially on more volatile architectures. Some very good packaging practices for any package using ``autoconf`` and/or ``automake`` have been synthesized in ``/usr/share/doc/autotools-dev/README.Debian.gz`` from the ``autotools-dev`` package. You're strongly encouraged to read this file and to follow the given recommendations.
ja: ``autoconf`` の ``config.sub`` および ``config.guess`` を最新に保ちつづけるのは、移植作業者、特により移行中の状況であるアーキテクチャの移植作業者にとって非常に重要です。\ ``autoconf`` や ``automake`` を使うあらゆるパッケージについてのとても素晴らしいパッケージ化における教訓が ``autotools-dev`` パッケージの ``/usr/share/doc/autotools-dev/README.Debian.gz`` にまとめられています。このファイルを読んで書かれている推奨に従うことを強くお勧めします。

en: Libraries
ja: ライブラリ

en: Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. Breakage in a library can result in dozens of dependent packages breaking.
ja: ライブラリは様々な理由から常にパッケージにするのが難しいです。ポリシーは、メンテナンスに楽にし、新しいバージョンが開発元から出た際にアップグレードを可能な限りシンプルであることを確保するため、多くの制約を課しています。ライブラリでの破損は、依存している何十ものパッケージの破損を招き得ます。

en: Documentation
ja: ドキュメント化

en: Be sure to follow the `Policy on documentation <https://www.debian.org/doc/debian-policy/ch-docs.html>`__.
ja: `ドキュメント化のポリシー <https://www.debian.org/doc/debian-policy/ch-docs.html>`__\ に忘れず従ってください。

en: If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package.
ja: あなたのパッケージが XML や SGML から生成されるドキュメントを含んでいる場合、XML や SGML のソースをバイナリパッケージに含めてリリースしないことをお勧めします。ユーザがドキュメントのソースを欲しい場合には、ソースパッケージを引っ張ってくれば良いのです。

en: Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and if output of reasonable quality is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML.
ja: ポリシーではドキュメントは HTML 形式でリリースされるべきであると定めています。我々は、もし手がかからないで問題ない品質の出力が可能であれば、ドキュメントを PDF 形式とテキスト形式でもリリースすることをお勧めしています。ですが、ソースの形式が HTML のドキュメントを普通のテキスト版でリリースするのは、大抵の場合は適切ではありません。

en: Major shipped manuals should register themselves with ``doc-base`` on installation. See the ``doc-base`` package documentation for more information.
ja: リリースされたメジャーなマニュアルは、インストール時に\ ``doc-base``\ で登録されるべきです。詳細については、\ ``doc-base`` パッケージのドキュメントを参照してください。

en: Debian policy (section 12.1) directs that manual pages should accompany every program, utility, and function, and suggests them for other objects like configuration files. If the work you are packaging does not have such manual pages, consider writing them for inclusion in your package, and submitting them upstream.
ja: Debian ポリシー (12.1 章) では、マニュアルページはすべてのプログラム・ユーティリティ・関数に対して付属すべきであり、設定ファイルのようなその他のものについては付属を提案を示しています。もし、あなたがパッケージングをしているものがそのようなマニュアルページを持っていない場合は、パッケージに含めるために記述を行い、開発元 (upstream) へ送付することを検討してください。

en: Specific types of packages
ja: 特定の種類のパッケージ

en: Several specific types of packages have special sub-policies and corresponding packaging rules and practices:
ja: いくつかの特定の種類のパッケージは、特別なサブポリシーと対応するパッケージ化ルールおよびプラクティスを持っています:

en: Emacs related packages have the `emacs policy <https://www.debian.org/doc/packaging-manuals/debian-emacs-policy>`__.
ja: Emacs 関連パッケージには、\ `emacs ポリシー <https://www.debian.org/doc/packaging-manuals/debian-emacs-policy>`__\ があります。

en: Java related packages have their `java policy <https://www.debian.org/doc/packaging-manuals/java-policy/>`__.
ja: Java 関連パッケージには、\ `java ポリシー <https://www.debian.org/doc/packaging-manuals/java-policy/>`__\ があります。

en: Packages providing XML or SGML DTDs should conform to the recommendations found in the ``sgml-base-doc`` package.
ja: XML や SGML DTD を提供しているパッケージは、\ ``sgml-base-doc`` パッケージ中の推奨に従わねばなりません。

en: Lisp packages should register themselves with ``common-lisp-controller``, about which see ``/usr/share/doc/common-lisp-controller/README.packaging``.
ja: lisp パッケージは、パッケージ自身を ``common-lisp-controller`` に登録する必要があります。これについては、\ ``/usr/share/doc/common-lisp-controller/README.packaging`` を参照してください。

en: Architecture-independent data
ja: アーキテクチャ非依存のデータ

en: It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package.
ja: 大量のアーキテクチャ非依存データがプログラムと共にパッケージ化されるのは、良くあることではありません。例えば、音声ファイル、アイコン集、様々な模様の壁紙、その他一般的な画像ファイルです。このデータのサイズがパッケージの残りのサイズと比較して取るに足らないのであれば、おそらくは単一パッケージでひとまとめにしておくのがベストでしょう。

en: Needing a certain locale during build
ja: ビルド中に特定のロケールが必要

en: If you need a certain locale during build, you can create a temporary file via this trick:
ja: ビルド中に特定のロケールを必要とする場合、こんな技を使えば一時ファイルを作成できます:

en: If you set ``LOCPATH`` to the equivalent of ``/usr/lib/locale``, and ``LC_ALL`` to the name of the locale you generate, you should get what you want without being root. Something like this:
ja: ``LOCPATH`` を ``/usr/lib/locale`` と同等のものに、そして ``LC_ALL`` を生成したロケールの名前に設定すれば、root にならなくても欲しいものが手に入ります。こんな感じです:

en: Make transition packages deborphan compliant
ja: 移行パッケージを deboprhan に適合するようにする

en: Deborphan is a program for helping users to detect which packages can safely be removed from the system, i.e. the ones that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections, to hunt down unused libraries. But when passed the right argument, it tries to catch other useless packages.
ja: deborphan は、どのパッケージがシステムから安全に削除できるか、ユーザが検出するのを助けてくれるプログラムです; すなわち、どのパッケージも依存していないものです。デフォルトの動作は、使われていないライブラリを見つけ出すために libs と oldlibs セクションからのみ検索を行います。ですが、正しい引数を渡せば、他の使われていないパッケージを捕らえようとします。

en: So, when you are creating such a package, please make sure to add ``transitional dummy package`` to the short description to make this explicit. If you are looking for examples, just run: ``apt-cache search .|grep dummy`` or ``apt-cache search .|grep transitional``.
ja: ですので、あなたがそのようなパッケージを作る際には、 ``transitional dummy package`` を短い説明文に必ず追加してください。例を探す場合は、以下を実行してください: ``apt-cache search .|grep dummy`` または ``apt-cache search .|grep transitional``

en: Best practices for ``.orig.tar.{gz,bz2,xz}`` files
ja: ``.orig.tar.{gz,bz2,xz}`` についてのベストプラクティス

en: There are two kinds of original source tarballs: Pristine source and repackaged upstream source.
ja: オリジナルのソース tarball には 2 種類あります: 手が入れられていない素のソース (Pristine source) と再パッケージした開発元のソース (repackaged upstream source) です。

en: Pristine source
ja: 手が入れられていないソース (Pristine source)

en: The defining characteristic of a pristine source tarball is that the ``.orig.tar.{gz,bz2,xz}`` file is byte-for-byte identical to a tarball officially distributed by the upstream author. [1]_ This makes it possible to use checksums to easily verify that all changes between Debian's version and upstream's are contained in the Debian diff. Also, if the original source is huge, upstream authors and others who already have the upstream tarball can save download time if they want to inspect your packaging in detail.
ja: 素のソース tarball (pristine source tarball) の特徴の定義は、\ ``.orig.tar.{gz,bz2,xz}`` は、開発元の作者によって公式に配布された tarball と 1 バイトたりとも違わない、というものです。 [1]_ これは、Debian diff 内に含まれているDebian バージョンと開発元のバージョン間のすべての違いを簡単に比較するのにチェックサムを使えるようになります。また、オリジナルのソースが巨大な場合、既に upstream の tarball を持っている upstream の作者と他の者は、あなたのパッケージを詳細に調査したい場合、ダウンロード時間を節約できます。

en: It unpacks the tarball in an empty temporary directory by doing
ja: 以下のようにして空の一時ディレクトリに tarball を展開します

en: If, after this, the temporary directory contains nothing but one directory and no other files, ``dpkg-source`` renames that directory to *packagename*\ ``-``\ *upstream-version*\ ``(.orig)``. The name of the top-level directory in the tarball does not matter, and is forgotten.
ja: もし、この後で、一時ディレクトリが 1 つのディレクトリ以外含まず他にどのファイルも無い場合、\ ``dpkg-source`` はそのディレクトリを *パッケージ名*-*開発元のバージョン*\ (.orig) にリネームします。tarball 中の最上位のディレクトリ名は問題にはされず、忘れられます。

en: Otherwise, the upstream tarball must have been packaged without a common top-level directory (shame on the upstream author!). In this case, ``dpkg-source`` renames the temporary directory *itself* to *packagename*\ ``-``\ *upstream-version*\ ``(.orig)``.
ja: それ以外の場合、upstream の tarball は共通の最上位ディレクトリ無しでパッケージされなくては いけません (upstream の作者よ、恥を知りなさい!)。この場合、\ ``dpkg-source`` は一時ディレクトリ\ *そのもの*\ を *パッケージ名*-*開発元のバージョン*\ (.orig) へリネームします。

en: Repackaged upstream source
ja: upstream のソースをパッケージしなおす

en: You **should** upload packages with a pristine source tarball if possible, but there are various reasons why it might not be possible. This is the case if upstream does not distribute the source as gzipped tar at all, or if upstream's tarball contains non-DFSG-free material that you must remove before uploading.
ja: パッケージは手が入っていない素のソース tarball と共にアップロード\ **すべき**\ ですが、それが可能ではない場合が色々とあります。upstream がソースを gzip 圧縮した tarball を全く配布していない場合や、upstream の tarball が DFSG-free ではない、あなたがアップロード前に削除しなければならない素材を含んでいる場合がこれにあたります。

en: In these cases the developer must construct a suitable ``.orig.tar.{gz,bz2,xz}`` file themselves. We refer to such a tarball as a repackaged upstream source. Note that a repackaged upstream source is different from a Debian-native package. A repackaged source still comes with Debian-specific changes in a separate ``.diff.gz`` or ``.debian.tar.{gz,bz2,xz}`` and still has a version number composed of *upstream-version* and *debian-version*.
ja: この様な場合、開発者は適切な ``.orig.tar.{gz,bz2,xz}`` ファイルを自身で準備する必要があります。この様な tarball を、再パッケージした開発元のソース (repackaged upstream source) と呼びます。再パッケージした開発元のソースでは Debian ネイティブパッケージとは違うことに注意してください。再パッケージしたソースは、Debian 固有の変更点は分割された ``.diff.gz`` または ``.debian.tar.{gz,bz2,xz}`` のままであり、バージョン番号は *開発元のバージョン* と *debian リビジョン* から構成されたままです。

en: There may be cases where it is desirable to repackage the source even though upstream distributes a ``.tar.{gz,bz2,xz}`` that could in principle be used in its pristine form. The most obvious is if *significant* space savings can be achieved by recompressing the tar archive or by removing genuinely useless cruft from the upstream archive. Use your own discretion here, but be prepared to defend your decision if you repackage source that could have been pristine.
ja: 開発元が、原則的にはそのままの形で使える ``.tar.{gz,bz2,xz}`` を配布していたとしても再パッケージをしたくなるという場合がありえます。最も明解なのは、tar アーカイブを再圧縮することや upstream のアーカイブから純粋に使われていないゴミを削除することで、\ *非常に*\ 容量を節約できる時です。ここで慎重になって頂きたいのですが、ソースを再パッケージする場合は、決定を貫く用意をしてください。

en: A repackaged ``.orig.tar.{gz,bz2,xz}``
ja: パッケージしなおした ``.orig.tar.{gz,bz2,xz}`` では、

en: **should not** contain any file that does not come from the upstream author(s), or whose contents has been changed by you. [2]_
ja: 開発元の作者由来ではないファイルや、あなたが内容を変更したファイルを含める\ **べきではありません**\ 。 [2]_

en: **should**, except where impossible for legal reasons, preserve the entire building and portability infrastructure provided by the upstream author. For example, it is not a sufficient reason for omitting a file that it is used only when building on MS-DOS. Similarly, a ``Makefile`` provided by upstream should not be omitted even if the first thing your ``debian/rules`` does is to overwrite it by running a configure script.
ja: 法的理由から不可能であるものを除いて、開発元の作者が提供しているビルドおよび移植作業環境を完全に\ **保全すべき**\ です。例えば、ファイルを省略する理由として MS-DOS でのビルドにしか使われないから、というのは十分な理由にはなりません。同様に、開発元から提供されている ``Makefile`` を省略すべきではありません。たとえ ``debian/rules`` が最初にすることが configure スクリプトを実行してそれを上書きすることであったとしても、です。

en: (*Rationale:* It is common for Debian users who need to build software for non-Debian platforms to fetch the source from a Debian mirror rather than trying to locate a canonical upstream distribution point).
ja: (*理由:* Debian 以外のプラットフォームのためにソフトウェアをビルドする必要がある Debian ユーザが、開発元の一次配布先を探そうとせずに Debian ミラーからソースを取得する、というのは普通です)。

en: **should** be compressed with ``xz`` (or ``gzip`` or ``bzip``) with maximal compression.
ja: ``xz`` あるいは ``gzip`` あるいは ``bzip`` で最大限\ **圧縮されるべき**\ です。

en: Changing binary files
ja: バイナリファイルの変更

en: Best practices for debug packages
ja: デバッグパッケージのベストプラクティス

en: Note that the debug package should depend on the package that it provides debugging symbols for, and this dependency should be versioned. For example:
ja: デバッグパッケージは、そのパッケージがデバッグシンボルを提供するパッケージに依存する必要があり、この依存関係はバージョン指定が必要であるということに注意してください。以下のような例になります:

en: Best practices for meta-packages
ja: メタパッケージのベストプラクティス

en: A meta-package is a mostly empty package that makes it easy to install a coherent set of packages that can evolve over time. It achieves this by depending on all the packages of the set. Thanks to the power of APT, the meta-package maintainer can adjust the dependencies and the user's system will automatically get the supplementary packages. The dropped packages that were automatically installed will be also be marked as removal candidates (and are even automatically removed by ``aptitude``). ``gnome`` and ``linux-image-amd64`` are two examples of meta-packages (built by the source packages ``meta-gnome2`` and ``linux-latest``).
ja: メタパッケージは、時間がかかる一貫したセットのパッケージをインストールするのを楽にしてくれる、ほぼ空のパッケージです。そのセットの全パッケージに依存することで、これを実現しています。APT の力のおかげで、メタパッケージのメンテナは依存関係を調整すればユーザのシステムが自動的に追加パッケージを得ることができます。自動的にインストールされていてメタパッケージから落とされたパッケージは、削除候補としてマークされます (そして ``aptitude`` によって自動的に削除もされます)。\ ``gnome`` と ``linux-image-amd64`` は、メタパッケージの 2 つの例です (ソースパッケージ ``meta-gnome2`` and ``linux-latest`` から生成されています)。
