PostgreSQLプログラムは（サーバ、クライアントともに）メッセージが翻訳されていた場合、好みの言語でそのメッセージを出すことができます。 翻訳メッセージセットの作成と保守は、その言語を理解しPostgreSQLの成果に貢献したい人間の手伝いが必要です。 この作業にはプログラマである必要はまったくありません。 本節ではお手伝いの仕方を説明します。
協力者の言語の熟練度については判断しません。 本節ではソフトウェアツールについて説明します。 理論的には、テキストエディタのみが必要です。 しかし、これは自分で作成した翻訳メッセージを試そうとはしないという、あまりあり得ない場合のみです。 ソースツリーを構築する際に、--enable-nlsオプションを使用していることを確認してください。 これにより、全てのエンドユーザがとにかく必要とする、libintlライブラリとmsgfmtプログラムが検査されます。 作業を試す際には、インストール手順の適切な部分に従ってください。
新規に翻訳作業を始め、（後述の）メッセージカタログのマージを行いたい場合、GNU版と互換性を持った実装のxgettextとmsgmergeという2つのプログラムが必要です。 将来はパッケージ化されたソース配布物を使用する場合にxgettextを必要としないように変更する予定です （CVS版ではまだこれが必要です）。 現在GNU Gettext 0.10.36以上を推奨します。
使用するマシンのgettextの実装については、文書が一緒に付いてくると思います。 以下のいくつかはおそらく重複していますが、追補すべき詳細についてはその文書を参照してください。
英語による元のメッセージとそれを基に（確かに）翻訳されたメッセージの組み合わせはメッセージカタログに保持されます。 片方は（関連するプログラムはメッセージカタログを共有していますが）各プログラム用の、もう片方は対象とする言語用のものです。 メッセージカタログには2つのファイル形式があります。 1つは"PO"ファイル（移植可能オブジェクト-Portable Object-を意味します）で翻訳者が編集する特別な構文を持った平文ファイルです。 2番目は"MO"ファイル（マシンオブジェクト-Machine Object-を意味します)で対応するPOファイルから生成され、国際化プログラムの実行の際に使用されるバイナリファイルです。 翻訳者は、MOファイルを扱いません。 実際に扱うことは困難です。
メッセージカタログファイルの拡張子は想像していたかもしれませんが.poもしくは.moです。 基本名（拡張子を除いた部分）は、プログラムが伴っている名前、もしくは翻訳目的とする言語の名前のいずれかで、状況によって変わります。 少し混乱するかもしれません。 例えば、psql.po（psql用のPOファイル）、もしくはfr.mo（フランス語用のMOファイル）です。
POファイルの書式を以下に示します。
# comment msgid "original string" msgstr "translated string" msgid "more original" msgstr "another translated" "string can be broken up like this" ...
msgidはプログラムのソースから抽出されます （これは必要はありませんが最も一般的な方法です）。 msgstr行は初期状態では空であり、翻訳者によって使用される文字列が埋め込まれます。 この文字列には、Cスタイルのエスケープ文字を含めることも、上に示したように複数行にまたがって続けることもできます （継続行は必ず行の先頭から始まらなければなりません）。
#文字はコメントを示します。 #文字の直後に空白文字があった場合、それは翻訳者によって保守されるコメントです。 #の直後に非空白文字が付く、自動的に付与されるコメントもあります。 これらは、POファイルに対する操作を行う各種ツールによって保守され、翻訳者の補助を意図しています。
#. automatic comment #: filename.c:1023 #, flags, flags
#.スタイルのコメントはそのメッセージが使用されるソースファイルから抽出されます。
おそらくプログラマが、翻訳者のために追加した、そのようにしてほしいと考える体裁についてなどの情報です。
#:コメントは、ソース内でそのメッセージが使用される正確な場所を示します。
翻訳者はプログラムソースを参照する必要はありませんが、翻訳の正確さに疑問がある場合にソースを参照することができます。
#,コメントは何らかの方法でメッセージを説明するフラグです。
現在、2つのフラグがあります。
そのメッセージがプログラムソースの変更によって古いものとなった可能性がある場合、fuzzyが設定されます。
翻訳者はこれを検証し、fuzzyフラグを削除できます。
fuzzyメッセージはエンドユーザからは利用できないことに注意してください。
もう1つのフラグはc-formatで、そのメッセージがprintf形式の書式テンプレートであることを示します。
これは、翻訳側もプレースホルダの型と同じ番号を持った書式文字列でなければならないことを意味します。
これを検証するツールがあります。
そのキーはc-formatフラグを解除します。
さて、"空の"メッセージカタログをどうやって作成するのでしょうか。 まず、翻訳したいメッセージを持つプログラムが存在するディレクトリに移動します。 nls.mkファイルがあればこのプログラムは翻訳の準備が整っています。
もし、.poファイルが数個既にあれば、誰かがある翻訳作業を行っています。 そのファイルはlanguage.po と名前が付けられています。 ここで、languageはISO 639-1の2文字言語コード（小文字）を表します。 例えば、fr.poはフランス語用です。 1つの言語に複数の翻訳成果が必要である場合そのファイルの名前はlanguage_region.poのようになります。 ここで、regionはISO 3166-1の2文字国コード（大文字）を表します。 例えば、pt_BR.poはブラジルでのポルトガル語用を示します。 翻訳対象とする言語用のファイルがあれば、それを基に作業を始めることができます。
新規に翻訳を始める必要がある場合、以下のコマンドを最初に実行してください。
gmake init-po
これは、progname.potファイルを作成します （.potは"実用の"POファイルと区別するためのものです。 Tは"テンプレート"を意味します）。 このファイルをlanguage.poにコピーして編集します。 新規の言語が利用可能になったことを知らせるために、nls.mkを編集し、言語（もしくは言語と国）コードを以下のように追加してください。
AVAIL_LANGUAGES := de fr
（もちろん他の言語を追加することができます。）
現在のプログラムやライブラリの変更に伴い、メッセージはプログラマによって変更、追加されます。 この場合は始めからやり直す必要はありません。 その代わりに以下のコマンドを実行してください。
gmake update-po
そうすると新しい空のメッセージカタログファイル（最初に使用したpotファイル）が作成され、既存のPOファイルにマージされます。 このマージのアルゴリズムが特定のメッセージに関して確実でない場合、それは上で説明した"fuzzy"となります。 何かが本当にうまく行かなかった場合、古いPOファイルは.po.oldという拡張子が付いて保存されます。
POファイルは普通のテキストエディタで編集することができます。 翻訳者はmsgstrディレクティブの後の引用符の間の部分の変更、コメントの追加、fuzzyフラグの変更のみを行えばよいのです。 Emacsには（予想通り）POモードがあり、非常に使いやすいものです。
POファイルを完全に埋めることは必要ありません。 ソフトウェアは使用できる翻訳がない（もしくは翻訳が空の）場合自動的に元の文字列に戻します。 他の人が作業を引き継ぐことができますので、ソースツリー内に不完全な翻訳を含めることにも問題はありません。 しかし、マージの後のfuzzyフラグを削除することを優先に考えることが推奨されています。 fuzzyエントリはインストールされないことを忘れないでください。 これらは何が正しい翻訳になり得るかを示す参照のためのみ提供されています。
以下に、翻訳の編集を行う際に注意すべき点を示します。
元の文字列の終端が改行の場合、翻訳も同様になっていることを確認してください。 タブなども同様です。
元がprintf書式文字列の場合、翻訳も同じでなければなりません。
また、翻訳は同じ書式識別子を同じ順番で持たなければなりません。
言語固有の規則によっては不可能な場合や扱いづらい場合も起こります。
このような場合は、以下の形式を使用することができます。
msgstr "Die Datei %2$s hat %1$u Zeichen."
そして、リストの最初のプレースホルダが実際にはこのリストの2番目の引数に使用されます。
digits$は%の直後に続く必要があり、他の書式の操作の前に使用する必要があります
（この機能はprintf系の関数に本当に存在するものです。
メッセージ国際化以外ではほとんど使用されませんので、聞いたことがないかもしれません）。
元の文字列に言語上の間違いがある場合、それを報告し（もしくはプログラムソースを直して）、普通に翻訳してください。 修正された文字列は、プログラムのソースが修正された時にマージ可能になります。 元の文字列が事実と異なる場合、それを報告し（もしくは自ら直して）、翻訳を行わないでください。 その代わりに、POファイルのその文字列にコメントを付けてください。
元の文字列のスタイルや調子を維持してください。 特に、（cannot open file %sなど）文章になっていないメッセージは、（翻訳する言語が大文字小文字を区別するのであれば）おそらく最初の文字を大文字にしてはなりませんし、（翻訳する言語が句読点として使用しているのであれば）ピリオドを終わりに付けてはいけません。 項45.3を読むと参考になります。
メッセージの意味がわからない時や、曖昧な場合は、開発者用のメーリングリストに問い合わせてください。 英語を話すエンドユーザも理解できない、または曖昧であると判断することができる機会となり、メッセージの改良を行う最善のものです。