Ru-Board.club
← Вернуться в раздел «Программы»

» TRADOS и другие CAT-средства

Автор: XPerformer
Дата сообщения: 28.12.2013 22:35
lion9

Цитата:
Микс из Trados Studio 2014 с Multitrerm + Multitern Extract + TermInjector + QTranslate + проверка Common и Terminology в Verifika позволяет в несколько раз (и я абсолютно не преувеличиваю) уменьшить время работы над документом, а также обеспечить единство терминологии по всему документу, сохранить оригинальную вёрстку, мгновенно локализовать даты и суммы и всё, что угодно, в нужный именно Вам формат («dated 2 May 2009» можно настроить для translation proposal в виде «от 2 мая 2009 года» или «от 2 мая 2009 г.» - как заблагорассудится), производить автоматизацию практически любых задач с использованием регулярных выражений.

Не могли бы вы пояснить, что такое TermInjector?
на офсайте его скачать без регистрации нельзя, скриншоты микроскопические и невнятные.
В чем суть TermInjector и почему для вас он необходим? неужели есть какие-то функции, которых нет в этом комбайне
Автор: lion9
Дата сообщения: 29.12.2013 00:55

Цитата:
Не могли бы вы пояснить, что такое TermInjector?
на офсайте его скачать без регистрации нельзя, скриншоты микроскопические и невнятные.
В чем суть TermInjector и почему для вас он необходим? неужели есть какие-то функции, которых нет в этом комбайне


В целом, TermInjector служит для модифицирования сегмента, выдаваемого Translation Memory, и для модифицирования Source при отсутствии совпадений по TM.


И в нём есть необходимые функции, не особо реализованные в рамках основного комбайна:

1. Например, возможность внести глоссарий заказчика в Exact Match File rule, чтобы нужная терминология сразу же подставлялась в предлагаемый сегмент (это удобнее, чем копировать термины из Terminology Base, и, в отличие от неё, TermInjector термины видит все, ничего не упускает, consistency в плане терминологии будет идеальная). Весь Exact Match File rule представляет из себя, по сути, следующую структуру, с разделителем табуляцией:

IOTS    CОПГ
ISAR    ПОАБ
OTS    ОПГ
PSA    ПОБ
RPV    КРПД
Absolute Guarantees    Абсолютные гарантии
Acceptance test    Приемочные испытания

Позже содержимое этого файла легко скопировать в Excel, а данный файл Excel использовать для импорта в Verifika в целях проверки терминологии.


2. Кроме того, TermInjector обладает огромными возможностями в плане использования регулярных выражений.

Например, в Source имеются суммы вида:

€ 2 million и € 3.4 million

Нужно, чтобы они локализовывались следующим образом:

2 млн евро и 3,4 млн евро.

Для этого в Regular Expression File rule добавляются два правила (разделитель - табуляция):

€ ([0-9]*) million    \1 млн евро
€ ([0-9]*)(\.)([0-9]*) million    \1,\3 млн евро

Равным образом, можно поступить и с датами:

on ([0-9][0-9]?) January ([0-9]{2,4})    \1 января \2 года
on ([0-9][0-9]?) February ([0-9]{2,4})    \1 февраля \2 года
on ([0-9][0-9]?) March ([0-9]{2,4})    \1 марта \2 года
on ([0-9][0-9]?) April ([0-9]{2,4})    \1 апреля \2 года
on ([0-9][0-9]?) May ([0-9]{2,4})    \1 мая \2 года
on ([0-9][0-9]?) June ([0-9]{2,4})    \1 июня \2 года
on ([0-9][0-9]?) July ([0-9]{2,4})    \1 июля \2 года
on ([0-9][0-9]?) August ([0-9]{2,4})    \1 августа \2 года
on ([0-9][0-9]?) September ([0-9]{2,4})    \1 сентября \2 года
on ([0-9][0-9]?) October ([0-9]{2,4})    \1 октября \2 года
on ([0-9][0-9]?) November ([0-9]{2,4})    \1 ноября \2 года
on ([0-9][0-9]?) December ([0-9]{2,4})    \1 декабря \2 года

