Клуб технических писателей

март 2015
Третий Гипербатон: кто, где, когда
polinalinen
3 марта 2015, 14:38

Мы начинаем подготовку к третьему Гипербатону, который состоится 18 апреля. Уже сейчас можно добавлять эту дату в свой календарь.

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

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

Участие в конференции бесплатное. Регистрация на мероприятие откроется 18 марта.

Если вы хотите выступить на Гипербатоне с докладом, присылайте тезисы на ya-events@yandex.ru до 15 марта. Мы рассмотрим все заявки и обязательно с вами свяжемся.

Да пребудет с вами Сила!

Команда технических писателей Яндекса

6 комментариев
События,гипербатон,2015,конференция
Особенности создания веб-документации для пользователей
Елена
5 марта 2015, 15:09

Мы начинаем серию публикаций с тезисами выступлений 2014 года. Сегодня речь пойдет о докладе «Особенности создания веб-документации для пользователей» с Гипербатона, прошедшего в рамках конференции Translation Forum Russia в Екатеринбурге.

Как писать, чтобы ответить на вопросы пользователя

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

Откуда мы берем вопросы?

  1. Смотрим, с какими проблемами обращаются в службу поддержки.
  2. Анализируем данные в Яндекс.Метрике ― узнаем, по каким поисковым запросам пользователи приходят в Помощь.
  3. Если сервис новый и пользователям еще не знаком, вопросы формулирует команда сервиса. Также сервис тестирует разработчик документации и описывает возможные пользовательские кейсы.

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

Как поддерживать качество документации

Раньше документацию в Яндексе писали специалисты службы технической поддержки и менеджеры сервисов ― без единого подхода к данному процессу каждый делал это по-своему. Сегодня поддерживать единообразие многих документов для разных сервисов нам помогают следующие правила и инструменты:

  • За каждым сервисом закрепляется один-два ответственных технических писателя. Такой подход позволяет авторам глубоко погрузиться в тему, исключить дублирование контента и оперативно поддерживать его актуальность.
  • В своей работе мы используем внутренние руководства по языку изложения и оформлению иллюстраций ― в них регламентируются основные моменты, разнобой в которых будет заметен или может помешать пользователю. Например, типовые обороты для описания интерфейса, использование технических терминов, оформление ссылок и т. п.
  • Практически для каждого инструмента у нас есть собственные шаблоны, которые мы применяем, чтобы не изобретать «велосипед» при выполнении типовых действий.
  • В работе над текстами руководствуемся несколькими принципами:
    1. Писать коротко и ясно.
    2. Разъяснять только неочевидное.
    3. Формулировать вопросы как пользователь.
    4. Вначале написать, что и зачем делать, потом объяснить ― как.
    5. Структурировать текст с помощью катов, табов, подразделов.

Как упростить поиск по документу

Вот несколько способов упростить поиск по документу:

  • Сделайте хорошую посадочную страницу, чтобы сформировать общее представление о вашем продукте.
  • Создайте отдельную страницу для каждой темы или группы связанных вопросов.
  • Используйте мини-оглавление для быстрого ориентирования на странице.
  • Разместите список полезных ссылок на статьи, к которым пользователи обращаются чаще всего или которые не включены в документ, но могут дополнить его.
  • Используйте двойные заголовки (тег <navtitle>) ― укажите короткий емкий заголовок в содержании, чтобы не перегружать его, а на странице напишите более подробный заголовок, который будет соответствовать запросу пользователя.
  • Укажите ключевые слова для каждой страницы (тег <keyword>) ― это те поисковые запросы, по которым пользователь приходит в вашу веб-справку.
  • По возможности поддерживайте адаптивную верстку для десктопных и мобильных платформ

Что нужно учитывать при подготовке текста к переводу

