Подготовка файлов к переводу: чек-лист для команды¶

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

Подготовка файла к переводу - это приведение исходного текста, структуры и сопроводительных материалов к виду, в котором переводчик может понять содержание и назначение каждого фрагмента. Речь не только о чистом DOCX. Нужно определить финальную версию, убрать неоднозначность, объяснить термины и передать требования к результату.

В статье разобраны документы Word, материалы для локализации и ситуации, когда сложную верстку или скриншоты нужно планировать отдельно. Конкретные рекомендации Microsoft могут меняться, поэтому сверяйте интерфейс и актуальные инструкции по ссылкам на официальную документацию.

Что подготовить до передачи файла¶

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

Перед отправкой соберите рабочий пакет:

1. Финальный исходный файл с понятным названием.
2. Краткий бриф: аудитория, назначение текста, целевой рынок и желаемый тон.
3. Глоссарий с утвержденными вариантами терминов, названий и имен.
4. Правила стиля, если у компании уже есть такие требования.
5. Контекст для неоднозначных фрагментов, строк интерфейса и placeholders.
6. Связанные материалы, которые помогают понять содержание: предыдущая версия, скриншот продукта, описание функции или ссылка на соседний раздел.
7. Требования к итоговому формату и пояснение, какие элементы нельзя менять.

Каждый пункт решает отдельную задачу. Финальный файл снижает риск перевода устаревшей версии. Глоссарий задает единый выбор терминов. Бриф помогает переводчику выбрать подходящий регистр и уровень формальности, а контекст объясняет, как использовать отдельный фрагмент.

Не отправляйте папку с десятком файлов и короткой запиской «переведите актуальное». Даже если команде очевидно, какой документ главный, исполнителю придется угадывать. Назовите файл так, чтобы его версию и назначение можно было понять без устного пояснения, например product-guide-final-for-translation.docx. Слово final полезно только в том случае, если внутри действительно финальный текст.

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

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

«Даже изменение одного слова может потребовать переработки предложения для естественного звучания».

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

Для контроля версий используйте короткое правило: укажите, кто утверждает исходник, как называется версия для перевода и каким способом команда передает изменения после старта. CAT-инструменты и память переводов могут помогать поддерживать локализованный текст в соответствии с изменениями исходника, но сами по себе не решают вопрос, какая версия утверждена (Microsoft Learn).

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

Как подготовить Word и другие документы¶

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

Сначала сохраните отдельную копию для перевода. Затем выполните проверку по порядку:

1. Сверьте содержимое с утвержденной версией и названием проекта.
2. Разберите все исправления: примите те, которые входят в финальный текст, и отклоните те, которые не должны попасть в перевод.
3. Удалите комментарии, которые не нужны исполнителю, или перепишите их как ясные инструкции.
4. Проверьте скрытый текст, сноски, подписи к таблицам, колонтитулы и текст в фигурах.
5. Запустите Document Inspector как заключительную проверку сведений, которые могут остаться в Word.
6. Проверьте заголовки, списки, таблицы и ссылки после очистки.
7. Сохраните подготовленную копию отдельно от рабочих черновиков.

Microsoft Support поясняет, что режим No Markup только временно скрывает исправления. При повторном открытии документа изменения снова станут видны, если их не принять или не отклонить (инструкция Microsoft Support).

«Режим No Markup только временно скрывает изменения. При следующем открытии документа они снова будут видны».

Вид документа на экране не доказывает, что файл очищен. Перед передачей нужно принять или отклонить исправления, а не маскировать разметку настройкой отображения.

Document Inspector помогает проверить исправления, комментарии, скрытый текст, имена в свойствах документа и другую информацию перед отправкой. Запускайте его на копии, чтобы случайно не изменить рабочий оригинал; после проверки просмотрите файл вручную, поскольку автоматическая проверка не заменяет редакторский просмотр (Microsoft Support).

Затем проверьте структуру. Заголовок, который выглядит крупнее основного текста только потому, что ему вручную назначили размер шрифта, может не распознаваться как заголовок документа. Microsoft советует использовать стили Word вместо ручного оформления каждого заголовка и элемента; Markdown и DITA XML дают более структурированные способы подготовки документации (Microsoft Learn).

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

Проверьте таблицы отдельно. Убедитесь, что заголовки колонок понятны, объединенные ячейки не скрывают связь между значениями, а сокращения расшифрованы или объяснены в брифе. Табличный фрагмент может быть грамматически коротким, но его значение зависит от колонки и соседних строк. Если ячейка содержит только «Да», «Нет» или название категории, добавьте пояснение о том, к какому вопросу относится ответ.

Не рассчитывайте, что исходная длина строки сохранится на другом языке. Если макет допускает только ограниченное число знаков, укажите ограничение переводчику и объясните, где оно действует. Microsoft рекомендует указывать требования к длине и недопустимые символы в контекстных комментариях к локализуемой строке (Microsoft Learn).

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

