国際化
Omeka Sは、異なる言語でユーザーインターフェースを提供するためのサポートを含んでいます。 Omekaとそのモジュールのソース文字列は英語で書かれており、私たちはボランティアによる 翻訳を頼りにしています。
基本
Omeka Sは、翻訳された文字列をgettext 形式で保存しています。大まかには以下の3種類のファイルがあります：
.potファイルは翻訳テンプレートで、英語のソース文字列のみが含まれます。.poファイルは、翻訳された文字列が保存されている場所です。.potファイルと同じですが、 各文字列の翻訳が記入されています。言語ごとに別々の.poファイルがあります。.moファイルは、.poファイルのコンパイルされたバージョンです。Omeka Sが実際に 特定の言語の翻訳された文字列を読み取り使用するためには.moファイルが使用されます。
これらの3種類のファイルは、languages ディレクトリ
（コアの場合はapplication/languages）に見つかります。
一般的に、翻訳者は次のセクションで説明されるTransifexを通じて、最初の2種類のファイルに
取り組むでしょう。
Transifex
Omeka Sは翻訳貢献を簡単にするためにTransifexプラットフォームを使用しています。 Omekaチームによって書かれたコアとモジュールは、Transifexの同じプロジェクトを通じて扱われます。 Transifexのサイトを通じて、既存の翻訳チームに参加したり、新しい言語をリクエストしたり、 翻訳への変更や貢献を行ったりすることができます。
翻訳可能な文字列の作成
Omeka Sでコードを書くときには、ユーザに提示される文字列は翻訳できるように特別な扱いが必要です。
直接翻訳：ビュー内
マークアップ内に直接文字列を書くのではなく、translate() ヘルパーを使用します。
実際の簡単な例として、インストーラビューからのこの行を参照してください： php
translate('Install Omeka S'); ?>
translate() を使用することで、英語のソース文字列を翻訳された同等のものに実際に置換し、
また翻訳者に利用可能な文字列を作成する翻訳テンプレートを作成するときに、翻訳可能な
文字列としてのマーカーとして機能します。
間接翻訳：フォームやその他のクラス内
Zend\Form クラスを使用するコードは、ユーザに提示されるラベル、凡例、および説明などの
文字列を自動的に翻訳します。
サイトブロックやメディアインジェスタ、設定ファイルで定義されるナビゲーションエントリの ラベル、およびエラーメッセージなど、ユーザ対面で定義される文字列のその他の領域も 自動的に翻訳されます。
このような状況では、行の最後に // @translate というコメントを付けるだけで十分です。
翻訳自体はコメントの有無にかかわらず行われますが、自動化されたテンプレート処理によって
翻訳される文字列を拾い上げて、翻訳チームに利用可能にするためにコメントが必要です。
// @translate コメントは、直前の文字列にのみ適用されます。単一行に複数の翻訳可能な
文字列が含まれている場合、または翻訳可能な文字列が翻訳不可能なものの間に出現する場合には、
元の行を複数の行に分割する必要があるかもしれません。
module.config.php ファイル内のサイトナビゲーションセクションで // @translateコメントを
使用する例を次に示します：
php
return [
'navigation' => [
'site' => [
[
'label' => 'Collecting', // @translate
'route' => 'admin/site/slug/collecting',
'action' => 'index',
'useRouteMatch' => true,
'pages' => [
// .....
],
],
]
]
];
そして、Zend\Form\Form を拡張するフォームクラスからのものです：
php
public function init()
{
$this->add([
'name' => 'o:email',
'type' => 'Email',
'options' => [
'label' => 'Email', // @translate
],
'attributes' => [
'id' => 'email',
'required' => true,
],
]);
};
動的な部分を含む文字列の扱い
上記の例は、単純な静的な文字列に焦点を当てていますが、しばしばユーザからのデータや、 検索結果の数などの変化する部分を持つ文字列が必要になります。既存の文字列をそのまま 翻訳システムに渡すだけでは正しく動作しません：データの変更がそれぞれ「新しい」文字列として 扱われ、翻訳されません。
このような状況では、文字列の動的な部分を「プレースホルダ」に置き換える必要があります。 これにより、動的な部分が挿入されている一定の翻訳可能な部分になります。これを行うために、 Omeka SはPHP関数 sprintfを使用します。
sprintfの基本的なプレースホルダは %s です。これを使って動的な文字列を翻訳可能にする方法の
例を示すのが最も簡単です。以下の翻訳されていないコード：
php
There are <?php echo $this->escapeHtml($results); ?> results.
翻訳された時には以下のようになります： php
translate('There are %s results.'), $this->escapeHtml($results)); ?>translate()への呼び出しが sprintfの 内 にあることに注意してください。
一つの文字列に 複数 の動的パーツが含まれている場合に使用される少し複雑なスタイルのプレースホルダがあります。
一部の言語は、元の英語の文字列とは異なる順序でこれらの部分を並べ替える必要があるかもしれないため、
最初のプレースホルダを二番目のプレースホルダと区別するためのものです。これらのプレースホルダは、
次のようになります： %1$s, %2$s などです。
これらの「動的」文字列をビューの外部（クラスファイルなどの場所で、例えば）で扱う場合に
使用される方法は少し異なります。sprintfを直接使用するのではなく、Omeka\Stdlib\Message クラスが使用され、
文字列の静的部分と動的部分を合わせて渡します。
php
結果として得られる Message オブジェクトはビューの中で translate() に直接渡すことができます。
このパターンは、ユーザに提示する必要があり、したがって翻訳する必要があるバックエンドコードの奥深くから
発せられるかもしれないエラーメッセージに対してよく使用されます。
翻訳ファイルの更新
Omeka Sには翻訳ファイルを扱うためのいくつかのGulpタスクが含まれています。タスクはすべて i18n （ "internationalization" の略）で始まります。Gulpがセットアップされているだけでなく、これらのタスクでは gettext パッケージが必要です。ここでは msgfmt や xgettext などのコマンドが使用されており、翻訳ファイルの処理に用いられます。
gulp i18n:template はコアの .pot 翻訳テンプレートを更新します。文字列が追加または変更されたとき、このタスクはテンプレートを更新し、翻訳者が自身の翻訳を更新できるようにします。Omekaチームはこのコマンドを実行し、その結果をTransifexにプッシュします。
gulp i18n:compile は .po ファイルを更新した後にコンパイルして .mo ファイルにするために実行されます。.po 翻訳ファイルを更新しても、Omeka Sが変更を認識するには十分ではありません。実際に使用されるのは .mo ファイルです。OmekaチームはTransifexから更新を引き出した後にこのコマンドを実行します。
コアではなくモジュールで作業するために使用されるさらに多くのコマンドについては、 モジュール内の国際化に関する文書を参照してください。