Сервисы Яндекса доступны в разных уголках планеты. И в каждой стране присутствия мы работаем так, как будто мы местные. Чтобы «говорить» с пользователем на одном языке, в документации:

  • Используем примеры и иллюстрации с местными географическими названиями.
    Русская версия на домене RU

    Русская версия на домене UA

    Украинская версия на домене UA
  • Указываем цены в местной валюте.
  • Учитываем различия в функциональности сервиса. Например, турецкие пользователи ищут товары по-другому, поэтому в Турции у сервиса Яндекс.Маркет иные алгоритмы работы, а значит и другая документация.
  • Публикуем документацию для каждого региона на отдельном домене. Если в стране есть несколько государственных языков или широко распространен второй, то публикуем документацию на всех этих языках. Например, для Турции справка публикуется на турецком и английском языках.

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

  1. Пишем полную версию на русском языке. Она содержит все возможные варианты текста для разных доменов (стран) и языков, в том числе те, которые на русском публиковаться не будут.
  2. Делаем разметку в тексте, с помощью которой указываем, для каких языков и доменов (стран) написан каждый фрагмент.
  3. Отдаем на перевод отфильтрованную версию текста. В нее попадают только те фрагменты, которые нужны на конкретном языке. Фильтрация выполняется автоматически. После перевода получаем полную версию текста на русском языке и переведенные на разные языки версии для других стран.
  4. Перед публикацией снова выполняем фильтрацию и получаем несколько комплектов документации для разных доменов с нужным набором языков.

    Разметка текста


    Текст на домене RU
    Минимальная сумма заказа в Яндекс.Директе составляет 300 рублей.
    Текст на домене UA
    Минимальная сумма заказа в Яндекс.Директе составляет 81 грн.
    Мінімальна сума замовлення в Яндекс.Директі становить 81 грн.

В заключение

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

  • Мы пишем, чтобы ответить на вопросы пользователей.
  • При создании текста следуем принципу «мало букв — много смысла».
  • Структурируем тексты, чтобы упростить поиск по документу.
  • Стараемся говорить с пользователем на одном языке.

Посмотреть видео доклада и презентацию

4 комментария
яндекс,гипербатон,гипербатон 2014 в Екатеринбурге,тезисы доклада
Technical Writing 101: как общаться с разработчиком
Пономарева Вера
11 марта 2015, 15:54
Технический писатель — профессия многогранная. Тут нужно не только уметь писать, разбираться в предмете, но еще и много общаться, чтобы добыть необходимую информацию. Иногда именно эта часть работы оказывается самой кропотливой.
Несколько советов о том, как найти подход к разработчику, от авторов уже знакомой книги "Technical writing 101":
  1. Учитывайте график разработчика. Звоните и приходите в удобное время. Если разработчик предпочитает общаться по почте, пишите письма (даже если сидите в одной комнате).
  2. Не задавайте вопросы по одному. Накапливайте и отправляйте списком.
  3. Научитесь читать код и извлекать из него информацию.
  4. Не задавайте глупых вопросов — сначала попытайтесь найти ответ самостоятельно.
  5. Облегчите жизнь разработчику: вставляйте ваши вопросы в текст документа крупным жирным шрифтом.
  6. Оставаясь вечером на работе, поделитесь пиццей!
  7. Организуйте вычитку таким образом, чтобы каждый разработчик вычитывал свою часть документа.
  8. Кексы. Много кексов!
  9. Посещайте регулярные встречи проекта, чтобы быть в курсе происходящего.
  10. Если ничего не помогает, выходите за него замуж! (Хотя, и это вряд ли поможет.)
На самом деле, в книжке опубликован список из 29 пунктов, я привожу сокращенную версию.
Интересно, а как по вашему опыту — что помогает лучше всего? Предлагаю поделиться собственными наблюдениями и историями.
9 комментариев
Technical Writing 101,почитать,яндекс,рецепты
Пример формулировки "из жизни"
Кристина
17 марта 2015, 16:32

Интересно мнение коллег по цеху. Есть предложение:

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

Считаете ли вы такую формулировку плохой? Или же тут "все в порядке"? Также было бы интересно услышать доводы.

6 комментариев
примеры из жизни
Открыта регистрация на третий Гипербатон
polinalinen
18 марта 2015, 12:21

