拡張された説明文は、短い説明文を補足します。拡張の部分では、長い文章を使って同じ質問を繰り返すのではなく、何を質問されているのかを説明します。完全な文章を書いてください。簡潔な書き方は強く忌避されます。versions).繰り返しますが、特定のインターフェイスのウィジェットを参照するのを避けてください。このようなテンプレートで良くある間違いは、「はい」と答える形かどうかです。:)拡張された説明文は、短い説明文を完備します。これでは、利用可能な選択肢に言及することがあります。(インターフェイスが大抵これを明確にはしてくれますが)。短い説明文はタイトルとして扱われます。詳細な説明を表示します。フレーズで、簡潔過ぎない書き方です。いう使い方をするのを検討してください。これは個々の選択項目を単一の文字列に分割するので、翻訳作業者が作業を行うのを助けてくれると考えられています。移植作業者同様に、翻訳作業者は難しい課題を抱えています。多くのパッケージについて作業を行い、多くの異なったメンテナと共同作業をする必要があります。ほとんどの場合、彼らはネイティブな英語話者ではないので、あなたは特に忍耐強くあらねばいけないでしょう。よる翻訳技術からの引き出しです)。特別なテンプレートファイルには、元の文章と、どのフィールドが翻訳可能かがマークされています。呼び出すことで、翻訳作業者の注意が必要なように翻訳にマークがされます。プログラムが、テンプレートに加え、最新の翻訳をバイナリパッケージに追加するのに必要となる魔法について、すべての面倒を見ます。マニュアルページを参照してください。ドキュメントの国際化¶ドキュメントの国際化はユーザにとって極めて重要ですが、多くの労力がかかります。この作業をすべて除去する方法はありませんが、翻訳作業者を気楽にはできます。最新に保ちつづけるのは、移植作業者、特により移行中の状況であるアーキテクチャの移植作業者にとって非常に重要です。このファイルを読んで書かれている推奨に従うことを強くお勧めします。ライブラリ¶ライブラリは様々な理由から常にパッケージにするのが難しいです。ポリシーは、メンテナンスに楽にし、新しいバージョンが開発元から出た際にアップグレードを可能な限りシンプルであることを確保するため、多くの制約を課しています。ライブラリでの破損は、依存している何十ものパッケージの破損を招き得ます。ドキュメント化¶ドキュメント化のポリシーに忘れず従ってください。ソースをバイナリパッケージに含めてリリースしないことをお勧めします。ユーザがドキュメントのソースを欲しい場合には、ソースパッケージを引っ張ってくれば良いのです。形式でリリースされるべきであると定めています。形式とテキスト形式でもリリースすることをお勧めしています。ドキュメントを普通のテキスト版でリリースするのは、大抵の場合は適切ではありません。リリースされたメジャーなマニュアルは、インストール時にdoc-baseで登録されるべきです。パッケージのドキュメントを参照してください。マニュアルページはすべてのプログラム・ユーティリティ・関数に対して付属すべきであり、設定ファイルのようなその他のものについては付属を提案を示しています。送付することを検討してください。