теперь вышеуказанный формат даты будет трансформироваться TermInjector как «29 декабря 2013 года».

Вот примеры выдачи TermInjector в моём текущем заказе:

http://www.evernote.com/shard/s63/sh/32ab4568-668f-4d20-90f4-efc32e870830/313c61b595a8e1bf600c4f747af60284

Более подробные инструкции есть на сайте разработчика: http://www.tntranslations.com/TermInjectorHelp.html

Ссылка на дистрибутив - https://mega.co.nz/#!s00Q1KhB!We9a6giRe-rlAKzInAmM8h6TrpcGroVt-Ml8ZKSJ5Ew (плагин предназначен для установки в Студии 2009 и 2011, обновлённую версию автор обещает в начале 2014 года, поэтому, если у Вас Студия 2014, установите плагин и скопируйте содержимое папки c:\Users\User_Name\AppData\Local\SDL\SDL Trados Studio\10\Plugins\ в папку c:\Users\User_Name\AppData\Local\SDL\SDL Trados Studio\11\Plugins\)

Для использования неразрывных пробелов в правилах файлы правил должны быть сохранены как текстовые файлы с кодировкой UTF-8, неразрывные пробелы в нужных местах можно ввести, зажав Alt и набрав на цифровой клавиатуре 0160

Самый большой для меня минус в TermInjector - если по сегменту есть Fuzzy Match, он не предлагает модификацию Source. В Advanced можно добавить настройку “inject” fuzzy matches, но тогда он определяемые правилами кусочки текста просто вставляет в начала предлагаемого из TM сегмента. Иной раз бывает так, что предлагаемый присланной TM сегмент настолько плох, что уж лучше бы просто выдача TermInjector была.
Автор: XPerformer
Дата сообщения: 29.12.2013 01:25
lion9

спасибо за ответ и за ссылку
а то тут http://www.translationzone.com/openexchange/app/terminjector-321.html
ничего разглядеть невозможно

Добавлено:
а можно вопрос немного о другом: как справляться с дюймами?
чтобы автоматически переводились в см.
Дело осложняется тем, что они дробные бывают - 2.5 дюйма, и в тексте идут сериями типа
10-10-11.5-12-13.5 inches
1 дюйм - это 2.54 см, в регулярное выражение умножение не вставишь, и все варианты не перечислишь
Автор: lion9
Дата сообщения: 29.12.2013 01:38

Цитата:
а можно вопрос немного о другом: как справляться с дюймами?
чтобы автоматически переводились в см.
Дело осложняется тем, что они дробные бывают - 2.5 дюйма, и в тексте идут сериями типа
10-10-11.5-12-13.5 inches
1 дюйм - это 2.54 см, в регулярное выражение умножение не вставишь, и все варианты не перечислишь


Не сталкивался с таким, поскольку не технический переводчик. Я бы перечислил хотя бы так:

0.5 дюйма
1 дюйма
1.5 дюйма
2 дюйма

и далее, добавив сантиметры. Т.е. если сегмент подходит, слово inches будет переведёно, всё норм, всё совпало. Если inches не заменилось на сантиметры, то число до сих пор в дюймах, аларм, надо делать вручную. Если серией, то, честно говоря - вообще не знаю... В голову приходит лишь вариант писать скрипт на Python, который бы читал и сплиттил строку 10-10-11.5-12-13.5 и возвращал строку, где все числа умножены на 2.54. И то навскидку не напишу, надо думать, как это реализовать.
Автор: XPerformer
Дата сообщения: 29.12.2013 01:47
lion9
так примерно и делаю. для серий отдельный скриптик сделан, но неудобно, что его отдельно запускать надо и вручную. Хотя бы серию регуляркой опознать можно

Добавлено:
lion9
Trados не использую, поэтому вопрос чайниковский - он позволяет подключать скрипты на питоне, или вы тоже посоветовали как отдельное приложение этот скрипт вызывать?
Автор: lion9
Дата сообщения: 29.12.2013 01:53
Нет, скрипты Trados не поддерживает. Даже макросы не поддерживает ни в каком виде. У него много чего встроено по автоматической локализации дат и цифр для языка, используемого как Target, но я не сталкивался с дюймами в работе, сказать ничего не могу.
Автор: XPerformer
Дата сообщения: 29.12.2013 01:57
я правильно понимаю - Trados и все его плагины/надстройки позволяют именно локализовать даты и суммы, но не сконвертировать из одной ед. измерения в другую?
Автор: lion9
Дата сообщения: 29.12.2013 02:02