Добрый день!

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

На конференции вы узнаете:

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

Программа конференции будет опубликована через неделю 25 марта.

Напоминаем о том, что участие бесплатное, но необходимо зарегистрироваться
Регистрация заканчивается 15 апреля в 18:00 по московскому времени.

Да пребудет с Вами сила!

Команда технических писателей Яндекса

6 комментариев
гипербатон,2015,конференция
Когда стоит использовать страдательный залог
Алексей
23 марта 2015, 12:42

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

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

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

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

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

  1. Должны ли читатели знать, кто ответственный за действие? Хотите ли вы, чтобы они знали?

    «После того, как ключ был проверен, сервер возвращает результат проверки.» — неважно, кто и как проверял ключ, важно, что сервер сообщает о результатах.

  2. Поможет ли пассивный залог перейти от одного предложения к другому?

    «Пользователь должен выбрать один из двух вариантов. Персональные настройки определяют доступные варианты.»

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

    Контекст в начале предложения помогает усвоить новую информацию в конце, а недостатки пассивного залога не проявляются.

  3. Какой залог поможет вам показать выбранную точку зрения?

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

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

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

Итого

Используйте пассивный залог в следующих ситуациях:

  • Вы не знаете или не хотите говорить читателям, кто произвел действие (или знаете, что читателям все равно).
  • Вы хотите сдвинуть новую и сложную информацию в конец предложения.
  • Вы хотите сконцентрировать внимание на определенной точке зрения или определенном персонаже.
4 комментария
яндекс,стиль
Опубликована программа третьего Гипербатона
polinalinen
25 марта 2015, 12:44

Добрый день!

Мы готовы представить программу третьего Гипербатона, который состоится 18 апреля и пройдет в одновременно в Москве, Санкт-Петербурге и Екатеринбурге. На этот раз мы сделали 3 тематических блока: обучение и развитие, стилистика и инструменты документирования. Теперь подробнее.


В первой части Гипербатона Светлана Каюшина, руководитель службы разработки технической документации Яндекса, поделится секретами непрерывного обучения и насущными проблема организации, с которыми сталкивается команда. Далее Алексей Замулла расскажет о своем опыте наставничества: чем полезно обучение других и как с его помощью проанализировать свои стереотипы и привычки. А завершит первую часть доклад Дарьи Ереминой о том, с какими сложностями сталкивается новичок, приходя в Большой проект, и как их можно преодолеть.

Второй блок докладов откроет Максим Ильяхов, редактор дизайн-бюро Артёма Горбунова и создатель сервиса «Главред» — инструмента для редактуры и очистки текста. Из доклада Максима вы узнаете, что такое «Информационный стиль», как он помогает писать и как использовать стоп-слова для «грубой очистки» текстов. А продолжит тему стилистики Татьяна Грачёва, редактор пользовательской документации Яндекса. Доклад будет транслироваться из Санкт-Петербурга. Татьяна, на основе опыта технических писателей Яндекса, расскажет о том, как разработать руководство по стилю и как правильно взяться за его написание.

В следующей части конференции мы предлагаем вам вместе с докладчиками исследовать инструменты документирования. Дмитрий Переплин, переводчик и технический писатель, расскажет как внедрить DITA 1.2 в повседневную деятельность организации, занимающейся производством промышленной продукции, разработкой ПО и системной интеграцией. Далее тему инструментов продолжит Татьяна Родионова — руководитель отдела локализации и разработки технической документации «Лаборатории Касперского». Из доклада Татьяны вы узнаете, как средствами единого источника Author-it свести к минимуму монотонное документирование, максимизировать эффект коллективного написания.

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

Познакомиться с тезисами и расписанием программы можно по ссылке.

Напоминаем, что регистрация на третий Гипербатон продлится до 18:00 (по московскому времени) 15 апреля.

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

Да пребудет с вами сила!

Команда технических писателей Яндекса

