The primary message should be short, factual, and avoid reference to implementation details such as specific function names. <quote>Short</quote> means <quote>should fit on one line under normal conditions</quote>. Use a detail message if needed to keep the primary message short, or if you feel a need to mention implementation details such as the particular system call that failed. Both primary and detail messages should be factual. Use a hint message for suggestions about what to do to fix the problem, especially if the suggestion might not always be applicable. 主メッセージは、簡潔に事実を示すものにすべきです。 特定の関数名など実装の詳細への参照は止めるべきです。 「簡潔」は「ごく普通の条件下で1行に収まる」ことを意味します。 主メッセージを簡潔にするために必要であれば、また、特定のシステムコールが失敗したなど実装の詳細について記載したいのであれば、詳細メッセージを使用してください。 主メッセージ、詳細メッセージの両方は事実を示すものにすべきです。 どうすれば問題を解決できるかに関する提言には、その提言が常に適切とは限らない場合は特に、ヒントメッセージを使用してください。

For example, instead of: 例えば、

IpcMemoryCreate: shmget(key=%d, size=%u, 0%o) failed: %m
(plus a long addendum that is basically a hint)

write: ではなく、以下のように記述してください。

Primary:    could not create shared memory segment: %m
Detail:     Failed syscall was shmget(key=%d, size=%u, 0%o).
Hint:       The addendum, written as a complete sentence.

Rationale: keeping the primary message short helps keep it to the point, and lets clients lay out screen space on the assumption that one line is enough for error messages. Detail and hint messages can be relegated to a verbose mode, or perhaps a pop-up error-details window. Also, details and hints would normally be suppressed from the server log to save space. Reference to implementation details is best avoided since users aren't expected to know the details. 理論的根拠： 主メッセージを簡潔にすることは、要点を維持することを助けます。 そして、クライアントは、エラーメッセージ用に1行分確保すれば十分であるという仮定の下で画面設計を行うことができます。 詳細メッセージやヒントメッセージを冗長モードに格下げしたり、エラーの詳細を表示するウィンドウをポップアップさせることもできます。 また、詳細メッセージやヒントメッセージは通常ディスク容量を節約するためにサーバログには出力されません。 ユーザがその詳細を知っているとは期待できないので、実装の詳細への参照を避けることが最善です。

Don't put any specific assumptions about formatting into the message texts. Expect clients and the server log to wrap lines to fit their own needs. In long messages, newline characters (\n) can be used to indicate suggested paragraph breaks. Don't end a message with a newline. Don't use tabs or other formatting characters. (In error context displays, newlines are automatically added to separate levels of context such as function calls.) メッセージテキストの整形に関して、特定の前提を行わないでください。 クライアントやサーバログでは、自身の必要性に合わせて行を改行すると想定してください。 長めのメッセージでは、改行文字（\n）を推奨する段落の区切りを示すものとして使用することができます。 メッセージの終わりに改行を付けないでください。 タブや他の整形用文字を使用しないでください。 （エラーの内容の表示では、関数呼び出しなどのコンテキストのレベルを区切るために、改行が自動的に追加されます。）

Rationale: Messages are not necessarily displayed on terminal-type displays. In GUI displays or browsers these formatting instructions are at best ignored. 理論的根拠： メッセージは必ずしも端末型のディスプレイに表示されるとは限りません。 GUIのディスプレイやブラウザでは、こうした書式指示はうまくいったとしても無視されます。

English text should use double quotes when quoting is appropriate. Text in other languages should consistently use one kind of quotes that is consistent with publishing customs and computer output of other programs. 英文では、引用が適切な場合には二重引用符を使用すべきです。 他の言語でのテキストは、出版上の慣習や他のプログラムのコンピュータ出力と矛盾しない種類の引用符の1つを一貫して使用してください。

Rationale: The choice of double quotes over single quotes is somewhat arbitrary, but tends to be the preferred use. Some have suggested choosing the kind of quotes depending on the type of object according to SQL conventions (namely, strings single quoted, identifiers double quoted). But this is a language-internal technical issue that many users aren't even familiar with, it won't scale to other kinds of quoted terms, it doesn't translate to other languages, and it's pretty pointless, too. 理論的根拠： 二重引用符と単一引用符の選択はどちらかでもよいものですが、推奨する方がよく使われています。 SQL規約（すなわち文字列には単一引用符、識別子には二重引用符）に従って、オブジェクトの種類に応じて引用符を選択することを推奨する人もいます。 しかし、これは言語内部の技術的な事項であり、多くのユーザが理解できるものではありません。 また、他の種類の引用手法には拡張できません。 他の言語へ翻訳できません。 ですので、あまり意味がありません。

