Советы

Продолжаем увлекательный сериал об ошибках Trados Studio.

Ошибка Error occurred in file ... Attempted to divide by zero возникает при попытке импортировать WSXZ-пакет. Ошибка редкая: Google знает о ней лишь понаслышке, и то — по ссылкам описываются проблемы с термбазами, а на деле оказалось, что нет.

Из-за чего именно возникает проблема, на самом деле неизвестно, но она связана с какими-то ошибками в структуре XLF-файла. Удивительно, что сам по себе проблемный XLF-файл открывается как положено (в нашем случае).

Первое, что желательно сделать, — сообщить о проблеме клиенту. Если он недоступен или сам не знает, как решить эту проблему, проделайте описанные ниже операции. Их общая цель — извлечь XLF-файл из пакета и перевести его отдельно. Порядок действий таков:

• Переименовать файл пакета: заменить расширение WSXZ на ZIP или просто добавить к нему расширение ZIP.
• Распаковать получившийся ZIP-архив.
• Вручную создать в Trados Studio проект с названием, повторяющим название исходного пакета, и тем же языковым направлением.
• XLF-файл из распакованного архива указать как файл на перевод.
• Создать в проекте пустую память переводов и импортировать в нее TMX-файл из распакованного архива.
• Если в распакованном архиве есть TBX-файл, подключить его как термбазу. Для этого нужно предварительно преобразовать его из TBX в SDLTB — как это сделать, расскажем в каком-нибудь из следующих постов, этот и так разросся :)
• Собственно, перевести проект, как обычно.
• Переведенным XLF-файлом заменить XLF-файл с таким же названием в распакованном архиве, ничего не меняя в его структуре.
• Создать из распакованного архива ZIP-архив.
• Заменить обратно расширение ZIP на WSXZ. Дальше, вероятно, нужно будет либо выгрузить этот пакет на SDL WorldServer (если вы ничего не напутали, сервер должен его принять), либо отправить его вашему заказчику, смотря как вы с ним работаете.
• Профит.

Инструкция кажется длинной, на деле все это дольше писать, чем делать — главное, понимать смысл каждого действия. А если XLF-файл небольшой и память переводов никак не сокращает объем работы, его можно перевести, открыв в Trados Studio напрямую — то есть даже не создавая проект.

Если кто-нибудь знает более гуманный способ, расскажите, пожалуйста.

MultiTerm is unable to create the termbase 

Такая ошибка иногда вылетает в Trados Studio при попытке импорта WSXZ-пакета, экспортированного из SDL WorldServer.

Причина этой ошибки простая: в структуре термбазы, включенной в пакет, нет целевого языка. То есть отсутствуют не термины на целевом языке, а сам язык. Это значит, что термбазу можно просто удалить — она никак не поможет вам переводить. А нет термбазы — нет и проблемы.

Метод устранения этой ошибки простой:

• Заменить расширение файла пакета WSXZ на ZIP.
• Разархивировать получившийся ZIP-архив.
• Удалить файл с названием terminology_data.tbx.
• Заархивировать получившийся комплект файлов в ZIP-архив.
• Заменить расширение файла пакета ZIP на WSXZ.

Если вы работаете в Total Commander, удалить файл из архива можно непосредственно, без переименований и разархиваций.

После этих операций WSXZ-пакет должен нормально открыться в Trados Studio.

Есть разные способы разрезать один большой SDLXLIFF-файл Trados Studio на несколько небольших. Один из них — воспользоваться плагином SDLXLIFF Split/Merge, который именно для этого и предназначен.

Но пользоваться им нужно с осторожностью. Он прекрасно делает split (на самом деле не прекрасно, довольно часто артачится), но плохо — merge.

Болезненный случай из практики: пришел проект в Trados Studio, в нем один большой файл, мы его разрезали с помощью плагина, перевели, объединили, вычитали, сдали, все как положено. Через неделю недовольный клиент сообщил, что 600 слов исходного (!) текста из файла куда-то исчезли вместе с переводом.

