(機械翻訳) 国際化とローカリゼーション¶

用語：「国際化」（i18n）は、複数の言語や文化の中で潜在的に表示される可能性のあるユーザインタフェースを備えたソフトウェアを作成する行為です。：term： `Localization`（110n）は国際化されたアプリケーションのユーザインタフェースを特定の*言語や文化的背景で表示するプロセスです。

：app： `Pyramid`は、ボタンやエラーメッセージ、その他のソフトウェア定義やテンプレート定義の値をアプリケーションのユーザの母国語に翻訳するために使用できる、国際化とローカリゼーションのサブシステムを提供します。

変換文字列の作成¶

あなたのソフトウェアを書いている間、Pythonコードに特別なマークアップを挿入することで、システムがテキスト値をアプリケーションのユーザが使用する言語に翻訳することができます。このマークアップは：term： `翻訳文字列`を作成します。翻訳文字列は：app： `Pyramid`翻訳機構の一部としてその仕事に関連する余分な情報を持ち歩いている点を除けば、通常のUnicodeオブジェクトとほとんど同じように動作するオブジェクトです。

`` TranslationString``クラスの使用¶

翻訳文字列を作成する最も基本的な方法は、：class： `pyramid.i18n.TranslationString`呼び出し可能を使用することです：

from pyramid.i18n import TranslationString
ts = TranslationString('Add')

これにより、TranslationStringであるUnicodeのようなオブジェクトが作成されます。

注釈

term： Zope i18nをよく知っている人のために、TranslationStringは` zope.i18nmessageid.Message``オブジェクトのようなものです。しかし、それはサブクラスではありません。 term： `Pylons`や：term： Django` i18nにもっと精通している方は、関連するgettext APIの"lazy "バージョンを使うのと似ています。

：class：〜pyramid.i18n.TranslationString`の最初の引数は msgid``です。それが必要です。これは、特定のローカリゼーションによって提供される翻訳マッピングのキーを表します。 ` msgid``引数は、UnicodeオブジェクトまたはASCII文字列でなければなりません。 msgidはオプションで*置換マーカー*を含むことができます。例えば：

from pyramid.i18n import TranslationString
ts = TranslationString('Add ${number}')

上記の文字列の中で、 `` $ {number} ``は置換マーカーです。翻訳文字列の*マッピング*にあるものに置換されます。マッピングは、置換マーカー自体と同時に供給することができます。

from pyramid.i18n import TranslationString
ts = TranslationString('Add ${number}', mapping={'number':1})

msgidの値に任意の数の置換マーカーを任意の回数追加できます。 *マッピング*の値で置き換えられるマーカーのみが翻訳時に置き換えられます。他は補間されず、文字通り出力されます。

翻訳文字列には、通常、* domain *も含める必要があります。ドメインは、競合する場合に、同じmsgidの他の翻訳との曖昧さを解消するための翻訳カテゴリを表します。

from pyramid.i18n import TranslationString
ts = TranslationString('Add ${number}', mapping={'number':1},
                       domain='form')

上記の翻訳文字列は、 `` form``のドメイン名です。 A：term： `translator`関数は、ドメインを使用して、指定されたドメインの翻訳を含むファイルシステム上の正しい翻訳ファイルを見つけることがよくあります。この場合、私たちのmsgidをドイツ語に翻訳しようとすると、term： `gettext`ファイル内の：term：`翻訳ディレクトリ 'のような翻訳を見つけようとするかもしれません：

locale/de/LC_MESSAGES/form.mo

言い換えれば、ドイツ語の `` form.mo``翻訳ファイルから翻訳を受けたいと思うでしょう。

最後に、TranslationStringコンストラクタは `` default``引数を受け取ります。 `` default``引数が指定された場合、 `` msgid``の使用法を変換文字列の*デフォルト値*に置き換えます。 `` default``が `` None``のとき、TranslationStringに渡される `` msgid``値は暗黙のメッセージ識別子として使われます。メッセージ識別子は翻訳ファイルの翻訳と一致しているので、デフォルトのテキストとは無関係の"不透明"メッセージ識別子で翻訳文字列を作成すると便利です。

from pyramid.i18n import TranslationString
ts = TranslationString('add-number', default='Add ${number}',
                        domain='form', mapping={'number':1})

デフォルトのテキストが使用されている場合、デフォルトのテキストオブジェクトには置換値が含まれている場合があります。

`` TranslationStringFactory``クラスの使用¶

変換文字列を生成する別の方法は、：attr：〜pyramid.i18n.TranslationStringFactory`オブジェクトを使用することです。このオブジェクトは、*翻訳文字列ファクトリ*です。基本的に翻訳文字列ファクトリは、それを使用して生成された：term： `翻訳文字列 'の `domain``値をプリセットします。例えば：

