<firstterm>Locale</firstterm> support refers to an application respecting cultural preferences regarding alphabets, sorting, number formatting, etc. <productname>PostgreSQL</productname> uses the standard ISO C and <acronym>POSIX</acronym> locale facilities provided by the server operating system. For additional information refer to the documentation of your system. ロケールのサポートはアルファベット、並び換え、数字の書式など文化的嗜好を配慮したアプリケーションを対象にします。 PostgreSQLは、サーバのオペレーティングシステムが提供する、標準ISO CとPOSIXのロケール機能を使用します。 これ以上の情報についてはお使いのシステムのドキュメントを参照してください。
Locale support is automatically initialized when a database
cluster is created using <command>initdb</command>.
<command>initdb</command> will initialize the database cluster
with the locale setting of its execution environment by default,
so if your system is already set to use the locale that you want
in your database cluster then there is nothing else you need to
do. If you want to use a different locale (or you are not sure
which locale your system is set to), you can instruct
<command>initdb</command> exactly which locale to use by
specifying the <option>--locale</option> option. For example:
ロケールのサポートは、initdbを使用してデータベースクラスタを作成する時に自動で初期化されます。
initdbは、デフォルトでその実行環境のロケール設定に従ってデータベースクラスタを初期化します。
そのため、システムがデータベースクラスタで使用したいロケールを使用するように既に設定してある場合は何も行う必要はありません。
違うロケールを使用したい場合（またはシステムのロケール設定が不明な場合）は、initdbの--localeオプションで希望のロケールを指定することができます。
以下に例を示します。
initdb --locale=sv_SE
This example for Unix systems sets the locale to Swedish
(<literal>sv</literal>) as spoken
in Sweden (<literal>SE</literal>). Other possibilities might include
<literal>en_US</literal> (U.S. English) and <literal>fr_CA</literal> (French
Canadian). If more than one character set can be used for a
locale then the specifications can take the form
<replaceable>language_territory.codeset</replaceable>. For example,
<literal>fr_BE.UTF-8</literal> represents the French language (fr) as
spoken in Belgium (BE), with a <acronym>UTF-8</acronym> character set
encoding.
Unixシステム用のこの例の設定はロケールをスウェーデン（SE）で使用されているスウェーデン語（sv）に合わせています。
他にもen_US（米国英語）やfr_CA（カナダのフランス語）などの設定もできます。
ロケールに複数の文字セットが使用可能であれば、language_territory.codesetのように記述することができます。
例えば、fr_BE.UTF-8はベルギー（BE）で使用されているフランス語（fr）でUTF-8の文字セットを表します。
What locales are available on your
system under what names depends on what was provided by the operating
system vendor and what was installed. On most Unix systems, the command
<literal>locale -a</literal> will provide a list of available locales.
Windows uses more verbose locale names, such as <literal>German_Germany</literal>
or <literal>Swedish_Sweden.1252</literal>, but the principles are the same.
お使いのシステムでどのロケールがどういう名前で使えるかはオペレーティングシステムのベンダがどのようなものを提供しているかと、何がインストールされているかに依存します。
ほとんどのUnixシステムでは、locale -aというコマンドで利用可能なロケールの一覧を入手できます。
Windowsは、German_GermanyやSwedish_Sweden.1252のようなもっと冗長なロケール名を使用しますが、原理は同じです。
Occasionally it is useful to mix rules from several locales, e.g., use English collation rules but Spanish messages. To support that, a set of locale subcategories exist that control only certain aspects of the localization rules: 英語の照合順序規則でスペイン語のメッセージを使用する時など、時として複数のロケールの規則を併用すると便利です。 これをサポートするために、ロケールには以下のような多言語対応規則の特定の箇所だけを管理する一連のサブカテゴリがあります。
LC_COLLATE | 文字列の並び換え順 |
LC_CTYPE | 文字の分類（文字とはどんなもの？大文字小文字を区別しない？） |
LC_MESSAGES | メッセージの言語 |
LC_MONETARY | 通貨書式 |
LC_NUMERIC | 数字の書式 |
LC_TIME | 日付と時刻の書式 |
The category names translate into names of
<command>initdb</command> options to override the locale choice
for a specific category. For instance, to set the locale to
French Canadian, but use U.S. rules for formatting currency, use
<literal>initdb --locale=fr_CA --lc-monetary=en_US</literal>.
これらのカテゴリの名前は、特定のカテゴリについてのロケールの選択を上書きするためのinitdbオプションの名前としてそのまま使用できます。
例えば、ロケールをカナダのフランス語に設定しながら通貨書式については米国の規則を使用するには、initdb --locale=fr_CA --lc-monetary=en_USとします。
If you want the system to behave as if it had no locale support,
use the special locale name <literal>C</literal>, or equivalently
<literal>POSIX</literal>.
システムがロケールをサポートしていないように動作させたい場合は、特別なロケールのC、もしくは同等なPOSIXを使用してください。
Some locale categories must have their values
fixed when the database is created. You can use different settings
for different databases, but once a database is created, you cannot
change them for that database anymore. <literal>LC_COLLATE</literal>
and <literal>LC_CTYPE</literal> are these categories. They affect
the sort order of indexes, so they must be kept fixed, or indexes on
text columns would become corrupt.
(But you can alleviate this restriction using collations, as discussed
in <xref linkend="collation"/>.)
The default values for these
categories are determined when <command>initdb</command> is run, and
those values are used when new databases are created, unless
specified otherwise in the <command>CREATE DATABASE</command> command.
一部のロケールカテゴリでは、その値がデータベース生成時に固定されていなければならないものがあります。
他のデータベースで他の設定を使用することができますが、一度データベースが生成されると、そのデータベースでは変更することができません。
LC_COLLATEとLC_CTYPEがこれらのカテゴリにあてはまります。
これらはインデックスのソート順に影響を及ぼすため、固定されていなければなりません。
さもないと、テキスト型の列上のインデックスは破壊されるでしょう。
（しかし24.2内で述べられているように、照合順序を使用することで、この制限を緩和できます）
initdbが実行された時に、これらのカテゴリのデフォルト値は決定され、CREATE DATABASEコマンドで他を指定しない限り、新しいデータベースが作成されるときにこの値が使用されます。
The other locale categories can be changed whenever desired
by setting the server configuration parameters
that have the same name as the locale categories (see <xref
linkend="runtime-config-client-format"/> for details). The values
that are chosen by <command>initdb</command> are actually only written
into the configuration file <filename>postgresql.conf</filename> to
serve as defaults when the server is started. If you remove these
assignments from <filename>postgresql.conf</filename> then the
server will inherit the settings from its execution environment.
その他のロケールカテゴリは、いつでも、ロケールカテゴリと同じ名前の実行時パラメータを設定することで、希望値に変更できます
（詳細は20.11.2を参照してください）。
initdbで選択された値は、実際のところ、サーバの起動時にデフォルトとして動作するようにpostgresql.conf設定ファイルに書き込まれるだけです。
この代入文をpostgresql.confから削除すると、サーバは実行環境の設定をそのまま使用します。
Note that the locale behavior of the server is determined by the environment variables seen by the server, not by the environment of any client. Therefore, be careful to configure the correct locale settings before starting the server. A consequence of this is that if client and server are set up in different locales, messages might appear in different languages depending on where they originated. サーバのロケールの動作はどのクライアントの環境にも依存せず、サーバが参照できる環境変数で決まります。 ですからサーバを稼働させる前に正しいロケール設定を行うように注意してください。 結果としてサーバとクライアントで異なるロケールが設定されていると、メッセージはそれらがどこから生じたかによって、異なる言語で表示されます。
When we speak of inheriting the locale from the execution
environment, this means the following on most operating systems:
For a given locale category, say the collation, the following
environment variables are consulted in this order until one is
found to be set: <envar>LC_ALL</envar>, <envar>LC_COLLATE</envar>
(or the variable corresponding to the respective category),
<envar>LANG</envar>. If none of these environment variables are
set then the locale defaults to <literal>C</literal>.
実行環境のロケールをそのまま使用するということは、ほとんどのオペレーティングシステムでは次のような意味を持ちます。
指定されたロケールカテゴリ（例えば照合順序）について、設定するものが見つかるまで、以下の環境変数がこの順番で調べられます。LC_ALL、LC_COLLATE（またはそれぞれのカテゴリに対応する変数）、LANG。
これらのいずれの環境変数も設定されない場合に、ロケールはデフォルトでCに設定されます。
Some message localization libraries also look at the environment
variable <envar>LANGUAGE</envar> which overrides all other locale
settings for the purpose of setting the language of messages. If
in doubt, please refer to the documentation of your operating
system, in particular the documentation about
<application>gettext</application>.
メッセージの言語を設定する目的で、メッセージ多言語化ライブラリの中には全てのロケール設定を上書きする環境変数LANGUAGEを検索するものがあります。
お使いのシステムでの挙動が不明ならばより詳細な情報を得るためお使いのオペレーティングシステムの文書、特にgettextの文書を参照してください。
To enable messages to be translated to the user's preferred language,
<acronym>NLS</acronym> must have been selected at build time
(<literal>configure --enable-nls</literal>). All other locale support is
built in automatically.
ユーザの選択した言語にメッセージを翻訳できるようにするためにはNLSを構築時に有効にする（configure --enable-nls）必要があります。
他のロケールサポートはすべて自動的に構築されます。
The locale settings influence the following SQL features: ロケールの設定は以下のSQL機能に影響を与えます。
Sort order in queries using <literal>ORDER BY</literal> or the standard
comparison operators on textual data
<indexterm><primary>ORDER BY</primary><secondary>and locales</secondary></indexterm>
文字列データに対するORDER BYまたは標準の比較演算子を使用した問い合わせにおける並べ替え順
The <function>upper</function>, <function>lower</function>, and <function>initcap</function>
functions
<indexterm><primary>upper</primary><secondary>and locales</secondary></indexterm>
<indexterm><primary>lower</primary><secondary>and locales</secondary></indexterm>
upper、lower、initcap関数
Pattern matching operators (<literal>LIKE</literal>, <literal>SIMILAR TO</literal>,
and POSIX-style regular expressions); locales affect both case
insensitive matching and the classification of characters by
character-class regular expressions
<indexterm><primary>LIKE</primary><secondary>and locales</secondary></indexterm>
<indexterm><primary>regular expressions</primary><secondary>and locales</secondary></indexterm>
（LIKE、SIMILAR TOやPOSIX形式の正規表現といった）パターンマッチング演算子では
ロケールは大文字、小文字を区別せず正規表現の文字クラスによる文字の区別に影響を及ぼします。
The <function>to_char</function> family of functions
<indexterm><primary>to_char</primary><secondary>and locales</secondary></indexterm>
一群のto_char関数
The ability to use indexes with <literal>LIKE</literal> clauses
LIKE節が付いたインデックスを使用する性能
The drawback of using locales other than <literal>C</literal> or
<literal>POSIX</literal> in <productname>PostgreSQL</productname> is its performance
impact. It slows character handling and prevents ordinary indexes
from being used by <literal>LIKE</literal>. For this reason use locales
only if you actually need them.
CやPOSIX以外で、PostgreSQLでロケールを使用する際の欠点は実行速度です。
ロケールは文字の扱いを遅くし、さらにLIKEで通常のインデックスが使用されなくなります。この理由から、本当に必要な時のみロケールを使用してください。
As a workaround to allow <productname>PostgreSQL</productname> to use indexes
with <literal>LIKE</literal> clauses under a non-C locale, several custom
operator classes exist. These allow the creation of an index that
performs a strict character-by-character comparison, ignoring
locale comparison rules. Refer to <xref linkend="indexes-opclass"/>
for more information. Another approach is to create indexes using
the <literal>C</literal> collation, as discussed in
<xref linkend="collation"/>.
C以外のロケールにおいて、PostgreSQLがLIKE句を持つインデックスを使用できるようにする回避方法として、いくつかのカスタム演算子クラスがあります。
これらを用いると、文字と文字を厳密に比較するようなインデックスや、ロケールの比較規則を無視するようなインデックスを作成できます。
詳細は11.10を参照してください。
もうひとつの方法は、24.2内で解説されているようなC照合順序を使用してインデックスを作成することです。
Locales can be selected in different scopes depending on requirements.
The above overview showed how locales are specified using
<command>initdb</command> to set the defaults for the entire cluster. The
following list shows where locales can be selected. Each item provides
the defaults for the subsequent items, and each lower item allows
overriding the defaults on a finer granularity.
ロケールは、要件に応じて異なる範囲で選択できます。
前述の概要では、initdbを使用してロケールを指定し、クラスタ全体のデフォルトを設定する方法を説明しました。
次のリストは、ロケールを選択できる場所を示しています。
各項目は後続の項目のデフォルトを提供し、下位の各項目はより細かい粒度でデフォルトを上書きできます。
As explained above, the environment of the operating system provides the defaults for the locales of a newly initialized database cluster. In many cases, this is enough: If the operating system is configured for the desired language/territory, then <productname>PostgreSQL</productname> will by default also behave according to that locale. 上で説明したように、オペレーティングシステムの環境は、新しく初期化されたデータベースクラスタのロケールのデフォルトを提供します。 多くの場合、これで十分です。 オペレーティングシステムが目的の言語/地域に設定されている場合、PostgreSQLもデフォルトでそのロケールに従って動作します。
As shown above, command-line options for <command>initdb</command>
specify the locale settings for a newly initialized database cluster.
Use this if the operating system does not have the locale configuration
you want for your database system.
上記のように、initdbのコマンドラインオプションでは、新しく初期化されたデータベースクラスタのロケール設定を指定します。
オペレーティングシステムにデータベースシステムに必要なロケール設定がない場合に使用します。
A locale can be selected separately for each database. The SQL command
<command>CREATE DATABASE</command> and its command-line equivalent
<command>createdb</command> have options for that. Use this for example
if a database cluster houses databases for multiple tenants with
different requirements.
ロケールはデータベースごとに個別に選択できます。
SQLコマンドCREATE DATABASEとそれに相当するコマンドラインcreatedbには、そのためのオプションがあります。
これは、データベース・クラスタに、異なる要件を持つ複数のテナントのデータベースが格納されている場合などに使用します。
Locale settings can be made for individual table columns. This uses an SQL object called <firstterm>collation</firstterm> and is explained in <xref linkend="collation"/>. Use this for example to sort data in different languages or customize the sort order of a particular table. ロケール設定は、個々のテーブル列に対して行うことができます。 これは照合順序というSQLオブジェクトを使用します。 このオブジェクトは24.2で説明されています。 たとえば、異なる言語でデータをソートしたり、特定のテーブルのソート順をカスタマイズする場合に使用します。
Finally, locales can be selected for an individual query. Again, this uses SQL collation objects. This could be used to change the sort order based on run-time choices or for ad-hoc experimentation. 最後に、個々の問い合わせに対してロケールを選択できます。 ここでも、SQL照合オブジェクトを使用します。 これは、実行時の選択に基づいて並べ替え順序を変更する場合や、アドホックな実験に使用できます。
<productname>PostgreSQL</productname> supports multiple <firstterm>locale
providers</firstterm>. This specifies which library supplies the locale
data. One standard provider name is <literal>libc</literal>, which uses
the locales provided by the operating system C library. These are the
locales used by most tools provided by the operating system. Another
provider is <literal>icu</literal>, which uses the external
ICU<indexterm><primary>ICU</primary></indexterm> library. ICU locales can
only be used if support for ICU was configured when PostgreSQL was built.
PostgreSQLは複数のロケールプロバイダをサポートします。
これによってどのライブラリがロケールデータを提供するかを決定します。
標準プロバイダの一つはlibcで、オペレーティングシステムのCライブラリが提供するロケールを使用します。
これらのロケールは、オペレーティングシステムが提供するほとんどのツールが使用します。
他のプロバイダとしてはicuがあり、外部のICUライブラリを使います。
ICUロケールは、PostgreSQLがビルドされた際にICUサポートが設定されていた場合にのみ利用可能です。
The commands and tools that select the locale settings, as described
above, each have an option to select the locale provider. The examples
shown earlier all use the <literal>libc</literal> provider, which is the
default. Here is an example to initialize a database cluster using the
ICU provider:
前述のように、ロケール設定を選択するコマンドおよびツールには、それぞれロケール・プロバイダを選択するオプションがあります。
前述の例では、デフォルトであるlibcプロバイダを使用しています。
次に、ICUプロバイダを使用してデータベース・クラスタを初期化する例を示します:
initdb --locale-provider=icu --icu-locale=en
See the description of the respective commands and programs for
details. Note that you can mix locale providers at different
granularities, for example use <literal>libc</literal> by default for the
cluster but have one database that uses the <literal>icu</literal>
provider, and then have collation objects using either provider within
those databases.
詳細は、各コマンドおよびプログラムの説明を参照してください。
異なる粒度でロケール・プロバイダを混在させることもできます。
たとえば、クラスタではデフォルトでlibcを使用しますが、icuプロバイダを使用するデータベースが1つあり、これらのデータベース内でいずれかのプロバイダを使用する照合オブジェクトがあることに注意してください。
Which locale provider to use depends on individual requirements. For most basic uses, either provider will give adequate results. For the libc provider, it depends on what the operating system offers; some operating systems are better than others. For advanced uses, ICU offers more locale variants and customization options. どのロケールプロバイダを使用するかは、個々の要件によって異なります。 ほとんどの基本的な使用方法では、どちらのプロバイダでも十分な結果が得られます。 libcプロバイダの場合は、オペレーティングシステムが提供するものによって異なります。 オペレーティングシステムによっては、より優れたものもあります。 高度な使用方法では、ICUはより多くのロケールバリエーションとカスタマイズオプションを提供します。
The ICU format for the locale name is a <link linkend="icu-language-tag">Language Tag</link>. 《機械翻訳》ロケール名のICU形式は言語タグです。
CREATE COLLATION mycollation1 (provider = icu, locale = 'ja-JP'); CREATE COLLATION mycollation2 (provider = icu, locale = 'fr');
When defining a new ICU collation object or database with ICU as the provider, the given locale name is transformed ("canonicalized") into a language tag if not already in that form. For instance, 《機械翻訳》ICUをプロバイダとして使用して新しいICU照合オブジェクトまたはデータベースを定義する場合、指定されたロケール名がその形式でない場合は、言語タグに変換 (「正規化」) されます。 たとえば、
CREATE COLLATION mycollation3 (provider = icu, locale = 'en-US-u-kn-true'); NOTICE: using standard form "en-US-u-kn" for locale "en-US-u-kn-true" CREATE COLLATION mycollation4 (provider = icu, locale = 'de_DE.utf8'); NOTICE: using standard form "de-DE" for locale "de_DE.utf8"
If you see this notice, ensure that the <symbol>provider</symbol> and
<symbol>locale</symbol> are the expected result. For consistent results
when using the ICU provider, specify the canonical <link
linkend="icu-language-tag">language tag</link> instead of relying on the
transformation.
《機械翻訳》この通知を見たら、providerとlocaleが期待される結果であることを確認してください。
ICUプロバイダを使用するときに一貫した結果を得るには、変換に依存するのではなく、標準の言語タグを指定してください。
A locale with no language name, or the special language name
<literal>root</literal>, is transformed to have the language
<literal>und</literal> ("undefined").
《機械翻訳》言語名前のないロケール、または特別言語名前ルートは、言語und("undefined")を持つように変換されます。
ICU can transform most libc locale names, as well as some other formats, into language tags for easier transition to ICU. If a libc locale name is used in ICU, it may not have precisely the same behavior as in libc. 《機械翻訳》ICUでは、ほとんどのlibcロケール名とその他の形式を言語タグに変換して、ICUへの移行を容易にすることができます。 libcロケール名前がICUで使用されている場合、libcとまったく同じ動作をしないことがあります。
If there is a problem interpreting the locale name, or if the locale name represents a language or region that ICU does not recognize, you will see the following warning: 《機械翻訳》ロケール名の解釈に問題がある場合、またはロケール名がICUが認識しない言語または地域を表す場合は、次の警告が表示されます。
CREATE COLLATION nonsense (provider = icu, locale = 'nonsense'); WARNING: ICU locale "nonsense" has unknown language "nonsense" HINT: To disable ICU locale validation, set parameter icu_validation_level to DISABLED. CREATE COLLATION
<xref linkend="guc-icu-validation-level"/> controls how the message is
reported. Unless set to <literal>ERROR</literal>, the collation will
still be created, but the behavior may not be what the user intended.
icu_validation_levelは、メッセージがどのように報告されるかを制御します。
エラーに設定しない限り、は作成されますが、その動作はが意図したものではない場合があります。
A language tag, defined in BCP 47, is a standardized identifier used to identify languages, regions, and other information about a locale. 《機械翻訳》BCP 47で定義されている言語タグは、言語、識別子、およびロケールに関するその他の情報を識別するために使用される標準化された地域です。
Basic language tags are simply
<replaceable>language</replaceable><literal>-</literal><replaceable>region</replaceable>;
or even just <replaceable>language</replaceable>. The
<replaceable>language</replaceable> is a language code
(e.g. <literal>fr</literal> for French), and
<replaceable>region</replaceable> is a region code
(e.g. <literal>CA</literal> for Canada). Examples:
<literal>ja-JP</literal>, <literal>de</literal>, or
<literal>fr-CA</literal>.
《機械翻訳》基本言語タグは、単にregion-region、または単にregionです。
regionは言語コード(例:frは言語を表します)で、regionは言語コード(例:caはカナダを表します)です。
例:ja-JP、de、またはfr-CA。
言語フランス
Collation settings may be included in the language tag to customize collation behavior. ICU allows extensive customization, such as sensitivity (or insensitivity) to accents, case, and punctuation; treatment of digits within text; and many other options to satisfy a variety of uses. 《機械翻訳》照合順序設定は、言語タグからカスタマイズ照合順序への動作に含まれる場合があります。 ICUでは、アクセント、ケース、および句読点に対するセンシティビティ(または非センシティビティ)、テキスト内の数字の処理、およびさまざまな用途を満たすその他の多くのオプションなど、広範なカスタマイズが可能です。
To include this additional collation information in a language tag,
append <literal>-u</literal>, which indicates there are additional
collation settings, followed by one or more
<literal>-</literal><replaceable>key</replaceable><literal>-</literal><replaceable>value</replaceable>
pairs. The <replaceable>key</replaceable> is the key for a <link
linkend="icu-collation-settings">collation setting</link> and
<replaceable>value</replaceable> is a valid value for that setting. For
boolean settings, the <literal>-</literal><replaceable>key</replaceable>
may be specified without a corresponding
<literal>-</literal><replaceable>value</replaceable>, which implies a
value of <literal>true</literal>.
《機械翻訳》includeタグのこの追加の照合順序情報を言語に追加するには、追加の照合順序設定があることを示す-uを追加し、その後に1つ以上の-key-valueのペアを追加します。
キーは照合順序設定のキーで、valueはその設定の有効な値です。
boolean設定の場合、-keyは対応する-valueを指定せずに指定できます。
これは、trueの値を意味します。
For example, the language tag <literal>en-US-u-kn-ks-level2</literal>
means the locale with the English language in the US region, with
collation settings <literal>kn</literal> set to <literal>true</literal>
and <literal>ks</literal> set to <literal>level2</literal>. Those
settings mean the collation will be case-insensitive and treat a sequence
of digits as a single number:
《機械翻訳》例の場合、言語タグja-US-u-kn-ks-レベル2とは、米国の英語言語を持つロケールを意味し、照合順序設定knは真に設定され、ksはレベル2に設定されています。
これらの設定は、照合順序がケースに依存せず、数字のシーケンスを単一の数字として扱うことを意味します:
CREATE COLLATION mycollation5 (provider = icu, deterministic = false, locale = 'en-US-u-kn-ks-level2'); SELECT 'aB' = 'Ab' COLLATE mycollation5 as result; result -------- t (1 row) SELECT 'N-45' < 'N-123' COLLATE mycollation5 as result; result -------- t (1 row)
See <xref linkend="icu-custom-collations"/> for details and additional examples of using language tags with custom collation information for the locale. 《機械翻訳》ロケールの言語照合順序情報でカスタムタグを使用する詳細および追加の例については、24.2.3を参照してください。
If locale support doesn't work according to the explanation above,
check that the locale support in your operating system is
correctly configured. To check what locales are installed on your
system, you can use the command <literal>locale -a</literal> if
your operating system provides it.
上記の説明に従ってロケールのサポートが正常に動作しない場合、オペレーティングシステムのロケールサポートが正確に設定されているか確認してください。
指定されたロケールがインストールされているかどうか確認するために、オペレーティングシステムが提供していれば、locale -aコマンドを使用することができます。
Check that <productname>PostgreSQL</productname> is actually using the locale
that you think it is. The <envar>LC_COLLATE</envar> and <envar>LC_CTYPE</envar>
settings are determined when a database is created, and cannot be
changed except by creating a new database. Other locale
settings including <envar>LC_MESSAGES</envar> and <envar>LC_MONETARY</envar>
are initially determined by the environment the server is started
in, but can be changed on-the-fly. You can check the active locale
settings using the <command>SHOW</command> command.
PostgreSQLが想定しているロケールを実際に使用しているかどうかを確認してください。
LC_COLLATEとLC_CTYPEの設定はデータベース作成時に決定され、新しいデータベースを作成する方法以外に変更することはできません。
LC_MESSAGESやLC_MONETARYなど他のロケール設定はサーバ起動時の環境変数によって初めに決定されますが、その場で変更することもできます。
SHOWコマンドを使用して、使用中のロケール設定を確認できます。
The directory <filename>src/test/locale</filename> in the source
distribution contains a test suite for
<productname>PostgreSQL</productname>'s locale support.
ソース配布物のsrc/test/localeディレクトリには、PostgreSQLのロケールサポート用の試験一式があります。
Client applications that handle server-side errors by parsing the text of the error message will obviously have problems when the server's messages are in a different language. Authors of such applications are advised to make use of the error code scheme instead. エラーメッセージ内のテキストを解析してサーバ側のエラーを扱っているクライアントアプリケーションでは、サーバのメッセージが異なる言語で記載されると、明らかに問題になります。 こうしたアプリケーションの作者には、エラーコードスキームで代替させることを推奨します。
Maintaining catalogs of message translations requires the on-going efforts of many volunteers that want to see <productname>PostgreSQL</productname> speak their preferred language well. If messages in your language are currently not available or not fully translated, your assistance would be appreciated. If you want to help, refer to <xref linkend="nls"/> or write to the developers' mailing list. メッセージ翻訳のカタログのメンテナンスにはPostgreSQLに選択した言語を話させてみたいという数多くのボランティアのたゆみのない努力を必要としています。 もしあなたの言語が現在使えなかったり完全に翻訳されていない場合、助力をよろしくお願いします。 もし助力していただけるのであれば、第57章を参照するか開発グループのメーリングリストに投稿してください。