В результате разбирательств выяснилось, что виноват плагин: он успешно разрезал файл, но, объединяя переведенные части, просто отбросил некоторые из них. Ну не понравились они ему.

Объединенный SDLXLIFF-файл был сгенерирован неправильно. При этом никаких сообщений об ошибках не появлялось, а Trados Studio даже не заметила подмены — приняла его как родного. Был неприятный разговор с клиентом.

С тех пор мы используем плагин SDLXLIFF Split/Merge только для split. А merge выполняем средствами Студии, по схеме:

• создать временную память переводов
• залить в нее все сегменты всех переведенных частей
• претранслировать этой памятью исходный большой SDLXLIFF-файл

При этом возникают некоторые нюансы, но они менее болезненны, чем потеря текста.

Впрочем, это была одна из ранних версий плагина — случай произошел года три назад. Возможно, более свежие версии уже избавились от этой детской болезни.

Акт первый здесь, а также на нашем телеграм-канале.

Случай из практики. Пришел проект в Trados Studio. Файл один и огромный, а дедлайн близко — приходится резать его на части, чтобы назначить разным переводчикам. Это нехорошо, но клиент отсрочки не дает, нет выхода.

Режем файл с помощью прибамбасины SDL Split/Merge. Получаем пачку пронумерованных SDLXLIFF-файлов с жуткими именами. Но при попытке открыть их вываливается ошибка:

В справочном разделе SDL есть статья о том, как эту ошибку устранить, но она не помогает. А дедлайн близится.

Что делать? Пробуем открыть в другой кошке. Первая же, memoQ, открывает их без разговоров — жалуется только, что не сможет сделать превью. После перевода еще предстоит процесс корректного обратного переноса в Trados Studio, но это уже дело техники.

Строго говоря, Trados Studio тут ни при чем: проблемные файлы созданы в сторонней программе. Но она могла бы справиться с родным форматом. memoQ же как-то их открывает.

Это очередная малоинформативная ошибка Trados Studio. Сообщение о ней появляется при операциях с памятью переводов (translation memory) — в частности, при поиске терминов в конкордансе с помощью команд F3 и CTRL+F3. При этом Trados Studio не вылетает, а некоторые термины даже находятся.

Сообщение об ошибке, как обычно, не помогает идентифицировать ее причину:

В дальнейшем при попытке найти термин в конкордансе выводится ошибка There was a problem while searching. See the Messages Window for more information:

А в Messages Window сообщают, что An error occurred while using the translation provider и что The translation memory file is corrupt:

Судя по всему, эта ошибка возникает, когда доступ к SDLTM-файлу, в котором содержится память переводов Trados Studio, пытаются получить две программы одновременно.

Чаще всего конфликт доступа возникает, когда SDLTM-файл находится не в папке по умолчанию, а в папке, автоматически синхронизируемой с каким-нибудь облаком, — Google Drive, Dropbox и т. п.

Типичный сценарий такой: Dropbox (например) синхронизирует локальный SDLTM-файл с облачным хранилищем, и в этот момент вы вносите (точнее, пытаетесь внести) в него изменение, подтвердив сегмент в Trados Studio командой CTRL+ENTER. Между Trados Studio и Dropbox происходит короткая драка, в результате которой возникает сбой — те самые «one or more errors».

На различных переводческих форумах дают две рекомендации для такого случая: реиндексировать память переводов и отключить функцию upLIFT (распознавание частичных совпадений). Ни то ни другое делать нежелательно: реиндексация может привести вашу память переводов в такое состояние, что ее уже ничем не восстановишь, а функция upLIFT, если ее отключить, перестанет работать (Кличко оценил бы эту фразу). В любом случае предварительно стоит сделать резервную копию SDLTM-файла.

