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-грамів.

У Solr немає таблиць. Натомість є документи з полями. Ось приклад документу: Кожен переклад і документація повідомлення мають свій документ. Щоб, власне кажучи, отримати підказки, ми спершу робимо пошук по відсортованому за подібністю рядків алгоритму для всіх документів вихідною мовою. Далі робимо інший запит на переклади для цих повідомлень, якщо вони є.

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

Початковий імпорт
 * 1) Виконати скрипт командного рядка ttmserver-export.php для кожної вікі, що використовує спільну пам'ять перекладів.

Новий переклад (якщо не застарілий)
 * 1) Створити документ

Оновлений переклад (якщо не застарілий)
 * 1) Видалити wiki:X language:Y message:Z
 * 2) Створити документ

Оновлене визначення повідомлення Усі існуючі документи для повідомлення залишаються, бо мають різні globalid.
 * 1) Створити новий документ

Переклад застарілий
 * 1) Видалити wiki:X language:Y message:Z

Зміна приналежності повідомлення до групи
 * 1) Видалити wiki:Z message:Z
 * 2) Створити документ (для усіх мов)

Повідомлення більше не використовується Усі подальші зміни до визначень або перекладів не оновлюються у пам'яті перекладів.
 * 1) Видалити wiki:Z message:Z
 * 2) Створити документ (для усіх мов)

Запит до пам'яті перекладів
 * 1) Зібрати подібні повідомлення зі strdist("message definition",content)
 * 2) Зібрати переклади з globalid:[A,B,C]

Пошуковий запит Може звужуватись до мови або групи повідомлень.
 * 1) Знайти усі співпадіння з text:"пошуковий запит"

Поля ідентифікатора Поле  ідентифікує переклад або визначення повідомлення унікально, комбінуючи такі поля: Використовуваний формат:.
 * вікі ідентифікатор (ID бази даних MediaWiki)
 * ідентифікатор повідомлення (Заголовок базової сторінки)
 * ідентифікатор версії повідомлення (ID версії сторінки визначення повідомлення)
 * мова повідомлення

На додачу, ми виділили окремі поля для вікі id, id повідомлення та мови, щоб зробити можливими запити на видалене, перераховані вище.

Встановлення
Ось загальні швидкі кроки встановлення і налаштування Solr для TTMServer. Ви маєте адаптувати їх до своєї ситуації. Щоб використовувати Solr backend, Вам також потрібна бібліотека Solarium. Найпростіше встановити MediaWiki розширення Solarium. Див. приклад конфігурації Solr backend у розділі налаштувань на цій сторінці. Ви можете зробити додаткові налаштунки Solarium через ключ, як зроблено, наприклад, у налаштуваннях Вікімедіа.

І останнє, можна заповнити пам'ять перекладів вмістом.