Цитата:
я правильно понимаю - Trados и все его плагины/надстройки позволяют именно локализовать даты и суммы, но не сконвертировать из одной ед. измерения в другую?


Да, абсолютно верно понимаете. По сути, настройки TermInjector в этом плане - это всего лишь Replace по регулярным выражениям.
Автор: XPerformer
Дата сообщения: 29.12.2013 02:06
lion9
спасибо, стало понятнее.
Но разве память переводов не делает тоже самое, только с учетом контекста?
Скажем in - это общепринятое сокращение inches и в то же время предлог.
С учетом контекста можно автоматически сделать правильный перевод, регулярки же здесь часто ошибаются.
Автор: lion9
Дата сообщения: 29.12.2013 02:10

Цитата:
Но разве память переводов не делает тоже самое, только с учетом контекста?


Память перевода - это сравнение предыдущего переведённого вручную сегмента/сегментов с текущим, в зависимости от процента совпадения. Никакого контекстного перевода она не делает. В студии есть возможность использовать Placebles - но это те же регулярки.

http://www.evernote.com/shard/s63/sh/5e6ce6d9-e386-4c9c-94e4-208e6c0cd7fb/a61b3d46b96aff30b573b770abf6fbf1

Как видите, локализация коснулась лишь в замене разделителя точки разделителем запятой.
Автор: XPerformer
Дата сообщения: 29.12.2013 02:15
но сегменты человек же указывает, верно?
в нашем примере с дюймами нужно ввести по сегменту на каждое
0.5 дюйма
1 дюйма
1.5 дюйма
2 дюйма
и т.п.
И тогда по сути это сработает как Replace.
Или я неправильно понимаю суть памяти перевода? мне эта тема интересна как программисту, хочется понять механизм автоматического перевода
Автор: lion9
Дата сообщения: 29.12.2013 02:25

Цитата:
но сегменты человек же указывает, верно?
в нашем примере с дюймами нужно ввести по сегменту на каждое
0.5 дюйма
1 дюйма
1.5 дюйма
2 дюйма
и т.п.
И тогда по сути это сработает как Replace.
Или я неправильно понимаю суть памяти перевода? мне эта тема интересна как программисту, хочется понять механизм автоматического перевода


Не совсем. Точнее, совсем не. Память перевода и автоматический перевод - разные вещи.

Продемонстрирую суть памяти перевода.

сегмент 1:

Договор

переводим как Contract

В памяти переводов появляется Translation Unit, единица перевода: Source: Договор Target: Contract.

сегмент 2:

Договорные отношения

Точного перевода в памяти переводов нет, но есть совпадение по слову «Договор». Поэтому нам предлагается частичное совпадение «Contract».

переводим второй сегмент как «Contractual relations», допечатав «aul relations» к слову «Contract». получаем ещё одну единицу перевода Source: Договорные отношения Target: Contractual relations.

сегмент 3:

Договорные обязательства

Точного перевода опять нет. Предлагается вариант с более высоким процентом совпадения - Contractual relations, но не Contract.

Переводим как Contractual obligations, получаем третью единицу перевода Source: Договорные обязательства Target: Contractual obligations.

сегмент 4:

Договор

100% совпадение по первой единице перевода. Подставляется готовый вариант - Contract.

Чем больше сегментом, тем чаще совпадения. Учитывая, что в текстах часто повторяются с небольшими вариациями одни и те же предложения, это существенно облегчает работу.

Моё же предложение касалось именно предложений TermInjector (дюймы не сериями):

Например, предложение:

«Average length of the part is 12 inches»

в TermInjector можно указать точное правило:

12 inches 30,48 см

Предложенный TermInjector вариант будет иметь вид:

«Average length of the part is 30,48 см»

И так для всех числовых значений дюймов хотя бы с шагом 0.5