Always use quotes to delimit file names, user-supplied identifiers, configuration variable names, and other variables that might contain words. Do not use them to mark up variables that will not contain words (for example, operator names). 《マッチ度[84.100418]》ファイル名、ユーザ提供の識別子、その他の変数に単語が含まれている可能性がある場合には、必ず引用符で区切ってください。 単語を含まない変数（例えば演算子名）をマークアップする際には引用符を使用しないでください。 《機械翻訳》ファイル名、ユーザ-提供される識別子、設定変数名、および単語を含む可能性のあるその他の変数を区切るには、常に引用符を使用します。 単語を含まない変数（例の場合は演算子名）を区切るために引用符を使用しないでください。 マーク

There are functions in the backend that will double-quote their own output as needed (for example, <function>format_type_be()</function>). Do not put additional quotes around the output of such functions. バックエンドには必要に応じて出力に二重引用符を付与する関数(例えばformat_type_be())があります。 こうした関数の出力の前後にさらに引用符を追加しないでください。

Rationale: Objects can have names that create ambiguity when embedded in a message. Be consistent about denoting where a plugged-in name starts and ends. But don't clutter messages with unnecessary or duplicate quote marks. 理論的根拠： オブジェクトの名前をメッセージ内に埋め込む際に曖昧さが生じることがあります。 埋め込む名前がどこから始まりどこで終わるかついての表記には一貫性を持たせてください。 しかし、不必要にメッセージをまとめたり、引用符を二重にすることは止めてください。

The rules are different for primary error messages and for detail/hint messages: この規則は、主エラーメッセージと詳細/ヒントメッセージとで異なります。

Primary error messages: Do not capitalize the first letter. Do not end a message with a period. Do not even think about ending a message with an exclamation point. 主エラーメッセージ： 最初の文字を大文字にしないでください。 メッセージの最後にピリオドを付けないでください。 メッセージの終わりに感嘆符を付けようとは考えないでください。

Detail and hint messages: Use complete sentences, and end each with a period. Capitalize the first word of sentences. Put two spaces after the period if another sentence follows (for English text; might be inappropriate in other languages). 詳細メッセージとヒントメッセージ： 完全な文章を使用し、終わりにピリオドを付けてください。 文章の最初の単語は大文字にしてください。 他の文が続く場合はピリオドの後に空白を2つ入れてください（英文の場合です。他の言語では不適切かもしれません）。

Error context strings: Do not capitalize the first letter and do not end the string with a period. Context strings should normally not be complete sentences. エラー文脈文字列: 先頭文字を大文字にせず、また、終わりにはピリオドを付けないでください。 文脈文字列は通常完全な文章にすべきではありません。