Как бы то ни было, нам ни одна из этих рекомендаций не помогла. А помог следующий метод:

• Загрузить SDLTM-файл в Xbench.
• Экспортировать оставшиеся в живых сегменты из Xbench в TMX-файл. Для этого нужно нажать CTRL+R, затем в появившемся окне снять флажок Untranslated items, указать имя TMX-файла, исходный язык и целевой язык:

Таким образом, Xbench используется не в качестве QA-инструмента, а в качестве конвертора.

• После этого перейти в Trados Studio, зайти в настройки злополучного проекта, перейти там в раздел Translations memory and autimated translation, отключить там заглючившую память переводов, создать новую память с тем же языковым направлением и импортировать в нее TMX-файл, созданный в Xbench. Мы это делали с такими параметрами (но вам могут больше подходить свои):

После этих операций операция сообщение One or more errors occurred больше не выводится. Для окончательного устранения ошибки желательно перезагрузить Trados Studio.

Иногда Trados Studio при импорте пакета выводит загадочное сообщение:

При этом пакет не импортируется, проект в списке не появляется и работать невозможно. Причем папка System Volume Information действительно есть на диске, но она скрытая, и непонятно, какое отношение она имеет к проектам Trados Studio.

Из-за чего возникает такая ошибка, не вполне ясно, но метод ее устранения довольно прост:

• Закрыть Trados Studio.
• Удалить файл UserSettings.xml в папке Trados Studio. Обычно он находится в папке c:\Users\[USER NAME]\AppData\Roaming\SDL\SDL Trados Studio\[Trados Studio version].
• Запустить Trados Studio.
• Импортировать пакет повторно.

Этот метод работает в Trados Studio 2015 и 2017, но должен работать и в других версиях.

Повсеместная распространенность английского языка привела к тому, что в мире нет единого общепризнанного лингвистического центра, который утверждает его правила и решениям которого подчиняются все остальные. Слишком уж много людей на нем говорят.

Всем известно о разнице между британским и американским английским. Есть еще австралийский, новозеландский, канадский и много других. При этом каждый англоговорящий уверен, что у него английский «правильный», а у остальных — искаженный. Попробуйте сказать британцу, что правильно писать не programme, а program.

Ситуация усложняется тем, что даже в границах одной страны часто нет одного всеми признаваемого свода правил английского языка. Стремясь как-то их унифицировать, крупные издательства и новостные агентства разрабатывают собственные стилевые руководства. Так появились The New York Times Manual of Style and Usage, University of Oxford Style Guide, знаменитый The Chicago Manual of Style и т. д. — их не перечесть.

Все это серьезные проработанные справочники один авторитетнее другого. Но среди них нет ни одного «окончательно правильного», на который можно было бы сослаться при возникновении лингвистических разногласий.

Кроме того, есть множество специализированных руководств разной степени авторитетности. Крупные IT-компании обычно разрабатывают собственные технические гайдлайны. Вот некоторые:

• Microsoft Writing Style Guide
• Apple Style Guide
• Google Developer Documentation Style Guide
• IBM Developer Style Guide
• SUSE Documentation Style Guide

Они тоже во многом друг другу противоречат, но каждая компания считает, что ее руководство — правильное. Так сказать, всяк кулик свое болото хвалит.

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

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

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

Стремление максимизировать количество пользователей, минимизировав при этом количество недовольных, вынуждает крупных разработчиков идти первым путем. Например, если вы пожелаете установить в Windows поддержку английского языка, Microsoft попросит вас выбрать конкретную его «реализацию» (это скриншот из Windows 7):

Выработав метод работы с языковыми вариациями английского, немецкого, испанского и т. д., разработчики начинают слепо применять его ко всем языкам, в том числе к русскому. И тут русский язык играет с разработчиками злую шутку.

В Windows появляются многочисленные вариации русского (скриншот из Windows 10):

SDL применила тот же подход в Trados Studio:

Если разобраться, чем эти разновидности русского друг от друга отличаются с точки зрения лингвистики, выяснится, что — ничем.

На русском говорят во многих странах, не только в России. А в Беларуси, Казахстане и Киргизии он даже является официальным. Существуют его диалекты и региональные особенности, но они «не тянут» на то, чтобы называться отдельными языками. Где бы и кто бы ни говорил на русском, формальные правила одинаковы для всех.

В отличие от английского, немецкого и многих других языков, в русском есть единый центр, который утверждает его правила: это Российская академия наук.

Поэтому не существует украинского русского, белорусского русского и т. п. Все эти RU-UA, RU-KZ, RU-BY — это не про лингвистику: это реверанс производителей программ перед пользователем. Нормативный русский существует только один: RU-RU.

SDL сплоховала, но большинство производителей «кошек» (программ автоматизированного перевода, CAT tools) этой ловушки избежали. Вот несколько примеров.

memoQ:

Smartcat (тут неудивительно — разработчики из России):

Отдадим должное Microsoft — количество русских языков в текстовом редакторе Word упало всего до двух, почему-то остался «молдавский русский»:

Перефразируем Булгакова: русский существует только один — первый, он же и последний.

Trados Studio — это источник огромного количества ошибок, порой весьма экзотических. Методы их устранения [должны быть] описаны в справочном разделе на портале SDL. Их уже много набежало по хештегу #tradosstudio на этом сайте и на нашем канале.

Если вы столкнулись с загадочной ошибкой, то прежде чем закапываться в справку и форумы, проверьте сначала основные проблемные места. Общий метод устранения непонятных ошибок Trados Studio, выработанный в результате набивания многочисленных шишек, выглядит так:

• Убедитесь, что общая длина пути к SDLXLIFF-файлам проекта не слишком большая. Суммарная длина не должна превышать 255 символов.
• Убедитесь, что в названиях папок и файлов нет символов, нехарактерных для языков, с которыми вы обычно работаете (иероглифов, букв RTL-языков, всевозможных вариаций букв с надбровными и подвздошными черточками, кружочками и т. п.). Студия относится к ним с подозрением. Например, вот эта ошибка вызвана тем, что кириллические символы в названии проекта не в той кодировке.
• бедитесь, что файлы проекта, особенно SDLXLIFF и SDLTM, не витают в облаках — в смысле, не лежат в стандартных папках Dropbox, Google Drive и т. п. Если работать прямо в облаке, то при любом изменении файла Trados Studio и локальное облачное приложение будут драться — кто первый его обработает, и станет уже не до перевода.
• Убедитесь, что в импортированном пакете всё хорошо с рабочей памятью переводов (TM):
• что она вообще есть — иногда ее просто забывают подключить;
• что она активна — напротив нее установлен флажок в настройках проекта;
• что языковое направление в ней совпадает с языковым направлением текущего SDLXLIFF-файла;
• что у файла памяти переводов (SDLTM) нет атрибута Read Only, а если память онлайновая — что есть подключение к серверу.
• То же самое с термбазой.

* * *

Если не помогло, ищите причину ошибки точным поиском по тексту сообщения об ошибке.

Сначала разберем, из-за чего эта ошибка возникает.

Когда вы создаете пакет на перевод в Trados Studio, каждый файл, который вы в него включаете, конвертируется в формат SDLXLIFF, и перевод выполняется уже в нем.

Имя SDLXLIFF-файла формируется предельно просто: к имени исходного файла добавляется расширение SDLXLIFF. Таким образом, файл с названием, например, Text_to_translate_asap.docx превращается в файл Text_to_translate_asap.docx.sdlxliff.

К слову, отсюда следует, что по имени файла очень просто восстановить имя и тип исходного файла, из которого он был создан. Понятно, что файл Trados Studio с именем Translate_right_now!.xlsx.sdlxliff создан из файла Excel Translate_right_now!.xlsx.