Повторюсь, что с сериями из дюймов такая штука, сами понимаете, невозможна.

Автор: XPerformer
Дата сообщения: 29.12.2013 02:31
хорошо, для программисткого уха это звучит примерно как замена нечеткими регулярными выражениями.
А с падежами и склонениями как дела обстоят?
По вашему примеру я понимаю, что никак: мне нужно каждую форму забивать как отдельный сегмент
1 table - 1 стол
2 tables - 2 стола
5 tables - 5 столов
Это верно?
Автор: lion9
Дата сообщения: 29.12.2013 02:34
Верно. Память переводов лишь предлагает вариант сегмента. Если он частичный, его приходится править по-любому, логично. Если он 100%, то всё равно надо смотреть контекст. То же слово Договор со 100% совпадением Contract в рамках данного документа может в соответствии с требованиями заказчика переводиться как Agreement.

Посмотрите выше, я дополнил пред. сообщение пояснением того, что я предлагал как вариант в рамках TermInjector.
Автор: XPerformer
Дата сообщения: 29.12.2013 02:36

Цитата:
Моё же предложение касалось именно предложений TermInjector (дюймы не сериями):  
Например, предложение:   «Average length of the part is 12 inches»
  в TermInjector можно указать точное правило:   12 inches    30,48 см  
Предложенный TermInjector вариант будет иметь вид:   «Average length of the part is 30,48 см»  
И так для всех числовых значений дюймов хотя бы с шагом 0.5

Кажется, я что-то упускаю.
То, что эту задачу можно решить в TermInjector - понимаю.
Но с моей точки зрения, можно и без него обойтись - задав те же пары замен как сегменты в самом Trados.
Может быть, в TermInjector это делать удобнее, быстрее и т.д., но он не является строго необходимым.
Разве не так?
Автор: lion9
Дата сообщения: 29.12.2013 02:44

Цитата:
Но с моей точки зрения, можно и без него обойтись - задав те же пары замен как сегменты в самом Trados.


Сегменты в Trados - переведённые предложения. Они никоим образом не являются регулярками. Вам ничего не даст отдельная единица перевода (это сегмент - целое предложение, отдельное, не в составе предложения!):

Source: 12 inches Target: 30,48 см

Только в том случае, если будет 100% совпадение - всё будет хорошо и правильно.

Если будет предложение «13 inches», то память перевода выдаст:

1213 inches 30,48 см

Target не поменяется. Красным цветом и зачёркиванием будет выделено несовпадение числа 12 из Translation Unit и 13 из переводимого сегмента.

Если будет длинное предложение:

«The length should not exceed 13 inches»

совпадений вообще не будет, процентная разница слишком велика. Translation Unit «12 inches» не подставится в соответствующий участок более длинного предложение. Данный вариант перевода будет предложен памятью переводов только тогда, когда процентное совпадение переводимого сегмента и единицы перевода в памяти переводов превышает некую пороговую величину.
Автор: XPerformer
Дата сообщения: 29.12.2013 02:51

Цитата:
Если будет предложение «13 дюймов», то память перевода выдаст:  
1213 inches    30,48 см

Я подразумеваю, что внесена вся таблица дюймов, с точностью до четверти дюйма.


Цитата:
Если будет длинное предложение:  
The length should not exceed 13 inches»   совпадений вообще не будет, процентная разница слишком велика.

ага, теперь дошло.
Я на своем доморощенном микропереводчике анализирую фразы-сегменты от длинных к более коротким, вплоть до 1 слова, и подменяю сначала длинные фразы, а то что не заменилось - вторым проходом среди фраз на 1 слово короче и т.д. Несколько другой подход




Добавлено:
Ну чтобы совсем удостовериться, что правильно понимаю - сегмент это ровно одно предложение. Нельзя указать устойчивое словосочетание или абзац, состоящий из двух-трех предложений?
Автор: lion9
Дата сообщения: 29.12.2013 02:57

Цитата:
Я на своем доморощенном микропереводчике анализирую фразы-сегменты от длинных к более коротким, вплоть до 1 слова, и подменяю сначала длинные фразы, а то что не заменилось - вторым проходом среди фраз на 1 слово короче и т.д. Несколько другой подход


