Где-то год назад я на своей странице в FB опубликовал небольшую инструкцию, как можно сделать процесс перевода более эффективным при использовании современных инструментов. За прошедшее время многие спрашивали про эти инструменты, поэтому я решил выпустить “полноценную” статью со статическим адресом, а также более подробно описать сами инструменты.
Но начнём по порядку…
Зачем вообще заниматься переводами?
Я не всегда (может, как и многие) бегло понимаю все детали в статьях, изложенных на английском языке. Требуется несколько раз перечитать, вникнуть… А её перевод позволяет это сделать, докопаться до сути, добавить в лексикон новые слова и обороты, помочь людям, которые воспринимают лучше русский текст, понять идеи заложенные авторами.
Наверно не скажу чего-то нового, но перевод который выполнен не погруженными в конкретную область экспертами может содержать неверно трактуемые термины, перевод которых (или его отсутствие) уже устоялись в сообществе. Поэтому, на мой взгляд, качественно выглядят те переводы, которое сделаны отраслевыми экспертами или при их непосредственном участии.
В какой программе выполняю перевод?
Использую бесплатную IDE от Jetbrains - Intellij IDEA Community Edition по трём причинам: поддержка split view (2 файла на одном экране) с синхронизацией строк, встроенная проверка орфографии и грамматики, из коробки интеграции с git (об этом ниже). А в качестве бонуса удобный набор быстрых “горячих клавиш” для работы с текстом и возможность настроить минималистичный вид.
В каком формате сохраняю переведённые статьи?
В мире разработки стандартом де-факто для документации стал формат Markdown. Он позволяет создавать текст с форматированием, списками, таблицами, иллюстрациями и гиперссылками. А работа с ним не требует какого-то специального ПО, такого MS Word, Notes или других, так как он является обычным текстом.
Подробнее о синтаксисе Markdown можно узнать по ссылке.
Как несколько человек могут работать над одной статьей?
Даже если вы переводите статью без чьей либо помощи, то черновик скорее всего захотите показать кому-либо, принцип несколько глаз никто не отменял, ошибки делает каждый;) Надеюсь, многие читатели понимают, что пересылать текстовые файлы по почте или в мессенджерах, придумывая каждый раз для новой версии новое название, не самая современная идея.
Многие сразу, скажут, что для таких целей хорошо подходит Google Docs или MS Office 360, и будут правы. Что может быть удобнее, чем в онлайн-формате вносить правки и оставлять комментарии? Но в среде разработки был придуман более совершенный инструмент - системы контроля версий, такие как git, и сервисы на нём основанные - GitHub, GitLab или Bitbucket.
Почему использую GitHub?
Почему именно GitHub - так исторически сложилось:) Но дальнейшее описание применимо ко всем вышеописанным сервисам, так как они построены по схожим принципам. Можно создавать несколько версий одной или нескольких статей, обмениваться правками, сливать работу нескольких авторов, и все это делать в несколько кликов мыши. Связанные статьи могут объединяться в проекты с общими настройками доступов и правилами. Еще большим плюсам таких порталов является возможность запуска “сборки” - например, проверки стилей, отступов, орфографии, генерации оглавления, … А готовые статьи можно опубликовать бесплатно на домене ваше-ник.github.io, знания HTML при этом не понадобятся .В Google Docs или MS Office 360 это несколько сложнее.
Какие элементы автоматизации применяю?
В среде разработки ПО применяется термин pipeline - конвейер, который позволяет выполнить автоматически все подготовительные этапы, проверки и развертывание новой версии приложений или сервисом. Например, если вы разрабатываете мобильное приложение, то создание такого “пайплайна” позволит без особого труда тестировать, собирать и публиковать новые версии вашего приложения, что значительно (порой в разы) сокращает риски появления ошибок. В GitHub за настройку таких pipelines отвечает GitHub Actions.
Я активно пользуюсь markdonlint (проверка корректности построения Markdown-файлов) и yandex-speller (проверка орфографии), запуск которых для всех статей каждого из проекта добавил в GitHub Actions. При каждом изменении текста и отправки его на сервер происходит запуск этих проверок, а также генерация новой страницы содержания, если в “прод” вышла новая статья. Например, если вы или ваш коллега допустили ошибку в тексте, то “билд” не пройдет, и система даст вам обратную связь об этом.
Переводя небольшие части текста я постоянно “интегрируюсь” с удаленным сервером, который десятки раз в день запускает скрипты для валидации контента. Это позволяет сделать прогресс перевода прозрачным, т.е. та версия, которая прошла сборку с большой вероятностью не имеет орфографических ошибок или проблем с форматированием и более не требует пристального внимания.
Конечно, после окончания перевода я перечитываю текст несколько раз, чтобы отловить ошибки, часто стилистические или связанные с падежами.
Я постарался описать на верхнем уровне, как происходит процесс перевода в моём случае. Напишите в комментариях, требуется ли детально описать каждый (или какой-то отдельный) из шагов?
Пример настроенного проекта с автоматизацией можно найти по ссылке. Спасибо!