Когда перевод выполнен, возникает обратная задача: нужно воссоздать исходный файл, заменив в нем исходный текст на переведенный. Эта операция называется Clean — то есть «очистка» файла от исходного текста. Чтобы выполнить эту операцию, Trados Studio нужно где-то сохранять исходный файл.

Если исходный файл небольшой, он сохраняется прямо в теле SDLXLIFF-файла. Если большой — Trados Studio «запоминает», где он лежит, чтобы потом к нему при необходимости обратиться.

Какой размер файла считается маленьким, а какой большим, определяет параметр в Trados Studio, запрятанный здесь:

Files > Options > File Types > SDLXLIFF > General:

По умолчанию он равен 20 МБ. Забегая наперед, скажем, что имеет смысл увеличить это значение.

Если работа над проектом выполняется на том же компьютере, на котором он был создан, проблем, как правило, не возникает, т. к. Trados Studio «знает», где хранятся все исходные файлы. Если же файлы были перемещены или если пакет передается на другой компьютер, Trados Studio теряет к ним доступ.

Если Trados Studio вывела сообщение «Dependency file not found», это значит, что ей потребовались исходные файлы, но она их «потеряла». Поэтому она поинтересуется: «Would you like to browse for this file?» — то есть попросит указать путь к ним.

Идеальный вариант — если у вас есть исходные файлы. Тогда на этот вопрос нужно ответить «Да» и просто указать путь к ним. Ошибка исчезнет, Trados Studio успокоится и продолжит работать как обычно.

Если исходных файлов у вас нет или вы решили не указывать путь к ним, отвечайте «Нет» — собственно, ничего другого и не остается. Вы сможете продолжать работу над текстом, но не сможете выполнить некоторые операции с файлами (в частности, Save Target As, Preview, Generate Target Translations и т. п.). Чаще всего этого и не требуется.

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

Но бывают ситуации, когда из-за этой ошибки Trados Studio отказывается работать дальше. В этом случае самое главное — сохранить память переводов (translation memory), с которой вы работали. В ней хранятся все переведенные вами сегменты, если вы их подтверждали при переводе. Их можно будет применить в исправленном пакете Trados Studio.

Время от времени возникает проблема: в длинном тексте нужно везде заменить прямые кавычки ("") на шевроны, они же «ёлочки» («»). Сделать это средствами поиска и замены сложно: прямая открывающая и прямая закрывающая кавычки — это один и тот же символ, тогда как открывающий и закрывающий шеврон — символы разные.

Сложно найти четкий признак — какая прямая кавычка должна превратиться в открывающую, какая в закрывающую. По идее, таким признаком мог бы быть пробел: комбинацию «пробел + прямая кавычка» хочется заменить на «пробел + открывающий шеврон», а комбинацию «прямая кавычка + пробел» — соответственно, на «закрывающий шеврон + пробел». Но если вы попробуете сделать такую замену, быстро выяснится, что из этого правила слишком много исключений и проще заменить прямые кавычки на шевроны вручную.

Тем не менее, способ быстрой полуавтоматической замены существует. Признаком замены является парность кавычек: если в тексте встретилась открывающая кавычка, то где-то дальше в этом же тексте обязательно должна встретиться парная ей закрывающая.

Воспользуемся для «отлова» парных прямых кавычек регулярными выражениями. Нажмите в Trados Studio комбинацию клавиш CTRL+H и настройте появившееся диалоговое окно Find and Replace следующим образом:

В поле Find what введите "(.+?)", в поле Replace with — «$1», а в нижней части окна не забудьте поставить флажок Regular expressions.

Нажмите Find Next — и Trados Studio найдет ближайший фрагмент, заключенный в прямые кавычки. Нажмите Replace — кавычки заменятся на шевроны (при этом текст внутри них сохранится) и произойдет переход к следующему фрагменту.

