Help:Extension:Translate/Translation memories/uk

TTMServer — це сервер пам'яті перекладів, що входить до розширення Translate. Він не вимагає жодних зовнішніх залежностей. Він увімкнений за замовчуванням і переносить підтримку для tmserver з translatetoolkit, який було складно встановити. TTMServer — це проста пам'ять перекладу, що не використовує ніяких розширених алгоритмів. Однак, вона використовує чудову підтримку мов MediaWiki і функції абстракції бази даних.

Існує декілька способів використання TTMServer:

Налаштування
Усі допомоги перекладу включно з пам'яттю перекладу налаштовуються у налаштуваннях конфігурацій. Приклад конфігурацій TTMServers:

Можливі ключі і значення:

Зараз для баз даних підтримується лише MySQL.

Доступ до TTMServer через API
Якщо Ви хотіли б впровадити власний сервіс TTMServer, тут подано деякі технічні параметри.

Параметри запиту:

Ваш сервіс повинен прийняти такі параметри: Ваш сервіс повинен надавати об'єкт JSON, що мусить мати ключ  з масивом об'єктів. Ці об'єкти повинні містити такі дані: Приклад:


 * URL: http://translatewiki.net/w/api.php?action=ttmserver&sourcelanguage=en&targetlanguage=fi&text=january&format=jsonfm
 * Повертає:

Архітектура TTMServer
Backend містить три таблиці:,   і. Вони відповідають джерелам, цілям та повному тексту. Ви можете знайти визначення таблиць у. Джерела містять усі визначення повідомлень. Незважаючи на те, що зазвичай вони написані тією ж мовою, скажімо, англійською, мова тексту також зберігається, крім рідкісних винятків.

Кожен запис має унікальний id і два додаткові поля, "length" і "context". "Length" використовується як перший фільтр довжини, так що при подачі запиту не треба порівнювати текст, який ми шукаємо, з кожним записом у базі даних. У "context" прописується назва сторінки, з якої цей текст, наприклад "MediaWiki:Jan/en". Виходячи з цієї інформації, ми можемо видати підказку на "MediaWiki:Jan/de", що дає можливість перекладачам швидко працювати, та й просто визначати, де використано такий вид перекладу.

Другий крок фільтрації забезпечується повнотекстовим пошуком. Визначення змішані за спеціальним алгоритмом. Спершу текст розбивається на сегменти (слова) з допомогою  MediaWiki. Якщо сегментів достатньо, відсівається все, що не є літерами слів, і впорядковується. Потім беремо перші десять унікальних слів довжиною щонайменше 5 байтів (5 букв англійською, але навіть і менші слова у мовах з мультибайтними кодовими точками). Ці слова потім зберігаються у повнотекстовому індексі для подальшої фільтрації у довших рядках.

Коли ми відфільтрувати список кандидатів, дістаємо з цільової таблиці те, що співпадає. Потім застосовується алгоритм відстані редагування Левенштейна для останнього фільтрування і ранжування. Давайте визначимо:


 * E : відстань редагування
 * S : текст, для якого шукаються підказки
 * Tc : текст підказки
 * To : вихідний текст, перекладом якого є Tc

Якість підказки Tc обраховується як E/min(length(Tc),length(To)). Залежно від довжини (length) рядків, ми користуємося або вбудованою функцією Левенштейна PHP, або, якщо будь-який з рядків довший, ніж 255 байтів, реалізацією алгоритму Левенштейна. Не перевірялось чи вбудована реалізація алгоритму Левенштейна коректно відображає мультибайтні символи. Це може бути ще одним слабким місцем, якщо мова джерела не англійська (іншими є повнотекстовий пошук і сегментація).

Є скрипт, який заповнює пам'ять перекладів перекладами з активних груп повідомлень. Навіть великі сайти мають бути здатними здійснити початкове завантаження пам'яті за півгодини, коли використовуються декілька нитей (потоків) з параметром. Час переважно залежить від того, наскільки повною є статистика завершеності групи повідомлень (незавершені групи будуть обраховуватись під час початкового завантаження). Нові переклади автоматично перехоплюються і додаються. Нові джерела (визначення) додаються, коли додано перший переклад.

Старі переклади, які більше не використовуються і не належать до жодної групи повідомлень не очищуються автоматично, якщо тільки ви не перезапустите скрипт початкового завантаження. Коли оновлюється переклад повідомлення, попередній переклад видаляється з пам'яті. Коли оновлюється визначення, нічого не стається одразу ж. Коли переклади оновлюються не зважаючи на нове визначення, буде додано новий запис. Старе визначення і його старі переклади залишаються у базі даних, поки не очистяться перезавантаженнями скрипта початкового завантаження. Також застарілі переклади не додаватимуться до пам'яті перекладів, але переклади і не видаляються з пам'яті, коли застарівають.

Solr backend
Чимало з написаного вище також можна застосувати до TTMServer, що використовує як backend пошукову платформу Solr, окрім деталей щодо макету бази даних і запитів. Результати за замовчуванням ранжуються за алгоритмом Левенштейна зі сторони Solr, але інші доступні алгоритми порівняння рядків також можуть використовуватись, як наприклад, порівняння N-грамів.

In Solr there are no tables. Instead we have documents with fields. Here is an example document: Each translation has its own document and message documentation has one too. To actually get suggestions we first perform the search sorted by string similarity algorithm for all documents in the source language. Then we do another query to fetch translations if any for those messages.

We are using lots of hooks to keep the translation memory database updated in almost real time. If user translates similar messages one after another, the previous translation can (in the best case) be displayed as suggestion for the next message.

Initial import
 * 1) Execute ttmserver-export.php command line script for each wiki using the shared translation memory.

New translation (if not fuzzy)
 * 1) Create document

Updated translation (if not fuzzy)
 * 1) Delete wiki:X language:Y message:Z
 * 2) Create document

Updated message definition All existing documents for the message stay around because globalid is different.
 * 1) Create new document

Translation is fuzzied
 * 1) Delete wiki:X language:Y message:Z

Messages changes group membership
 * 1) Delete wiki:Z message:Z
 * 2) Create document (for all languages)

Message goes out of use Any further changes to definitions or translations are not updated to TM.
 * 1) Delete wiki:Z message:Z
 * 2) Create document (for all languages)

Translation memory query
 * 1) Collect similar messages with strdist("message definition",content)
 * 2) Collect translation with globalid:[A,B,C]

Search query Can be narrowed further by facets on language or group field.
 * 1) Find all matches with text:"search query"

Identifier fields Field  uniquely identifies the translation or message definition by combining the following fields: The used format is.
 * wiki identifier (MediaWiki database id)
 * message identifier (Title of the base page)
 * message version identifier (Revision id of the message definition page)
 * message language

In addition we have separate fields for wiki id, message id and language to make the delete queries listed above possible.

Встановлення
Here are the general quick steps for installing and configuring Solr for TTMServer. You should adapt them to your situation. To use Solrbackend you also need Solarium library. Easiest way is to install the Solarium MediaWiki extensions. See the example configuration for Solr backend at the configuration section of this page. You can pass extra configuration to Solarium via the  key like done for example in the Wikimedia configuration.

And finally we can populate the translation memory with content.