В Trados единица перевода на более длинный сегмент не даст совпадения в более маленьком сегменте, Source: «The length should not exceed 13 inches» Target: «Длина не должна превышать 13 дюймов» не выдаст никаких совпадений на сегменте «13 inches».
Автор: XPerformer
Дата сообщения: 29.12.2013 03:02
lion9
Спасибо за уделенное время.
Получается, что память переводов хороша для технических текстов, таких как компьютерные инструкции или тексты договоров, где много повторяющихся фрагментов.
Для перевода художественного текста эта схема не работает даже в первом приближении (ну чтобы текст не набирать, а сразу перейти к творческой составляющей перевода). Потому как художественный текст ценен своей свежестью и отсутствием штампов.
Автор: lion9
Дата сообщения: 29.12.2013 03:03

Цитата:
Ну чтобы совсем удостовериться, что правильно понимаю - сегмент это ровно одно предложение. Нельзя указать устойчивое словосочетание или абзац, состоящий из двух-трех предложений?


Правила сегментирования задаются в памяти переводов, и тоже регулярками. Можно сегментировать по параграфам, можно - по предложениям. Иногда приходится исправлять ошибки сегментирования, типа «See para. 14 below» и «See paras. 14-18 below» по умолчанию разбивает на два сегмента «See para.» и «14 below», считая «para.» или paras. концом предложения. Поэтому в правила сегментирования приходится добавлять исключение типа:

Before break:
par.{1,2}\.+

After break:

\s\d+

Разумеется, для художественных текстов память перевода не очень пригодна, повторений не будет. Но вот двуязычный текст всё равно иметь имеет смысл, хотя бы в плане проверки терминологии в QA Checker типа Verifika.

Автор: XPerformer
Дата сообщения: 29.12.2013 03:05
Это я к тому, что, например, гугл-переводчик вероятно работает по другому алгоритму. Он обучается, это заметно - год от года переводит лучше, но падежи обрабатывает и уникальные тексты худо-бедно переводит.
Автор: lion9
Дата сообщения: 29.12.2013 03:08

Цитата:
Это я к тому, что, например, гугл-переводчик вероятно работает по другому алгоритму.


Память перевода и автоматизированный переводчик (машинный перевод) - совершенно разные вещи. Память перевода ничего не переводит сама - она лишь предлагает процентные совпадения из ранее переведённых сегментов.
Автор: XPerformer
Дата сообщения: 29.12.2013 03:14
Возвращаясь к указанной вами связке

Цитата:
Микс из Trados Studio 2014 с Multitrerm + Multitern Extract + TermInjector + QTranslate + проверка Common и Terminology в Verifika

вы в своей работе не используете автоматический переводчик?
Автор: Xoanon
Дата сообщения: 29.12.2013 08:44

Цитата:
Это я к тому, что, например, гугл-переводчик вероятно работает по другому алгоритму. Он обучается, это заметно - год от года переводит лучше, но падежи обрабатывает и уникальные тексты худо-бедно переводит.


Да, гугл-переводчик работает на базе машинного обучения на огромных объемах параллельных текстов, с которых собираются вероятности перехода слов исходного языка в слова целевого языка с учётом контекста до пяти слов слева и справа (возможно, контекст расширили с тех пор), а также с учётом штрафов за вставку/удаление/перестановку слов. Также используется языковая модель целевого языка. А также прикручиваются и другие навороты, и оптимизации (как например, мемоизация фрагментов, наиболее часто отправляемых пользователями на перевод).

Почитайте про статиcтические модели перевода номер 1 и номер 2 от IBM, если хотите вникнуть в тему:
http://www.cs.columbia.edu/~cs4705/notes/ibm12.pdf

Качество гугл-переводчика растет год от года, так как растет объем, качество и охват тематики параллельных текстов, плюс алгоритм улучшается засчет новых идей. Самое интересное, что гугл-переводчик мог бы переводить еще лучше, но это было бы слишком ресурсоёмко для бесплатного сервиса, которым пользуются миллионы людей.
Автор: ghosty
Дата сообщения: 29.12.2013 09:08
XPerformer

Цитата:
Получается, что память переводов хороша для технических текстов, таких как компьютерные инструкции или тексты договоров, где много повторяющихся фрагментов.

У меня достаточно большой опыт работы в SDL Trados, а сейчас перевожу один из диалогов Платона. И вот ни разу не повернулась мысль воспользоваться Традосом
Для нетехнических текстов он не просто бесполезен, но вреден.
Автор: lion9
Дата сообщения: 29.12.2013 09:47

Цитата:
вы в своей работе не используете автоматический переводчик?


Для не локализованных TermInjector участков использую Qtranslate (автоматический перевод Google), с последующей корректурой предложенного варианта.

Добавлено:

Цитата:
Для нетехнических текстов он не просто бесполезен, но вреден.


Полезен даже для художественных, при сохранённом Source удобно вычитывать окончательный вариант перевода.

Далее, для примера беру Апологию Сократа:

«о мужи афиняне» - выражение повторяется по всему тексту, такое имеет смысл включить в TermInjector и не перепечатывать каждый раз.
В тексте много имён, в которых легко опечататься. Имея на руках двуязычных SDLXLIFF и загнав правильное написание имён в терминологический словарь Verifika, легко сверить, нет ли ошибок.
Автор: XPerformer
Дата сообщения: 29.12.2013 16:18
Xoanon
Спасибо, вы одним постом выдали такое количество информации
(Поверхностные поиски в интернете к успеху не привели, в основном вода)

Цитата:
вероятности перехода слов исходного языка в слова целевого языка с учётом контекста до пяти слов слева и справа (возможно, контекст расширили с тех пор)

так и думал, что не предложениями, смысла не вижу. Поэтому и удивился, что сегмент - это чаще всего предложение.

Цитата:
Почитайте про статиcтические модели перевода номер 1 и номер 2 от IBM, если хотите вникнуть в тему:
http://www.cs.columbia.edu/~cs4705/notes/ibm12.pdf

Со статьей ознакомлюсь, благодарю.

Цитата:
Качество гугл-переводчика растет год от года, так как растет объем, качество и охват тематики параллельных текстов, плюс алгоритм улучшается засчет новых идей. Самое интересное, что гугл-переводчик мог бы переводить еще лучше, но это было бы слишком ресурсоёмко для бесплатного сервиса, которым пользуются миллионы людей.

Тоже интересный вопрос - реально ли развернуть эту систему на одной машине? понятно, что смысла нет, так система должна обучаться, но меня интересуют скорее технические характеристики базы - насколько велика должна быть база для получения перевода приемлемого качества. Вы пишите об огромных объемах текста, и комбинаций из 10 слов очень много.
Скажем, база поиска яндекса велика и требует множества серверов, хранится распределенно.
Интересно, как обстоит дело здесь - интуитивно мне кажется, что объем базы должен быть под силу современному компьютеру.


Цитата:
Также используется языковая модель целевого языка.

Совсем непонятно, что это - учитывается грамматика языка (порядок слов в предложении и т.п). Или что-то другое? вдруг есть ссылка, где это подробнее написано, буду признателен.
Еще интересный вопрос - что считать "словом", а что его контекстом? Допустим на входе обычное предложение из 9 слов. Маловероятно, что за "слово" надо брать пятое слово, скорее, подлежащее или подлежащее+сказуемое...


Добавлено:
ghosty

Цитата:
У меня достаточно большой опыт работы в SDL Trados, а сейчас перевожу один из диалогов Платона. И вот ни разу не повернулась мысль воспользоваться Традосом
Для нетехнических текстов он не просто бесполезен, но вреден.

Вероятно, это зависит от специфики и объема самого текста.
Сделать механические замены тех словосочетаний, которые не имеют оттенков смысла и всегда переводятся одинаково, в любом случае ускоряет процесс перевода.
Подумалось, что если гугл-переводчик долго обучать только на произведениях поэтических форм, в результате перевода будут получаться стихи. А вот память перевода вряд ли даст такой эффект. Хотя может и ошибаюсь...

Добавлено:
lion9