8 комментариев
События,гипербатон,2015,конференция
Инструменты для подготовки пользовательской документации
Екатерина
27 марта 2015, 12:51
В Яндексе пишут разную документацию, используя множество инструментов. Я заострю внимание на Помощи (документах для пользователей), т.к. занимаюсь непосредственно ей.
Начнем с того, какие этапы проходит документация в Яндексе, а затем рассмотрим инструменты, используемые на каждом из них. 
  1. Разработка. 
  1. Готовим план и структуру документа, пишем текст. В нужных местах добавляем иллюстрации, ведь часто одна картинка понятнее тысячи слов.
  2.   2. Локализация.
  3. Документ с картинками готов на русском языке — переводим его, чтобы он был доступен и для пользователей в других странах
  4.   3. Публикация.
  5. Документ переведен на все нужные языки — показываем его пользователям.

  6. Пишем текст
  7. Техписатели в Яндексе используют логическую разметку документа и формат DITA XML — чем это удобно?
  • это обеспечивает единый источник данных, из которого мы можем получить документы в разных форматах — HTML, PDF, EPUB;
  • это позволяет редактировать содержимое и внешний вид по отдельности: например, при изменении дизайна не придется менять контент.
Для работы с DITA XML мы используем редактор Syntext Serna, допиленный нашими разработчиками. 
 
 
Готовим картинки
Иллюстрации можно разделить на 3 вида:
  • схемы (MS Visio для Windows; DIA для Windows, Mac OS и Linux);
  • cкриншоты (Jing, Snagit для Windows и Mac OS; GIMP, DIA для Linux);
  • интерактивные скриншоты, в Яндексе мы называем их «живыми картинками» (Handy Image Mapper) — пример использования вПомощи браузера Yandex.
  • Иногда снять хороший скриншот сразу нельзя — например, если данные секретны; если в тестовом интерфейсе опечатки, а скриншоты нужны уже сейчас. Как поменять любой текст на веб-странице, вы можете прочитать в посте Алексея «Нельзя просто так взять и снять скриншот браузера».

Локализация
Локализация подразумевает перевод документа на нужные языки для определенных доменов. Как это всё происходит?
  1. Размечаем исходный документ — об этом упоминала Елена в посте «Особенности создания веб-документации для пользователей».
  2. Конвертируем DITA XML в формат XLIFF — для того, чтобы получить из разметки исходника файл для перевода. Раньше это вручную выполнял переводчик, сейчас у нас для этого есть свой конвертер.
  3. Переводим сегменты файла XLIFF в САТ-системе SwordFish.
  4. Конвертируем XLIFF обратно в DITA XML.

Публикация
Чтобы посмотреть документацию в верстке, «собираем» ее из исходников с помощью скрипта. Это делается для того, чтобы проверять промежуточные версии при разработке и чтобы показывать готовый документ пользователю.
Собранный в верстке контент помещается в дебиановские пакеты, которые устанавливаются на продакшн-серверы.
Сборка контента и пакетов выполняется на *nix-серверах. Для доступа к ним техписатели на Windows используют Putty или WinSCP, а маководы и линуксоиды справляются с командной строкой.

Подведем итоги:
  • пишем документы в редакторе Serna (формат DITA XML);
  • схемы пилим в Visio и DIA;
  • скриншоты снимаем с помощью наборов Jing + SnagIt или GIMP + DIA;
  • получаем координаты для интерактивных скриншотов — Handy Image Mapper;
  • переводим тексты в CAT-системе SwordFish;
  • собираем документацию на *nix-серверах через Putty, WinSCP или командную строку.

Всю разрабатываемую документацию нужно где-то хранить и учитывать процессы работы с ней. О том, как организовано хранение и учет документов, я расскажу вам в следующем посте.
15 комментариев
2014,яндекс,гипербатон,конференция,Инструменты
Как писать так, чтобы переводить было просто
Кристина
31 марта 2015, 16:03


Ремесло технического писателя тесно связано с ремеслом переводчика. Часто документацию необходимо переводить на другие языки, и качество перевода во многом зависит от качества исходного текста.


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

  • стандартизировать технические тексты, чтобы упростить перевод;
  • адаптировать тексты для читателей, которые не являются носителями языка.