Rationale: Avoiding punctuation makes it easier for client applications to embed the message into a variety of grammatical contexts. Often, primary messages are not grammatically complete sentences anyway. (And if they're long enough to be more than one sentence, they should be split into primary and detail parts.) However, detail and hint messages are longer and might need to include multiple sentences. For consistency, they should follow complete-sentence style even when there's only one sentence. 理論的根拠： 句読点の禁止により、クライアントアプリケーションでは、そのメッセージを各種文法的なコンテキストに埋め込みやすくなります。 主メッセージはしばしば文法的に完全な文章になっていません。 （そして、1行以上の長さになりそうであれば、主メッセージと詳細メッセージに分割すべきです。） しかし、詳細メッセージとヒントメッセージは、より長く、かつ複数の文章を持つ必要があるかもしれません。 一貫性のため、これらは、たとえ文章が1つだけであっても、完全な文章形式に従うべきです。

Use lower case for message wording, including the first letter of a primary error message. Use upper case for SQL commands and key words if they appear in the message. メッセージの言葉使いでは小文字を使用してください。 主エラーメッセージの場合は先頭文字も含みます。 SQLコマンドとキーワードがメッセージ内に出現する場合は大文字を使用してください。

Rationale: It's easier to make everything look more consistent this way, since some messages are complete sentences and some not. 理論的根拠： メッセージは完全な文章かもしれませんし、そうではないかもしれませんので、この方法は、より簡単にすべての見た目の一貫性を向上します。

Use the active voice. Use complete sentences when there is an acting subject (<quote>A could not do B</quote>). Use telegram style without subject if the subject would be the program itself; do not use <quote>I</quote> for the program. 能動態を使用してください。 能動的な主語がある（「AはBを行うことができない」）場合は完全な文章を使用してください。 主語がプログラム自体である場合は、主語を付けずに電報様式を使用してください。 プログラムに「I（私）」を使用しないでください。

Rationale: The program is not human. Don't pretend otherwise. 理論的根拠： プログラムは人間ではありません。 他を真似ないでください。

Use past tense if an attempt to do something failed, but could perhaps succeed next time (perhaps after fixing some problem). Use present tense if the failure is certainly permanent. 試行が失敗したが、次は（何らかの問題を修正した後に）成功するかもしれない場合は過去形を使用してください。 失敗が永続するようであれば、現在形を使用してください。

There is a nontrivial semantic difference between sentences of the form: 以下の2つの意味には無視できないほどの違いがあります。

could not open file "%s": %m

and: および

cannot open file "%s"

The first one means that the attempt to open the file failed. The message should give a reason, such as <quote>disk full</quote> or <quote>file doesn't exist</quote>. The past tense is appropriate because next time the disk might not be full anymore or the file in question might exist. 最初のものは、ファイルを開くことに失敗したことを意味します。 メッセージには、「ディスクが一杯」や「ファイルが存在しない」といった、その理由を付けるべきです。 次回はディスクに空きがあるかもしれませんし、問題のファイルが存在するかもしれませんので過去形が適切です。

The second form indicates that the functionality of opening the named file does not exist at all in the program, or that it's conceptually impossible. The present tense is appropriate because the condition will persist indefinitely. 2番目の形式は、そのプログラム内の指定されたファイルを開く機能が存在しない、あるいは、概念的に不可能であることを示します。 この条件は永遠に続きますので現在形が適切です。

Rationale: Granted, the average user will not be able to draw great conclusions merely from the tense of the message, but since the language provides us with a grammar we should use it correctly. 理論的根拠： 仮定ですが、一般的なユーザは単なるメッセージの時制から多くの意味を引き出すことはできないでしょう。 しかし、言語が文法を提供してくれますので、それを正確に使用すべきでしょう。

When citing the name of an object, state what kind of object it is. オブジェクトの名前を引用する時、そのオブジェクトの種類を記載してください。

Rationale: Otherwise no one will know what <quote>foo.bar.baz</quote> refers to. 理論的根拠： さもないと、「foo.bar.baz」が何なのか誰もわかりません。

Square brackets are only to be used (1) in command synopses to denote optional arguments, or (2) to denote an array subscript. 角括弧は、（1）コマンドの概要にて省略可能な引数を表す、（2）配列の添字を表す、ためだけに使用されます。

Rationale: Anything else does not correspond to widely-known customary usage and will confuse people. 理論的根拠： 広く知られる慣習に対応するものがなく、人々を混乱させることになります。

When a message includes text that is generated elsewhere, embed it in this style: メッセージに、他で生成されるテキストを含める場合、以下の様式で埋め込んでください。

could not open file %s: %m

Rationale: It would be difficult to account for all possible error codes to paste this into a single smooth sentence, so some sort of punctuation is needed. Putting the embedded text in parentheses has also been suggested, but it's unnatural if the embedded text is likely to be the most important part of the message, as is often the case. 理論的根拠： すべての起こり得るエラーコードを単一のなめらかな文章に埋め込むことを考えることは困難です。 ですので、何らかの句読点が必要とされます。 括弧の中にテキストを埋め込むこともまた推奨されていますが、よくあるように埋め込むテキストがそのメッセージの最も重要となる場合は不自然です。

Messages should always state the reason why an error occurred. For example: メッセージは常にエラーが発生した理由を記述すべきです。 以下に例を示します。

BAD:    could not open file %s
BETTER: could not open file %s (I/O failure)

If no reason is known you better fix the code. 理由がわからない場合はコードを直すべきです。

Don't include the name of the reporting routine in the error text. We have other mechanisms for finding that out when needed, and for most users it's not helpful information. If the error text doesn't make as much sense without the function name, reword it. エラーテキストには、それを報告したルーチンの名前を含めないでください。 必要に応じて、そのルーチンを見つける他の機構がありますし、また、ほとんどのユーザにとって役に立つ情報ではありません。 関数名がないと、エラーメッセージにあまり意味がないのであれば、言葉使いを変えてください。

BAD:    pg_strtoint32: error in "z": cannot parse "z"
BETTER: invalid input syntax for type integer: "z"

Avoid mentioning called function names, either; instead say what the code was trying to do: 同時に呼び出した関数名の記述も止めてください。 代わりにそのコードが何をしようとしたのかを記述してください。

BAD:    open() failed: %m
BETTER: could not open file %s: %m

If it really seems necessary, mention the system call in the detail message. (In some cases, providing the actual values passed to the system call might be appropriate information for the detail message.) もし本当に必要であれば、詳細メッセージにそのシステムコールを記載してください （詳細メッセージの情報としてシステムコールに実際に渡した値を与えることが適切な場合もあります）。

Rationale: Users don't know what all those functions do. 理論的根拠： ユーザはその関数が何を行うのかを知りません。

Unable.  <quote>Unable</quote> is nearly the passive voice. Better use <quote>cannot</quote> or <quote>could not</quote>, as appropriate. 「Unable」はほとんど受動態です。 「cannot」または「could not」の適切な方を使用してください。

Bad.  Error messages like <quote>bad result</quote> are really hard to interpret intelligently. It's better to write why the result is <quote>bad</quote>, e.g., <quote>invalid format</quote>. 「bad result」といったエラーメッセージは、知的に解釈することが非常に困難です。 結果が「bad」である理由、例えば「invalid format」を記述してください。

Illegal.  <quote>Illegal</quote> stands for a violation of the law, the rest is <quote>invalid</quote>. Better yet, say why it's invalid. 「Illegal」は規則違反を表します。 他は「invalid」です。 より良くするために、なぜ無効なのかについても記述してください。

Unknown.  Try to avoid <quote>unknown</quote>. Consider <quote>error: unknown response</quote>. If you don't know what the response is, how do you know it's erroneous? <quote>Unrecognized</quote> is often a better choice. Also, be sure to include the value being complained of. 「unknown」は極力使用しないでください。 「error: unknown response」について考えてみましょう。 どんな応答であるかわからなければ、どうやって何がエラーなのかわかるでしょうか。 「Unrecognized」を選んだ方が良い場合がしばしばあります。 また、その警告の中に値が含まれていることを確認してください。

BAD:    unknown node type
BETTER: unrecognized node type: 42

<title>Find vs. Exists</title> Find対Exists.  If the program uses a nontrivial algorithm to locate a resource (e.g., a path search) and that algorithm fails, it is fair to say that the program couldn't <quote>find</quote> the resource. If, on the other hand, the expected location of the resource is known but the program cannot access it there then say that the resource doesn't <quote>exist</quote>. Using <quote>find</quote> in this case sounds weak and confuses the issue. プログラムがリソースの場所について無視できないアルゴリズム（例えばパスの検索）を使用し、そのアルゴリズムが失敗した場合、プログラムがリソースを「find」できなかったと記述すべきでしょう。 一方、想定したリソースの場所はわかっているが、プログラムがアクセスできなかった場合は、リソースが「exist」しなかったと記述してください。 この場合に「find」を使用すると、弱く取られ、問題が混乱します。

<title>May vs. Can vs. Might</title> May、Can、Might.  <quote>May</quote> suggests permission (e.g., "You may borrow my rake."), and has little use in documentation or error messages. <quote>Can</quote> suggests ability (e.g., "I can lift that log."), and <quote>might</quote> suggests possibility (e.g., "It might rain today."). Using the proper word clarifies meaning and assists translation. 「May」は許可を示し、文書やエラーメッセージではあまり使われません（たとえば、熊手を借りられます）。 「Can」は能力を示し（たとえば、丸太を持ち上げることができます）、「might」は可能性を示します（たとえば、雨が降るかもしれません）。 意味を明確にし、翻訳を補助するために適切に使用してください。

<title>Contractions</title> 短縮.  Avoid contractions, like <quote>can't</quote>; use <quote>cannot</quote> instead. 「can't」などの短縮は避けてください。 代わりに「cannot」を使用してください。

<title>Non-negative</title> Non-negative（非負）.  Avoid <quote>non-negative</quote> as it is ambiguous about whether it accepts zero. It's better to use <quote>greater than zero</quote> or <quote>greater than or equal to zero</quote>. 0を受け入れるかどうかが不明確なため、「non-negative（非負）」の使用は避けてください。 「0より大きい」または「0以上」を使用することをお勧めします。

Spell out words in full. For instance, avoid: 単語の完全なスペルを使用してください。 例えば、以下は止めてください。

Rationale: This will improve consistency. 理論的根拠： これは一貫性を向上します。

Keep in mind that error message texts need to be translated into other languages. Follow the guidelines in <xref linkend="nls-guidelines"/> to avoid making life difficult for translators. エラーメッセージは他の言語に翻訳される必要があることを忘れないでください。 55.2.2のガイドラインに従い、翻訳者に苦労を強いることを防いでください。