Цитата:
Для не локализованных TermInjector участков использую Qtranslate (автоматический перевод Google), с последующей корректурой предложенного варианта.

а я решил, что Qtranslate используете как словарь.
Интересна "кухня" профессионального переводчика, спасибо, что делитесь.
Скажите, а словари в работе используете? такие как Lingvo или бумажные?
Все-таки не понял какова последовательность обработки:
сначала память переводов + TermInjector, а потом если надо Qtranslate, потом ручная доводка?

Добавлено:
Xoanon
Похоже, вы хорошо разбираетесь в этой теме. Не подскажите, есть ли ощутимая разница в качестве разных авто-переводчиков? когда-то начал использовать гугл-переводчик, так и продолжаю. Babylon как-то не прижился. Есть смысл пробовать другие - яндекс, microsoft... в случаях, когда гугл не справился?
Автор: lion9
Дата сообщения: 29.12.2013 19:12

Цитата:
а я решил, что Qtranslate используете как словарь.
Интересна "кухня" профессионального переводчика, спасибо, что делитесь.
Скажите, а словари в работе используете? такие как Lingvo или бумажные?
Все-таки не понял какова последовательность обработки:
сначала память переводов + TermInjector, а потом если надо  Qtranslate, потом ручная доводка?


Именно так, всё правильно поняли насчёт последовательности. Только перед этим ещё Multiterm Extract. Словарь основной - сайт www.multitran.ru , Википедия, профильные сайты по тематике перевода, если перевод на английский - проверка употребительности терминологии путём введения её в кавычках в поиск Google, чтобы вывел именно такие фразы, if any, и контекстная сверка термина-кандидата с текстами на профильных сайтах носителей языка.

Автор: Xoanon
Дата сообщения: 29.12.2013 19:43

Цитата:
Тоже интересный вопрос - реально ли развернуть эту систему на одной машине? понятно, что смысла нет, так система должна обучаться, но меня интересуют скорее технические характеристики базы - насколько велика должна быть база для получения перевода приемлемого качества. Вы пишите об огромных объемах текста, и комбинаций из 10 слов очень много.
Скажем, база поиска яндекса велика и требует множества серверов, хранится распределенно.
Интересно, как обстоит дело здесь - интуитивно мне кажется, что объем базы должен быть под силу современному компьютеру.


Всё зависит от требуемой скорости, качества и жанрового охвата. Если вы хотите качество Гугла в любом жанре - вам одной машиной не обойтись.


Цитата:
Совсем непонятно, что это - учитывается грамматика языка (порядок слов в предложении и т.п).

Языковая модель целевого языка - это статистическая модель языка, которая отвечает на вопрос, какая последовательность слов более вероятная в целевом языке. Например, русское слово "большой" на английский может переводиться "large" или "high", к примеру, и просто вероятности перевода даже с учетом контекста не гарантируют вам правильного выбора между этими двумя переводами прилагательного. Тут вступает в действие языковая модель целевого языка, которая, если вы, например, переводите фразу "большой объём данных" и "большой спрос", вам скажет, что вероятность существования комбинации слов "large volume of data" равна столько-то и она больше, чем "high volume of data", и аналогично, "high demand" более вероятно в целевом языке чем "large demand".

Языковая модель строится на основе большого количества текстов одного языка (http://en.wikipedia.org/wiki/Language_model). Из тектов собирается распределение вероятностей комбинаторики на базе униграммов (одного слова), биграммов (двоек слов), триграммов (трое слов), квадриграммов (четверок слов), пентаграммов (пятёрок слов) и т.д. с использованием различных методов сглаживания, свойства Маркова, методов отхода.

Поэтому от модели перевода берутся всегда много вариантов перевода, которые "просеиваются" через языковую модель. При помощи языковой модели решаются и многие грамматические вещи, например, падежи в русском. Для перевода фразы "buy a cow" берется множество комбинаций от модели перевода от наиболее вероятных к менее {купить, приобрести, надыбать, ...} {корова, корову, коровой, корове} и из них само собой языковая модель наиболее вероятным выберет винительный падеж.


Цитата:
Еще интересный вопрос  - что считать "словом", а что его контекстом? Допустим на входе обычное предложение из 9 слов. Маловероятно, что за "слово" надо брать пятое слово, скорее, подлежащее или подлежащее+сказуемое...

Надеюсь, с учетом вышеописанного вам теперь понятно, что Гугл использует только слово, так как он пользуется чисто статистическим подходом машинного перевода. И сила статистического подхода в том, что не нужно вникать в грамматический анализ, а нужно лишь наращивать объем тренировочных данных и увеличивать контекст. Т.е. грубо говоря, можно брать силой, а не умом. Есть и более "умные" подходы с грамматическим анализом и синтезом, но разработка и поддерждание/улучшение системы более ресурсоёмко с точки зрения человеческих ресурсов, поэтому большинство предпочитает статистический метод, который в основном пожирает данные и сервера. Самая мощь получилась бы, если бы гугл наложил статистику еще и поверх грамматики, но он не хочет тратиться на бесплатный сервис для миллионов пользователей.


Цитата:
Похоже, вы хорошо разбираетесь в этой теме. Не подскажите, есть ли ощутимая разница в качестве разных авто-переводчиков? когда-то начал использовать гугл-переводчик, так и продолжаю. Babylon как-то не прижился. Есть смысл пробовать другие - яндекс, microsoft... в случаях, когда гугл не справился?

Можете пробовать, нельзя сказать огулом, что одни лучше, другие хуже, они разные, так как они обучаются на разных массивах параллельных и одноязычных текстах, тексты у них по-разному сбалансированы. Чтобы сказать точно, есть специальные метрики качества машинного перевода NIST/BLEU и др., но вы должны взять случайную выборку текстов разных жанров прогнать через все эти системы, рассчитать NIST/BLEU и тогда можно будет сказать что-то объективно. Но для конечного пользователя - это все равно сказки, ему важен перевод конкретного абзаца. А один такой абзац может будет лучше, другой хуже. Но вы и сами можете выбрать, исходя из сравнения, что вам больше нравится, как переводит.

В любом случае, машинный перевод пока имеет основную цель дать понять, о чем текст на другом языке, донести информацию на иностранном языке, а не заменить профессионального переводчика-человека.
Автор: XPerformer
Дата сообщения: 29.12.2013 19:53
Xoanon


Цитата:
Поэтому от модели перевода берутся всегда много вариантов перевода, которые "просеиваются" через языковую модель. При помощи языковой модели решаются и многие грамматические вещи, например, падежи в русском. Для перевода фразы "buy a cow" берется множество комбинаций от модели перевода от наиболее вероятных к менее {купить, приобрести, надыбать, ...} {корова, корову, коровой, корове} и из них само собой языковая модель наиболее вероятным выберет винительный падеж.

Можно ли сказать, что человек строит фразу по тому же принципу?
Родители в детстве формируют языковую модель, исправляя ошибки. Затем накапливается статистика - чем больше человек общается и читает, тем грамотнее речь.
Если да - получается, что мозг (и особенно мозг профессионального переводчика) хранит весь этот объем информации, который пока не под силу хранить и обрабатывать современному компьютеру (в количестве 1 шт).

Добавлено:

Цитата:
лишь наращивать объем тренировочных данных и увеличивать контекст.

Допустим, вычислительные мощности позволяют резко увеличить контекст - до 20-50 слов.
Разве это повысит качество перевода?
новый абзац обычно означает начало новой мысли, и мне кажется, там может быть другой набор слов для выражения этой мысли, которые только исказят контекст.
Разве не лучше ввести какой-то параметр типа "тональности" всего текста, который можно посчитать достаточно быстро для 50-100 страниц, и найти похожий текст в базе по этому параметру, и брать вероятности по этому тексту? В этом случае перевод может быть даже лучше оригинала, если в базе тексты высокого качества и слова подобраны точнее для этой предметной области.
То есть мой вопрос в том, есть ли смысл "тупо" расширять контекст больше 10-15 слов, дает ли это рост качества?

Страницы: 12345678910111213141516171819202122232425

Предыдущая тема: Ag Copy v 2.5 - программа для быстрого копирования файлов


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.