PostgreSQL プログラムは（サーバ、クライアントともに） メッセージが翻訳されていた場合、好みの言語でそのメッセージを出すことが できます。翻訳メッセージセットの作成と保守は、その言語を理解し PostgreSQL の成果に貢献したい人間の手伝いが必要です。 この作業にはプログラマである必要は全くありません。この節では手伝いの しかたを説明します。
協力者の言語の熟練度については判断しません。この節ではソフトウェアツール についてを説明します。理論的には、テキストエディタのみが必要です。しかし、 これは自分で作成した翻訳メッセージを試そうとはしないという、あまりあり 得ない場合のみです。ソースツリーを構築する際に、--enable-nls オプションを使用していることを確認して下さい。これにより、全てのエンドユーザ がとにかく必要とする、libintl ライブラリと msgfmt プログラムが検査されます。作業を試す際には、 インストール手順の適切な部分に従って下さい。
新規に翻訳作業を始め,（後述の）メッセージカタログのマージを行ないたい場合、 GNU 版と互換性を持った実装の xgettext と msgmerge という両方のプログラムが必要です。将来は パッケージ化されたソース配布物を使用する場合に 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 メッセージはエンドユーザからは利用できないことに注意して下さい。 もう一つのフラグは 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 エントリはインストールされないことを忘れないで下さい。 これらは何が正しい翻訳になりえるかを示す参照のためのみ提供されています。
以下に、翻訳の編集を行なう際に注意すべき点を示します。
元の文字列の終端が改行の場合、翻訳も同様になっていることを確認して下さい。 tab なども同様です。
元が printf 形式文字列の場合、翻訳も同じでなければなりません。 また、翻訳は同じ形式識別子を同じ順番で持たなければなりません。言語固有の規則 によっては不可能な場合や扱いづらい場合も起こります。 このような場合は、以下の形式を使用することができます。
msgstr "Die Datei %2$s hat %1$u Zeichen."
そして、リストの最初のプレースホルダが実際にはこのリストの 2 番目 の引数に使用されます。 digits$ は % の直後に 続く必要があり、他の形式の操作の前に使用する必要があります。 （この機能は printf ファミリ関数に本当に存在 するものです。メッセージ国際化以外ではほとんど使用されませんので、 聞いたことがないかもしれません。）
元の文字列に言語上の間違いがある場合、それを報告（もしくは プログラムソースを直し、）通常に翻訳して下さい。修正された 文字列は、プログラムのソースが修正された時にマージ可能になります。 元の文字列が事実と異なる場合、それを報告（もしくは自ら直し）翻訳を 行なわないで下さい。その代わりに、PO ファイルのその文字列にコメント を付けて下さい。
元の文字列のスタイルや調子を維持して下さい。特に、 （cannot open file %s など）文章になっていない メッセージは、（翻訳する言語が大文字小文字を区別するのであれば） おそらく最初の文字を大文字にしてはなりませんし、（翻訳する言語が 句読点として使用しているのであれば）ピリオドを終りに付けてはいけません。 項45.3 を読むと参考になります。
メッセージの意味が分からない時や、曖昧な場合は、開発者用のメーリングリスト に問い合わせて下さい。英語を話すエンドユーザも理解できない、または、曖昧で あると判断することができる機会となりメッセージの改良を行なう最善のものです。