Импортированный текст разбивается в DVX на сегменты, разделенные знаками пунктуации и другими символами (delimiters). В умолчальном варианте сегментами являются отдельные предложения, части предложений, разделенные точкой с запятой, пункты списков. Все это деление настраивается, если интересует мой вариант, привожу скриншот настроек разделителей:
Одно неудобство в нем есть – в один сегмент попадают два или более предложений, которые заканчиваются цифрой. Зато в формуле изобретения нет разрыва между номером пункта с точкой и текстом. В общем, выбирайте, что вам удобнее исправлять. Разбивка на сегменты не окончательная, пользователь может в процессе работы клеить/резать сегменты, как ему заблагорассудится. Это удобно в текстах заявителей, которые любят предложения на полстраницы – мы делим его на логические куски (явно фигурирующие этапы способа, функции какого-нибудь блока или т.п.), которые потом обычно встречаются в виде отдельных пунктов формулы или ее подпунктов. Даже если и не встретятся – все равно наглядно переводить куски текста из 2-3 строк. Вообще, чем короче сегмент, тем нам удобнее его переводить, а DVX – точнее анализировать его при неточном совпадении в будущих сегментах. Однако увлекаться тоже не стоит.
Теперь о том, как «переводит» DVX. При переходе к очередному сегменту DVX смотрит в TM на предмет того, есть ли уже в ней такой же сегмент – здесь имеется в виду 100%-ное совпадение. Если таковой отыскивается, то перевод из ТМ подставляется в текущий сегмент. Посмотрим на пример:
Определенный цвет сегмента (слева) и значение совпадения (100%, справа внизу) указывают, что в ТМ уже есть точно такой же переведенный сегмент. Встречаются ситуации, когда совпадающих сегментов в ТМ несколько – например, с одинаковым source и разными target (переводами). Тогда для выбора наиболее подходящего DVX использует свою «шкалу ценностей»:
- точность совпадения (fuzziness): выигрывает тот сегмент, у которого она выше;
- язык перевода (target) – сравнивается не только основной, но и sub-language (в наших проектах не используется);
- client – если вы указываете его при создании проекта, тогда можно играть с разными переводами одинаковых фраз для разных клиентов… ну а вдруг 🙂
- subject (тоже если указан);
- язык исходника (source);
- регистр букв;
- «возраст» сегмента – можно в настройках указать, предпочитать ли более старые или более свежие переводы.
Это самый первый и простой случай – Exact Match. У него есть разновидность – Guaranteed Match, использование которого надо включить в настройках (лично я не использую). Это еще более «жесткое» совпадение, при котором анализируются и окружающие сегменты (т.е. как бы гарантируется, что предложение не вырвано из контекста).
Конечно, чем больше Exact Match, тем приятнее, но тогда бы и труд переводчика был попроще 🙂 Второй случай при анализе сегмента – это не 100%-ное совпадение, но близкое к нему, так называемый Fuzzy Match. Порог совпадения в процентах также задается в настройках. Когда возникает этот Fuzzy Match? Когда в переводимом сегменте, по сравнению с имеющимся в ТМ, заменено 1-2 слова, добавлено несколько слов, некоторые слова переставлены, отличаются знаки препинания и т.п. Это позволяет судить о том, что предложение в принципе похожее, но нужно кое-что поменять. При этом получается экономия времени, потому что мы не «колотим» снова полный текст перевода сегмента, а лишь меняем несколько слов или даже пару окончаний. Причем часть замен DVX может сделать автоматически, если распознает, какое слово было заменено каким другим словом, и у нее есть перевод слова/словосочетания в TDB или в лексиконе. Проиллюстрирую это примерами:
Здесь видно, что в переводимом в настоящий момент сегменте, по сравнению с имеющимся в ТМ, удалено сочетание «at the same time», что DVX наглядно показала нам зачеркиванием. При этом DVX обнаружила где-то у себя (в TM, TDB, лексиконе – не важно), что знает перевод этого удаленного куска («одновременно»), поэтому смело удалила его в переводимом сегменте (показано стрелкой).
Пример №2:
Тут немного интереснее, но принцип анализа тот же. В переводимом сегменте «can comprise» заменено на «comprises». Видим, что «comprises» есть в TDB, и далее сам инструмент выполняет замену. За нами – только визуальный контроль. Еще один пример, аналогичный предыдущему:
И последний пример «умной» замены:
Как видно, DVX не только распознала замену «module» на «application», но и сохранила конструкцию (благодаря тому, что в лексикон занесено всё сочетание «image processing application»). Обратите внимание – цифры (здесь это номера ссылок) меняются автоматом, и это тоже большое облегчение. Дополнительно в DVX есть инструмент контроля чисел (нумерации), о нем поговорим позже.