Особенно внимательно планируйте материалы для печати. Microsoft отмечает, что локализованную печатную документацию иногда нужно заново верстать для целевого рынка. Форматы бумаги и предположения о разрывах строк могут отличаться: в руководстве сопоставляются форматы ISO 216, применяемые в большинстве стран, и американские форматы Letter и Legal (Microsoft Learn).

Если переводятся скриншоты продукта, выясните, должен ли итог показывать локализованную версию интерфейса. Microsoft указывает, что для этого скриншоты может потребоваться пересоздать, а такая работа влияет на планирование проекта (Microsoft Learn). Передайте исходные изображения и подпишите, какие элементы нужно перевести, какие названия должны совпадать с интерфейсом, а какие детали изображения менять нельзя.

Как сделать исходный текст понятным переводчику¶

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

Начните с орфографии и грамматики. Microsoft прямо советует проверить их до отправки строк переводчику, чтобы уменьшить количество вопросов и повторной работы (Microsoft Learn).

«Перед отправкой строк переводчикам проверьте орфографию и грамматику».

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

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

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

Избегайте двусмысленных слов. Microsoft приводит пример английского слова light, которое может означать свет, легкий вес или низкую интенсивность, и советует делать формулировки понятными по контексту (Microsoft Learn). В русском тексте похожую проблему создают короткие слова и сокращенные фразы без окружения. Если одно слово может обозначать действие, свойство или объект, добавьте пояснение в исходник либо контекстный комментарий.

Разверните плотные цепочки существительных. Формулировка вроде «проверка срока ответа клиента» может быть истолкована по-разному: проверяется срок, ответ или клиентское действие? Перепишите предложение так, чтобы отношения между элементами были ясны: «Проверьте, сколько времени клиенту отводится на ответ». Microsoft предупреждает, что цепочки существительных могут быть неоднозначны между языками, и советует прояснять смысл исходной фразы (Microsoft Learn).

Сокращайте внутренний жаргон или объясняйте его. Команда может знать, что «снять блок» означает разрешить действие в интерфейсе, но переводчику без контекста неясно, идет ли речь о блокировке пользователя, элемента страницы или операции. Вместо неясного сокращения добавьте определение, короткий пример или пояснение места использования.

Разделяйте содержание и инструкцию. Фраза «Здесь использовать вариант для новых пользователей» не должна случайно попасть в переводимый текст. Поместите указание в комментарий и ясно обозначьте, к какому фрагменту оно относится. Если комментарий содержит решение редактора, а не справку переводчику, отметьте это отдельно.

Передайте сведения об аудитории и тоне. Для одного и того же текста может понадобиться нейтральный интерфейсный стиль, формальное обращение или понятное объяснение для новых пользователей. Не ограничивайтесь словами «сделайте естественно»: укажите, кто читает материал, где он появится и какой тон принят в других материалах.

Контекст помогает, когда строка короткая или повторяется в разных местах. Microsoft отмечает, что одинаково написанные строки в разных ситуациях могут требовать разных переводов, поэтому для каждого употребления полезен механизм передачи контекста (Microsoft Learn). Например, Open может быть командой «Открыть» или признаком того, что объект открыт. Укажите назначение конкретного экземпляра, а не только общий переводимый список.

Что передавать для программных строк и локализации¶

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

Для каждой короткой строки подготовьте контекст:

• где она показывается: кнопка, сообщение об ошибке, заголовок или подсказка;
• какую функцию выполняет;
• кто ее видит и при каких условиях;
• является ли фраза существительным, глаголом, командой или статусом;
• связана ли строка с соседними элементами;
• есть ли ограничение длины или запрещенные символы;
• какие термины и placeholders должны остаться согласованными.

Microsoft советует добавлять комментарии о том, где и как появляется строка, какова ее функция и при каких условиях она отображается (Microsoft Learn). Комментарий должен помогать принять решение, а не повторять строку другими словами.

Placeholder - это переменная или заменяемый фрагмент в тексте, например имя пользователя или значение параметра. Объясните переводчику, что означает каждая переменная, и приведите пример значения. Имя переменной само по себе может быть непонятным. Microsoft рекомендует пояснять placeholders и давать пример того, что подставится при показе строки (Microsoft Learn).

Например, строка Hello, {name} содержит переменную {name}. Без пояснения переводчик не знает, будет ли там имя человека, название команды или имя файла. Короткая заметка «{name} - имя пользователя, например Анна» снимает эту неопределенность. Если placeholder нельзя изменять, отметьте это в формате, понятном команде и переводчику.

По возможности выбирайте именованные placeholders вместо безымянных позиционных обозначений. В записи с несколькими переменными понятное имя дает больше контекста, чем общий номер или тип. Microsoft рекомендует давать переводчикам как можно больше контроля над порядком placeholders и отмечает, что в целевом языке их порядок может отличаться от исходного (Microsoft Learn).

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

Не собирайте предложение из отдельных склеенных фрагментов, если можно передать его целиком. В таком фрагменте переводчик часто не видит, какие слова будут рядом, а порядок слов, знаки препинания, пробелы и формы множественного числа могут зависеть от языка. Microsoft рекомендует писать полные строки вместо склеивания частей предложения в большинстве случаев (Microsoft Learn).