Конечно, есть и исключения — в некоторых случаях такой запрос будет промахиваться:

• Если текст внутри кавычек содержит теги (при замене текст останется, но теги исчезнут).
• Если в тексте есть ошибка и открывающая или закрывающая кавычка просто отсутствует.
• Если фрагмент большой и открывающая кавычка оказалась в одном сегменте, а закрывающая — другом.
• Если хотя бы одна из кавычек является обозначением символа дюйма (хотя вообще-то в русском языке такое обозначение не совсем корректно и лучше просто написать «дюйм» словами).

Поэтому слепо нажать кнопку Replace All нельзя — нужно пройти по всем случаям, нажимая Replace  и убеждаясь, что замена происходит корректно. Но это все равно быстрее, чем заменять кавычки вручную.

Пусть у вас есть файл Word, содержащий большое количество адресов электронной почты, примерно такой:

(Все имена, адреса и телефоны здесь случайны.)

Вам нужно перевести этот текст в Trados Studio. Вы создаете проект, и в ней этот текст выглядит так:

Но, как видим, в тексте упоминается очень много адресов электронной почты, которые не подлежат переводу. Если «переводить» их, последовательно подтверждая сегменты, на это уйдет много времени. Но есть способ скопировать их в таргет и подтвердить все сразу.

Воспользуемся тем, что существует отличительный признак адресов электронной почты — знак @ («собака»). Нам нужно найти и отфильтровать все сегменты, в которых присутствует этот знак. Для этого перейдите на ленте на вкладку Review и введите этот знак в поле Search. Поскольку мы ищем его только в исходном языке, важно, чтобы в области поиска было выбрано In Source:

Нажмите клавишу ENTER. На рабочей области отобразятся только те сегменты, в которых присутствует знак @, — в нашем случае это адреса электронной почты:

Теперь щелкаем ячейку с номером первого сегмента (2), скроллим список до конца и с нажатой клавишей SHIFT щелкаем ячейку с номером последнего сегмента. Все сегменты будут выделены:

Теперь переходим на вкладку Home и нажимаем кнопку Copy Source to Target. 

Осталось подтвердить все отфильтрованные сегменты. Для этого снова выделяем их все, щелкаем правой кнопкой мыши по номеру любой ячейки и меняем статус на Translated:

После этого опять переходим на вкладку Review и снимаем фильтр кнопкой Reset Filters:

Таким образом, все адреса электронной почты скопированы в ячейки целевого языка, а все содержащие их сегменты подтверждены.

Аналогичным образом можно отфильтровывать и подтверждать любые сегменты, если у них есть четкий признак, по которому их можно отфильтровать.

Месяц тому назад мы говорили об отображении скрытых символов в файлах Word. Поскольку скрытые символы помогают работать над текстом, имеет смысл рассмотреть, как они отображаются в основных CAT-программах.

Trados Studio

Находясь в режиме Editor, перейдите на вкладку Home на ленте и нажмите вот эту кнопку:

В Trados Studio нет предустановленной комбинации клавиш для отображения скрытых символов, но вы можете установить ее самостоятельно в настройках программы. 

memoQ

В memoQ отображение скрытых символов требует нескольких неочевидных действий.

Выберите memoQ (на ленте) > Options > Options. Появится диалоговое окно Options. В левой его части выберите пункт Appearance, затем в правой части установите флажок Show non-printing characters:

 Xliff Editor

В Xliff Editor есть такой же переключатель, как в Word и Trados Studio:

TagEditor

Такой же переключатель есть и в TagEditor (эта программа входит в пакет Trados 2007):

Transit NXT

В Transit NXT нужно перейти на вкладку View на ленте, затем установить флажок Special characters:

Wordfast Pro

Переключатель скрытых символов в Wordfast аналогичен переключателям в TagEditor, Word и Xliff Editor:

Memsource

Такая же кнопка предусмотрена и в Memsource Editor: