Help:Extension:Translate/Translation memories/ja

翻訳拡張機能翻訳メモリは、ElasticSearchをサポートします. このページでは、ElasticSearchの仕様をより詳細に説明し、利用者にElasticSearchをインストールする手助けをしていきます.

例えば外部機械翻訳サービスなど他の翻訳支援ソフトとは異なり、この翻訳メモリは利用者のウィキの新しい訳文によって絶えず更新されます. ElasticSearch の使用を選択した場合、全訳文を対象にした高度な検索 Special:SearchTranslations も利用できます.

比較
既定でデータベースバックエンドを使用. 依存関係はなく設定も不要です. ただし複数のウィキ間でデータベースバックエンドの共有はできず、あるいは大量の翻訳コンテンツの処理はできません. ElasticSearchのバックエンドもサポートします. 他のウィキの翻訳メモリも、先方の Web API を開いた状態なら使用可能です. ElasticSearchと異なる点は、利用中のウィキの翻訳を使った、リモートバックエンドの更新はできないことです.

必要条件


ElasticSearch バックエンド
ElasticSearch の設定は比較的簡単です. 配布パッケージに同梱されていない場合は、ウェブサイトから入手してください. 合わせて拡張機能のElastica extension も入手する必要があります. そして翻訳拡張機能に固有の環境設定は、で確認をお願いします.

ブートストラップ スクリプトが必要なスキーマを作成します. 複数のウィキで ElasticSearch バックエンドを利用する場合は、既定で翻訳メモリが共有されます. 利用者が環境設定でインデックス引数を設定すると、共有されません.

Elasticsearch のメジャーアップグレード（2.x から 5.x へなど）を実行する前に、リリースノートおよび説明文書に書いてある、アップグレード手順を熟読するよう、強く推奨します.

インストール
必要条件が整ったら、インストール前に設定を微調整し、ブートストラップを実行する必要があります.

設定
翻訳メモリを含め、翻訳支援ソフトはどれも 環境変数を使って設定されます.

プライマリの翻訳メモリ バックエンドは キーを必ず使います. プライマリのバックエンドは翻訳更新情報を受け取り、Special:SearchTranslations に渡します.

TTMServers の設定サンプルは以下のとおり.

利用できるキーと値は以下の通りです:

現在、対応しているデータベース バックエンドは MySQL のみです.

Bootstrap
ひとたび ElasticSearch を選び、要件と設定が整ったら、 を実行し翻訳メモリをブートします. 翻訳メモリのバックエンドを変更したときも必ずブートしてください. 断片化翻訳メモリを複数のウィキに使用している場合は、個別にひとつずつブートストラップする必要があります.

大量の翻訳を要するサイトの場合は、 引数を用いるスレッドを複数使い、プロセスの処理速度を上げるよう検討してください. 時間は、メッセージ群完了統計の完全度に大きく依存します（不完全なものはブートストラップ中に計算）. 新しい翻訳は自動的にフックによって追加されます. 初めて訳文が作成されると、新しい翻訳原文（メッセージ定義）を追加します.

ブートストラップが行う以下のことは、その他の処理では実行されません.
 * 翻訳メモリスキーマの追加と更新.
 * 既存の翻訳を翻訳メモリに追加する.
 * 翻訳メモリを空にしたあと再設定し、未使用の翻訳エントリを開放.

特定のメッセージの翻訳が更新されると、それまでの訳文は翻訳メモリから除外されます. ただし新しい定義に対して翻訳が更新され新しいエントリが追加されても、古い定義とそれに対する古い翻訳はパージするまでデータベースに残されます. 特定のメッセージの定義変更や、すべてのメッセージ群からの削除が発生しても、直後には何も起こりません. 翻訳をファジーとして保存しても、新しい翻訳が追加されたり、古い翻訳が翻訳メモリから削除されることはありません.

TTMServer API
もし利用者独自の TTMServer サービスを実行したいならば、仕様は以下のとおりです.

クエリのパラメーター:

サービスでは以下のパラメータを受け入れる必要があります.

利用者のサービスには JSON オブジェクトにオブジェクトの配列と キーを備える必要があります. それらオブジェクトには、以下のデータが含まれる必要があります.

例:


 * URL: http://translatewiki.net/w/api.php?action=ttmserver&sourcelanguage=en&targetlanguage=ja&text=january&format=jsonfm
 * 応答:



データベース バックエンド
The backend contains three tables:,   and. Those correspond to sources, targets and fulltext. You can find the table definitions in. The sources contain all the message definitions. Even though usually they are always in the same language, say, English, the language of the text is also stored for the rare cases this is not true.

Each entry has a unique id and two extra fields, length and context. Length is used as the first pass filter, so that when querying we don't need to compare the text we're searching with every entry in the database. The context stores the title of the page where the text comes from, for example "MediaWiki:Jan/en". From this information we can link the suggestions back to "MediaWiki:Jan/de", which makes it possible for translators to quickly fix things, or just to determine where that kind of translation was used.

The second pass of filtering comes from the fulltext search. The definitions are mingled with an ad hoc algorithm. First the text is segmented into segments (words) with MediaWiki's. If there are enough segments, we strip basically everything that is not word letters and normalize the case. Then we take the first ten unique words, which are at least 5 bytes long (5 letters in English, but even shorter words for languages with multibyte code points). Those words are then stored in the fulltext index for further filtering for longer strings.

When we have filtered the list of candidates, we fetch the matching targets from the targets table. Then we apply the levenshtein edit distance algorithm to do the final filtering and ranking. Let's define:


 * E :編集距離
 * S :提案を探す元となっている文字列
 * Tc :提案の文章
 * To :Tc が翻訳結果となるような元の文章

The quality of suggestion Tc is calculated as E/min(length(Tc),length(To)). Depending on the length of the strings, we use: either PHP's native levenshtein function; or, if either of the strings is longer than 255 bytes, the PHP implementation of levenshtein algorithm.  It has not been tested whether the native implementation of levenshtein handles multibyte characters correctly. This might be another weak point when source language is not English (the others being the fulltext search and segmentation).