«Лучшая практика - никогда не склеивать строки».

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

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

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

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

Когда нужны справочные материалы, а когда - отдельная подготовка¶

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

Минимальный комплект зависит от типа материала:

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

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

Структуру документа тоже стоит выбирать по масштабу работы. Microsoft описывает стили Word как минимальный шаг к структурированному авторингу, а Markdown и DITA XML - как более структурированные варианты для документации (Microsoft Learn). Для небольшого документа удобнее оставаться в DOCX. Для технической документации с повторяющимися компонентами команда может выбрать формат, в котором структура и отдельные элементы описаны явно.

Отдельная подготовка нужна и для материалов, которые должны выходить в печать. Переводчик отвечает за текст, но макет может потребовать пересборки из-за длины переводных фраз, формата бумаги или правил переносов. Microsoft обращает внимание на различия в форматах бумаги и на то, что правила разбиения строк отличаются между языками (Microsoft Learn). Уточните, кто отвечает за финальную верстку, чтобы не считать исходный макет гарантией готового результата.

Для указателей, индексов и алфавитных списков также проверьте требования целевого языка. Microsoft предупреждает, что правила сортировки и индексирования могут различаться между языками, поэтому локализованный индекс должен соответствовать правилам целевого языка (Microsoft Learn). Если такой элемент важен для публикации, включите его в список проверки, а не оставляйте в исходной сортировке.

Справочные материалы не должны подменять ясный исходник. Контекстный комментарий способен объяснить, где появляется строка и что означает переменная, но он не исправит противоречивую формулировку в самом тексте. Microsoft отдельно отмечает, что метаданные помогают переводчикам, когда назначение строки или placeholder неясно, но не заменяют понятный исходный текст (Microsoft Learn).

Ошибки подготовки, из-за которых растет объем работы¶

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

Вторая ошибка - менять исходник после начала перевода без объяснения. Переводчик может уже обработать прежний вариант, а команда отправит новую версию без списка отличий. В результате нужно выяснять, какие изменения затрагивают перевод и какие уже согласованы. Microsoft предупреждает, что правки после завершения перевода способны вызвать дополнительную работу над предложением (Microsoft Learn).

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

Четвертая ошибка - передавать глоссарий без пояснений. Перечень терминов помогает согласовать варианты, но не отвечает на вопрос, где термин применяется и что означает в продукте. Добавляйте короткие определения, отмечайте запретные варианты и различайте похожие названия функций.

Пятая ошибка - собирать предложение из фрагментов. Такой подход может скрыть контекст и не дать переводчику переставить части фразы. Microsoft описывает проблемы с порядком слов, пунктуацией, пробелами и формами множественного числа при склеивании текста (Microsoft Learn).

Шестая ошибка - полагаться только на режим отображения Word. No Markup скрывает исправления на экране, но не принимает их и не удаляет. Перед передачей нужно принять или отклонить правки и запустить Document Inspector (Microsoft Support).

Седьмая ошибка - считать, что верстка автоматически подойдет для всех языков и рынков. Переносы, индексирование и форматы бумаги могут отличаться; скриншоты иногда нужно пересоздавать, а печатную документацию - заново верстать (Microsoft Learn). Отметьте такие элементы до начала работы и определите, кто их проверяет.

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

Проверка перед отправкой может быть короткой, если команда использует один и тот же порядок для каждого проекта:

• утверждена ли версия исходника;
• разобраны ли исправления и удалены ли ненужные комментарии;
• проверены ли скрытый текст и свойства файла;
• используют ли заголовки и списки структурные стили;
• проверены ли орфография, грамматика, термины и неоднозначные фразы;
• приложены ли бриф, глоссарий и контекстные заметки;
• объяснены ли placeholders и технические ограничения;
• отмечены ли скриншоты, печатная верстка и другие элементы, требующие отдельного внимания.

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

Частые вопросы¶

Как подготовить документ Word перед отправкой переводчику?¶

Сохраните утвержденную версию, примите или отклоните исправления, удалите ненужные комментарии и проверьте скрытый текст. Затем запустите Document Inspector, проверьте структуру заголовков и сохраните подготовленную копию отдельно от черновика.

Нужно ли принимать исправления в Word перед переводом?¶

Да, если правки согласованы и должны войти в перевод. Примите нужные исправления, отклоните ненужные и не ограничивайтесь режимом No Markup: Microsoft Support указывает, что этот режим только скрывает изменения, которые снова появятся при открытии документа.

Какие справочные материалы отправить переводчику?¶

Передайте краткий бриф об аудитории, назначении текста и тоне, а также глоссарий и стиль-гайд, если они есть. Для коротких строк добавьте скриншот, описание места использования, условия показа и пояснения к переменным.

Как подготовить placeholders и программные строки к переводу?¶

Передавайте полные предложения, а не склеенные фрагменты. Для каждого placeholder поясните его значение и приведите пример; укажите, можно ли менять порядок переменных, и добавьте ограничения по длине или символам, если они заданы.

Почему переводчику нужен финальный исходный файл?¶

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