Примеры контролируемых языков:
  • Caterpillar Technical English
  • Kodak International Service Language
  • Sun Controlled English
  • IBM Easy English
  • Xerox Multilingual Customized English
  • General Motors Global English
  • GIFAS Rationalised French (Airbus)
  • AECMA Simplified English (Boeing)

В контролируемых языках «устраняются» сложности естественного языка. Рассмотрим примеры таких сложностей в английском языке:

    • Омонимия частей речи (например, существительное work и глагол to work, существительное result и глагол to result). В упрощенном языке разрешается использовать только один из таких омонимов — можно использовать существительное result, а глагол to result не используется.
    • Многозначность слов. В упрощенном языке многозначные слова разрешено использовать только в одном значении, для других значений нужно использовать синонимы. Например, глагол change можно использовать только в значении «изменяться», «что-то изменяется», но нельзя использовать в значении «менять что-либо». Для этого значения используется синоним replace.

В наших текстах, составленных на русском языке, мы выделили следующие сложности:

Синонимы

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

Глаголы с «пустым значением»

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

Плохо: производить проверку, обеспечивать передачу, осуществлять контроль.

Лучше: проверять, передавать, контролировать.

Цепочки существительных в родительном падеже

Чем длиннее цепочка существительных, тем сложнее ее понять и перевести. Если в цепочке встречается омонимия падежных форм, перевести цепочку становится еще сложнее.

Плохо: Ограничение показа рекламы нецелевой аудитории.

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

Лучше:

Ограничение показа рекламы для нецелевой аудитории.

Чтобы реклама не показывалась нецелевой аудитории, [сделайте следующее]…

Отглагольные существительные

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

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

Лучше:

Стоп-слова используются, чтобы ограничить показ рекламы.

Используйте стоп-слова, чтобы ограничить показ рекламы.

Причастные обороты

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

Плохо:

Нажмите на значок, расположенный рядом с изображением товара.

Категории, имеющие карточки товара.

Лучше:

Нажмите на значок рядом с изображением товара.

Категории с карточками товара.

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

Страдательный залог

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

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

(Пользователь должен использовать/задать стоп-слова вручную или они используются /задаются автоматически?)

Если нельзя понять, в каком залоге используется глагол, то при переводе может возникнуть смысловая ошибка. Например, у нас в документации была фраза «товары доставляются при следующих условиях». В ней подразумевалось, что товары доставляет магазин, но в тексте не было слова «магазин». Смысл всего предложения получился двояким. Переводчик подумал, что речь идет об ограничениях в целом, и перевел эту фразу как «goods shall be delivered under the terms», хотя на самом деле имелось в виду «goods are delivered by the store under the terms». Если бы мы написали просто: «магазин доставляет товары при таких-то условиях» — эта ошибка не возникла бы.

Обратный порядок слов

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

Плохо: Кнопкой <tag>Плюс</tag> на клавиатуре измените масштаб объекта <tag>Объект1</tag>.

Лучше: Измените масштаб объекта <tag>Объект1</tag> кнопкой <tag>Плюс</tag> на клавиатуре.

Длинные предложения

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

 

Если учитывать перечисленные особенности при работе над документацией, тексты будут получаться однозначными по смыслу и простыми по структуре. А значит, будет лучше и качество перевода. Мы не просто облегчим работу для переводчиков — мы сделаем свои тексты доступнее и для читателей, причем как читателей исходного текста, так и текста переводного.

Если вы хотите улучшить качество ваших исходных и переводных текстов, рекомендуем вам:

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

В качестве заключения процитирую слова нашего переводчика: «I think a lot of difficulties stem from the technical writer just not thinking primarily about the translator when they're writing… which is understandable... but it does create some problems for us».

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

 Посмотреть видео доклада и презентацию

9 комментариев
яндекс,гипербатон,гипербатон 2014 в Екатеринбурге,конференция,тезисы доклада