from pyramid.i18n import TranslationStringFactory
_ = TranslationStringFactory('pyramid')
ts = _('add-number', default='Add ${number}', mapping={'number':1})

注釈

変換文字列ファクトリを `` _``という名前に割り当てました。これは翻訳ファイル生成ツールでサポートされる規約です。

：func：〜pyramid.i18n.TranslationStringFactory`の結果に _``を代入した後、 _``を呼び出す結果は：class：〜pyramid.i18n.TranslationString`インスタンスになります。変換文字列ファクトリの代わりに：class：〜pyramid.i18n.TranslationString`コンストラクタが使用された場合に必要だったように、 domain``値が _``に渡されなかったとしても、結果の翻訳文字列の `domain``属性は `pyramid``になります。結果として、前のコード例は、（スペルを除いて）完全に同等です：

from pyramid.i18n import TranslationString as _
ts = _('add-number', default='Add ${number}', mapping={'number':1},
       domain='pyramid')

：class：〜pyramid.i18n.TranslationStringFactory`クラスを使用して、上で提供されているような独自の翻訳文字列ファクトリを設定できます。たとえば、生成された翻訳文字列の ` domain``値を `` form``にプリセットする翻訳文字列ファクトリを作成したい場合は、次のようにします：

from pyramid.i18n import TranslationStringFactory
_ = TranslationStringFactory('form')
ts = _('add-number', default='Add ${number}', mapping={'number':1})

翻訳文字列ファクトリを使用してアプリケーションの一意のドメインを作成することがベストプラクティスです。独自の翻訳ドメインを使用すると、別の人が自分の翻訳ファイルをマージすることなく、アプリケーションを再利用することができます。代わりに、：meth： `pyramid.config.Configurator.add_translation_dirs`メソッドを使って、あなたのパッケージの：term：`翻訳ディレクトリ 'を含めることができます。

注釈

Zopeの国際化に精通している人のために、TranslationStringFactoryは `` zope.i18nmessageid.MessageFactory``オブジェクトによく似ています。しかし、それはサブクラスではありません。

`` gettext``翻訳ファイルの操作¶

：app： Pyramid`翻訳サービスの基礎はGNU：term： gettext`です。アプリケーションのソースコードファイルとテンプレートに翻訳マーカがマークアップされたら、さまざまな種類のgettextファイルを作成して翻訳作業を行うことができます。

注釈

開発者がa：app： Pyramid`アプリケーション内でterm： gettext`：term： message catalog`ファイルを処理するために必要な手順は、a：term： Pylons`開発者が行う必要のある手順に非常に似ています同じ。：ref： `Pylonsの国際化とローカリゼーションのドキュメントを参照してください。 <pylonswebframework:i18n> `を参照してください。

GNU gettextは、翻訳フレームワークでは `` .pot``ファイル、 `` .po``ファイル、 `` .mo``ファイルの3種類のファイルを使います。

`` .pot``（ポータブルオブジェクトテンプレート）ファイル

`` .pot``ファイルは、あなたのプロジェクトのソースコードを検索し、 `` _（） ``関数に渡されるすべての：term： message identifier`を選ぶプログラムによって作成されます：term ： `翻訳ストリング`構造）。すべてのメッセージ識別子のリストは ` .pot``ファイルに置かれます。これは `` .po``ファイルを作るためのテンプレートとして機能します。

`` .po``（Portable Object）ファイル

`` .pot``ファイル中のメッセージのリストは人間によって特定の言語に翻訳されます。結果は `` .po``ファイルとして保存されます。

`` .mo``（マシンオブジェクト）ファイル

`` .po``ファイルは `` .mo``ファイルである機械可読バイナリファイルに変換されます。翻訳を機械コードにコンパイルすると、ローカライズされたプログラムがより早く開始します。

a：app： Pyramid`アプリケーションに関連する：term： gettext`翻訳ファイルは：term： Lingua`と：term： Gettext`です。 LinguaはPythonとChameleonのファイルからi18nの参照を取り除き、 `` .pot``ファイルを作成することができます。 Gettextには更新された `` .pot``ファイルと `` .po``ファイルを `` .mo``にコンパイルする `` msgfmt``から `` .po``ファイルを更新する `` msgmerge``ツールが含まれています。ファイル。

LinguaとGettextのインストール¶

`` gettext``翻訳ファイルの操作に関連するコマンドが正しく動作するためには、：term： Lingua`と：term： Gettext`が同じ環境にインストールされている必要があります：app： `Pyramid `がインストールされています。

UNIXへのインストール¶

Gettextは、UNIXシステムにすでにインストールされていることがよくあります。 `` msgfmt``コマンドが利用可能かどうかをテストすることで、インストールされているかどうかを確認することができます。使用できない場合は、ご使用のOSのパッケージシステムを使用してインストールできます。パッケージ名はほとんど常に `` gettext``です。例えば、DebianやUbuntuのシステムでは、次のコマンドを実行します：

$ sudo apt-get install gettext

Linguaのインストールは、Pythonのパッケージツールを使って行います。：app： Pyramid`アプリケーションをインストールした：term：`仮想環境 'が環境変数 ` $ VENV``にある場合、Linguaを以下のようにインストールすることができます：

$ $VENV/bin/pip install lingua

Windowsへのインストール¶

GettextをWindowsにインストールするにはいくつかの方法があります： Cygwin <http://www.cygwin.com/> `_ collection、または GnuWin32のインストーラを使うことができます<http://gnuwin32.sourceforge.net/packages/gettext.htm> _、または自分でコンパイルしてください。インストールパスが ` $ PATH``に追加されていることを確認してください。

Linguaのインストールは、Pythonのパッケージツールを使って行います。：app： Pyramid`アプリケーションをインストールした：term：`仮想環境 'が環境変数 `％VENV％ ``にある場合、Linguaを以下のようにインストールすることができます：

c:\> %VENV%\Scripts\pip install lingua

コードとテンプレートからのメッセージの抽出¶

Linguaがインストールされたら、app： Pyramid`アプリケーションにあるcode and：term： Chameleon`テンプレートからメッセージカタログテンプレートを抽出することができます。 `` pot-create``コマンドを実行してメッセージを抽出します：

$ cd /file/path/to/myapplication_setup.py
$ mkdir -p myapplication/locale
$ $VENV/bin/pot-create -o myapplication/locale/myapplication.pot src

メッセージカタログの `` .pot``テンプレートは `` myapplication / locale / myapplication.pot``に終ります。

メッセージカタログファイルの初期化¶

`` .pot``ファイルにメッセージを抽出したら（：ref： extraction_messages`を参照）、 .pot``ファイルにあるメッセージのローカライズを開始するには、少なくとも一つの .pot``ファイルを生成する必要があります。 .po``ファイルです。 ` .po``ファイルは特定のロケールへの特定のメッセージの翻訳を表します。 Gettextの `` msginit``コマンドを使って、あらかじめ生成された `` .pot``テンプレートから特定のロケール用の `` .po``ファイルを初期化します：

$ cd /file/path/to/myapplication_setup.py
$ cd myapplication/locale
$ mkdir -p es/LC_MESSAGES
$ msginit -l es -o es/LC_MESSAGES/myapplication.po

これにより、 `` myapplication / locale / es / LC_MESSAGES / myapplication.po``に新しいメッセージカタログ `` .po``ファイルが作成されます。

ファイルがそこにあると、それは人間の翻訳者が作業することができます。これを助ける一つのツールは `Poedit <https://poedit.net/> `_。

app： Pyramid`自体はすべての .po``ファイルの存在を無視しています。実行中のアプリケーションが翻訳を利用できるようにするには、 ` .mo``ファイルが存在しなければなりません。参考文献：ref： `compiling_message_catalog`を参照してください。

カタログファイルの更新¶

アプリケーションに翻訳文字列が追加されたり、翻訳文字列が変更されたりすると、 `` .pot``ファイルの変更に基づいて既存の `` .po``ファイルを更新する必要があります。翻訳されるか、または再翻訳される。

まず、：ref： extracted_messages`に従って .pot``ファイルを再生成します。次に、Gettextから ` msgmerge``コマンドを使います。

$ cd /file/path/to/myapplication_setup.py
$ cd myapplication/locale
$ msgmerge --update es/LC_MESSAGES/myapplication.po myapplication.pot

メッセージカタログファイルのコンパイル¶

最後に、実際のランタイム変換を実行するためのアプリケーションを用意するには、Gettextの `` msgfmt``コマンドを使って `` .po``ファイルを `` .mo``ファイルにコンパイルします：

$ cd /file/path/to/myapplication_setup.py
$ msgfmt -o myapplication/locale/es/LC_MESSAGES/myapplication.mo \
      myapplication/locale/es/LC_MESSAGES/myapplication.po

これにより、アプリケーションの `` .po``ファイルごとに `` .mo``ファイルが作成されます。 `` .mo``ファイルが終わる：term：翻訳ディレクトリ 'があなたのアプリケーションに設定されている限り（これらの翻訳は、app_ `Pyramid `。

ローカライザの使用¶

A：term： localizer`は、アプリケーション内で手で翻訳や複数形変換を行うためのオブジェクトです。：attr： `pyramid.request.Request.localizer`属性を使って：term： localizer`を取得することができます。ローカライザオブジェクトは、active：term： `locale negotiator`によって暗黙の翻訳を生成するように設定されます。明示的ロケールネゴシエーターが登録されていない場合、デフォルトローカライザオブジェクトです。

def aview(request):
    localizer = request.localizer

注釈

ロケール用のローカライザーを作成する必要がある場合は、：func： `pyramid.i18n.make_localizer`関数を使用してください。

翻訳の実行¶

A：term： localizer`は：term：`翻訳文字列 `またはUnicode文字列のいずれかを受け取り、翻訳を表すUnicodeオブジェクトを返す `translate``メソッドを持っています。アプリケーションのビューコンポーネントで翻訳を生成すると、次のようになります。

from pyramid.i18n import TranslationString

ts = TranslationString('Add ${number}', mapping={'number':1},
                       domain='pyramid')

def aview(request):
    localizer = request.localizer
    translated = localizer.translate(ts) # translation string
    # ... use translated ...

`` request.localizer``属性は：class： pyramid.i18n.Localizer`オブジェクトで、要求によって表されるロケール名にバインドされます。：meth： `pyramid.i18n.Localizer.translate`メソッドから返される翻訳は、提供された翻訳文字列のローカライザのロケールと `domain``属性に依存します。

注釈

：term： `Chameleon`テンプレートを使用している場合、このように翻訳文字列をあらかじめ翻訳する必要はありません。参照：ref： `chameleon_translation_strings`を参照してください。

複数化の実行¶

A：term： localizer`は以下のシグネチャを持つ `pluralize``メソッドを持っています：

def pluralize(singular, plural, n, domain=None, mapping=None):
    ...

最も単純なケースは、Unicodeリテラルとして渡される "単数形"と "複数形"の引数です。これは、数字 `` n``のロケール複数化規則に従って適切なリテラルを返し、 `` mapping``を補間します。

def aview(request):
    localizer = request.localizer
    translated = localizer.pluralize('Item', 'Items', 1, 'mydomain')
    # ... use translated ...

しかし、他の言語のサポートのために、 `` singular``引数は：term： message identifier`を表すUnicode値でなければなりません。この場合、 ` plural``値は無視されます。「domain」は：term： translation domain`でなければならず、 `mapping``は翻訳された文字列の* replacement value *補間に使われる辞書でなければなりません。

`` n``の値は現在の言語に対して適切な複数形を見つけるのに使われ、 `` pluralize``はメッセージid `` singular``のUnicode変換を返します。メッセージファイルは、複数形の翻訳として「単数形」を定義していなければなりません。

`` singular``として提供される引数は：term： `translation string`オブジェクトですが、添付されるドメインとマッピング情報は無視されます。

def aview(request):
    localizer = request.localizer
    num = 1
    translated = localizer.pluralize('item_plural', '${number} items',
        num, 'mydomain', mapping={'number':num})

対応するメッセージカタログには、複数の言語定義と複数の代替案が設定されている必要があります。

"Plural-Forms: nplurals=3; plural=n==0 ? 0 : n==1 ? 1 : 2;"

msgid "item_plural"
msgid_plural ""
msgstr[0] "No items"
msgstr[1] "${number} item"
msgstr[2] "${number} items"

複雑な複数形の詳細は、 `gettext documentation <https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-forms.html> `_。

リクエストのロケール名の取得¶

リクエストに関連するロケール名は、リクエストの：func： `pyramid.request.Request.locale_name`属性を使用して取得できます。

def aview(request):
    locale_name = request.locale_name

要求のロケール名は動的に計算されます。ロケールネゴシエーターが `` None``を返す場合、それは現在アクティブな：term： locale negotiator`または：term：`デフォルトロケール名 `によって交渉されるロケール名になります。デフォルトのロケール名は ` pyramid.default_locale_name``の設定を変更することで変更できます。参照：ref： `default_locale_name_setting`を参照してください。

いったん：func：〜pyramid.request.Request.locale_name`が最初に実行されると、ロケール名はリクエストオブジェクトに格納されます。それ以降の：func： `〜pyramid.request.Request.locale_name`の呼び出しは、：term： locale negotiator`を呼び出さずに、格納されたロケール名を返します。このキャッシングを避けるには、：func： `pyramid.i18n.negotiate_locale_name`関数を使用します：

from pyramid.i18n import negotiate_locale_name

def aview(request):
    locale_name = negotiate_locale_name(request)

：term： localizer`の `locale_name``属性を使ってリクエストに関連するロケール名を取得することもできます。

def aview(request):
    localizer = request.localizer
    locale_name = localizer.locale_name

ローカライザの属性としてロケール名を取得することは、：func： `〜pyramid.request.Request.locale_name`属性を要求することによってロケール名を取得することと同じです。

日付書式設定および通貨書式設定の実行¶

：app： Pyramid`はそれ自身で異なるロケールの日付と通貨の書式設定を行いません。しかし、：term： `Babel`は：class： babel.core.Locale`クラスでこれを行うのを助けることができます。このクラスの `Babelのドキュメント<http://babel.pocoo.org/en/latest/api/core.html#basic-interface> `_は、日付と通貨に関連するロケール操作の実行方法に関する最小限の情報を提供します。 Babelのインストール方法については、ref： `installation_babel`を参照してください。

：class： babel.core.Locale`クラスは、コンストラクタへの引数として：term： locale name`を必要とします。：app： Pyramid APIを使って：class：` babel.core.Locale`コンストラクタに渡すリクエストのロケール名を取得できます。参照：ref： `obtain_the_locale_name`を参照してください。例えば：

from babel.core import Locale

def aview(request):
    locale_name = request.locale_name
    locale = Locale(locale_name)

翻訳文字列のカメレオンテンプレートのサポート¶

a：term： `翻訳文字列`がa：term： `Chameleon`テンプレートレンダラーによるテキストレンダリングの対象として使用される場合、適切な翻訳が存在する場合、自動的に要求ユーザの言語に翻訳されます。これは、カメレオンテンプレートレンダラのZPTとテキストバリアントの両方に当てはまります。

たとえば、カメレオンのZPTテンプレートでは、下の各例の"some_translation_string "で表される翻訳文字列がレンダリングされる前に翻訳されます。

<span tal:content="some_translation_string"/>

<span tal:replace="some_translation_string"/>

1	<span>${some_translation_string}</span>

<a tal:attributes="href some_translation_string">Click here</a>

Chameleonの `` i18n``名前空間の属性によって表される機能は：app： `Pyramid`の翻訳も参照します。 https://chameleon.readthedocs.io/en/latest/reference.html#translation-i18nを参照してください。

注釈

Chameleonが：app： Pyramid`の外で使用されているのとは異なり、*：*：app： Pyramid`内で使用された場合、 `` zope.i18n``翻訳フレームワークの使用はサポートされません。 app： Pyramid`を使うアプリケーションは、 `zope.i18n``ではなく、この章で説明している機能を使うべきです。

サードパーティー：app： `Pyramid`テンプレートレンダラーがこのサポートを提供していない可能性があり、同等の機能を実行するために特別なコードが必要な場合があります。そのためには、：ref： `performing_a_translation`で説明されているより手作業の翻訳機能をいつでも使用できます。

マコピラミッドi18nサポート¶

「ピラミッドコミュニティクックブック」という名前のレシピがあります：ref： Mako Internationalization <cookbook:mako_i18n> `は：term： Mako`テンプレートに慣用的なi18nサポートを追加する方法を説明しています。

Jinja2ピラミッドi18nサポート¶

アドオンの pyramid_jinja2 <https://github.com/Pylons/pyramid_jinja2> `_はPyramidのJinja2で国際化を使用する方法の例を足場に提供します。ドキュメントの `内部化（i18n） <https://docs.pylonsproject.org/projects/pyramid-jinja2/en/latest/#internalization-i18n> `_ and Paster Template I18N <https://docs.pylonsproject.org/projects/pyramid-jinja2/en/latest/#paster-template-i18n> `_。

"使用可能な言語の検出"¶

他のシステムでは、APIの呼び出し時にディスク上のすべての翻訳ディレクトリにあるすべての言語の組み合わせで示される"利用可能な言語"のセットを返すAPIが提供されています。

それは設計上のものです：app： `Pyramid`はそのようなAPIを提供しません。代わりに、アプリケーション自体が"利用可能な言語"を知る責任があります。どのような翻訳ファイルがディスク上にあるかにかかわらず、特定のアプリケーション展開では常にどの言語に翻訳できるかを常に把握しておく必要があります。

理由は次のとおりです。この特定の配備で登録されている翻訳ディレクトリ内の特定の言語に翻訳が存在するため、その言語への翻訳を許可したいからです。たとえば、一部の翻訳が存在する可能性がありますが、不完全または間違っている可能性があります。または、ある言語への翻訳があるかもしれませんが、すべての翻訳ドメインではありません。

すべての重要なアプリケーションの配備は、登録された翻訳ディレクトリ内で検出されたすべての言語よりも言語セットが小さい場合でも、いくつかの言語のみを選択できるように選択する必要が常にあります。これを可能にする最も簡単な方法は、翻訳ディレクトリファイル情報からこの情報を抽出するためにフレームワークに頼るのではなく、どの言語を翻訳することができるかをアプリケーションが完全に認識できるようにすることです。

配備者が：mod： `pyramid.settings`メカニズムを使って規約に基づいて利用可能な言語を選択できるようにシステムを設定することができます。

デプロイヤーにアプリケーションの `` .ini``ファイルを変更させる：

[app:main]
use = egg:MyProject
# ...
available_languages = fr de en ru

そして、カスタムのコードの一部として：用語：ロケールネゴシエーター：

from pyramid.settings import aslist

def my_locale_negotiator(request):
    languages = aslist(request.registry.settings['available_languages'])
    # ...

これは単なる提案です。必要に応じて、独自の「使用可能な言語」構成スキームを作成できます。

翻訳の有効化¶

デフォルトでは、a：app： `Pyramid`アプリケーションは翻訳を実行しません。翻訳を有効にするには、以下が必要です。

少なくとも1つ：term： `翻訳ディレクトリ 'をアプリケーションに追加してください。
アプリケーションで：term： `locale name`が正しく設定されていることを確認してください。

翻訳ディレクトリの追加¶

：term： gettext`は：app： Pyramid`翻訳機構の背後にある基礎となる機械です。翻訳ディレクトリは、term： gettext`に役立つように編成されたディレクトリです。翻訳ディレクトリには通常、言語ディレクトリのリストが含まれており、それぞれに ` LC_MESSAGES``ディレクトリがあります。それぞれの `` LC_MESSAGES``ディレクトリには、一つ以上の `` .mo``ファイルが含まれていなければなりません。各 `` .mo``ファイルは、アプリケーションに翻訳を提供するために使用される：term： `message catalog`を表します。

a：term： translation directory`を追加すると：app： Pyramid`アプリケーション内のterm： message catalog`ファイルがすべて翻訳サービスに使用できるように登録されます。これには、翻訳ディレクトリ内の各ロケールディレクトリ内のすべての ` LC_MESSAGES``ディレクトリ内にある `` .mo``ファイルのすべてが含まれます。

アプリケーションの起動時に、：meth： `pyramid.config.Configurator.add_translation_dirs`を使用して、変換ディレクトリを必須に追加できます。例えば：

from pyramid.config import Configurator
config.add_translation_dirs('my.application:locale/',
                            'another.application:locale/')

：meth：〜pyramid.config.Configurator.add_translation_dirs`を介して追加された翻訳ディレクトリ内のメッセージカタログは、両方の翻訳ディレクトリに同じロケールと：term：`翻訳ドメインの翻訳が含まれている場合、以前に追加されたメッセージカタログの翻訳にマージされます。

ロケールの設定¶

*デフォルトのロケールネゴシエーター*（参照：ref： default_locale_negotiator`を参照）が使用されている場合、翻訳を実行する前にこれらのことを実行することによって、現在のロケール名のapp： Pyramid '

要求の `` _LOCALE_``属性を有効なロケール名（通常はビューコード内で直接）に設定します。たとえば、 `` request._LOCALE_ = 'de'``です。
有効なロケール名の値が、 `` _LOCALE_``という名前のキーの下にある `` request.params``ディクショナリにあることを確認してください。これは、通常、クエリ文字列または要求に関連付けられたフォームポストの本文に `` _LOCALE_``値を渡した結果です。たとえば、「http：//my.application？_LOCALE_ = de``にアクセスします。
有効なロケール名の値が `` _LOCALE_``という名前のキーの下にある `` request.cookies``ディクショナリにあることを確認してください。これは、通常、 `` response.set_cookie（ '_ LOCALE_'、 'de'） ``のように、以前のレスポンスに `` _LOCALE_``クッキーを設定した結果です。

注釈

このロケールネゴシエーションスキームが特定のアプリケーションにとって不適切な場合は、必要に応じてそのアプリケーションにcustom：term： `locale negotiator`関数を設定することができます。参照：ref： `custom_locale_negotiator`を参照してください。

ロケールネゴシエーター¶

A：term： locale negotiator`は：term： localizer`の動作に、：locale name`が特定の要求に関連していることを伝えて通知します。ロケールネゴシエーターは、要求を受け取り、：term： `ロケール名`を返すコードです。それは：meth： `pyramid.i18n.Localizer.translate`または：meth： pyramid.i18n.Localizer.pluralize`が呼び出されたときに参照されます。それは：func：〜pyramid.request.Request.locale_name`がアクセスされたとき、または：func：〜pyramid.i18n.negotiate_locale_name`が呼び出されたときにも参照されます。

デフォルトロケールネゴシエーター¶

ほとんどのアプリケーションでは、デフォルトのロケールネゴシエーターを使用できます。追加のコーディングや構成は必要ありません。

class： `〜pyramid.i18n.default_locale_negotiator`という名前のデフォルトのロケールネゴシエーター実装は、以下の一連のステップを使用してロケール名を決定します。

最初に、ネゴシエーターは要求オブジェクトの `` _LOCALE_``属性を探します（おそらく、ビューコードによって直接設定されるか、または：term： `event`のリスナーによって設定されます）。
それから、 `` request.params ['_ LOCALE _'] ``の値を探します。
それから、 `` request.cookies ['_ LOCALE _'] ``の値を探します。
リクエストによってロケールが見つからない場合は、：term：デフォルトのロケール名`（参照：ref： `localization_deployment_settings）を使用します。
最後に、デフォルトロケール名が明示的に設定されていない場合は、ロケール名 `` en``を使用します。

カスタムロケールネゴシエーターの使用¶

ロケールネゴシエーションは時にはポリシーが重く複雑です。：ref： activating_translation`で説明されている（単純な）デフォルトのロケールネゴシエーションスキームがあなたのアプリケーションには不適切な場合、特別な：term： locale negotiator`を作成することができます。その後、新しく作成したロケールネゴシエーターをアプリケーションの構成に追加して、デフォルトのロケールネゴシエーターをオーバーライドすることができます。

ロケールネゴシエーターは、単に要求を受け入れ、ロケールが決まらない場合には：term：ロケール名`または ` None``を返します。

単純なロケールネゴシエーターの実装を次に示します。

def my_locale_negotiator(request):
    locale_name = request.params.get('my_locale')
    return locale_name

ロケールネゴシエーターが `` None``を返すと、デフォルトのアプリケーションロケール名を使用すべきであることをapp： `Pyramid`に示します。

：新しく作成したロケールネゴシエーターを、アプリケーションの設定に追加することができます。ネゴシエーターとして機能するオブジェクトを渡します（または：term：オブジェクトを参照する点線のPythonの名前）を：classの `` locale_negotiator``引数として渡します： `〜pyramid.config.Configurator`インスタンス。例えば：

from pyramid.config import Configurator
config = Configurator(locale_negotiator=my_locale_negotiator)

代わりに、：meth： `pyramid.config.Configurator.set_locale_negotiator`メソッドを使用してください。

例えば：

from pyramid.config import Configurator
config = Configurator()
config.set_locale_negotiator(my_locale_negotiator)

(機械翻訳) 国際化とローカリゼーション¶

変換文字列の作成¶

`` TranslationString``クラスの使用¶

`` TranslationStringFactory``クラスの使用¶

`` gettext``翻訳ファイルの操作¶

LinguaとGettextのインストール¶

UNIXへのインストール¶

Windowsへのインストール¶

コードとテンプレートからのメッセージの抽出¶

メッセージカタログファイルの初期化¶

カタログファイルの更新¶

メッセージカタログファイルのコンパイル¶

ローカライザの使用¶

翻訳の実行¶

複数化の実行¶

リクエストのロケール名の取得¶

日付書式設定および通貨書式設定の実行¶

翻訳文字列のカメレオンテンプレートのサポート¶

マコピラミッドi18nサポート¶

Jinja2ピラミッドi18nサポート¶

"使用可能な言語の検出"¶

翻訳の有効化¶

翻訳ディレクトリの追加¶

ロケールの設定¶

ロケールネゴシエーター¶

デフォルトロケールネゴシエーター¶

カスタムロケールネゴシエーターの使用¶

Table of Contents

前のトピックへ

次のトピックへ

このページ

(機械翻訳) 国際化とローカリゼーション¶

変換文字列の作成¶

`` TranslationString``クラスの使用¶

`` TranslationStringFactory``クラスの使用¶

`` gettext``翻訳ファイルの操作¶

LinguaとGettextのインストール¶

UNIXへのインストール¶

Windowsへのインストール¶

コードとテンプレートからのメッセージの抽出¶

メッセージカタログファイルの初期化¶

カタログファイルの更新¶

メッセージカタログファイルのコンパイル¶

ローカライザの使用¶

翻訳の実行¶

複数化の実行¶

リクエストのロケール名の取得¶

日付書式設定および通貨書式設定の実行¶

翻訳文字列のカメレオンテンプレートのサポート¶

マコピラミッドi18nサポート¶

Jinja2ピラミッドi18nサポート¶

ローカリゼーション関連の展開設定¶

&quot;使用可能な言語の検出&quot;¶

翻訳の有効化¶

翻訳ディレクトリの追加¶

ロケールの設定¶

ロケールネゴシエーター¶

デフォルトロケールネゴシエーター¶

カスタムロケールネゴシエーターの使用¶

"使用可能な言語の検出"¶