В IT можно довольно долго жить с английским на уровне server, user, password, error и ещё пары сотен знакомых слов. Интерфейс понятен, команды запомнились, типовые ошибки узнаются с первого взгляда. А потом нужно прочитать длинный issue на GitHub, разобраться в security advisory или понять документацию к незнакомому инструменту. Тут выясняется, что одних терминов мало. Разбор того, какой английский действительно нужен разработчикам и другим IT-специалистам, есть на SEO Title: Английский для программистов: лексика и работа. Ниже речь о более узкой задаче: как читать технический английский быстрее и не таскать каждую фразу в переводчик.
Технический текст вообще устроен немного странно. С одной стороны, он обычно проще художественного: автор не пытается удивить метафорами и редко играет со словами. С другой, в документации полно длинных конструкций, пассивного залога и слов, которые в обычной жизни встречаются нечасто. Поэтому человек может спокойно смотреть YouTube на английском, но спотыкаться о два предложения из мануала.
Хорошая новость в том, что набор этих конструкций довольно ограничен. Если вы регулярно читаете документацию, GitHub и сообщения об ошибках, одни и те же обороты начинают повторяться. В какой-то момент failed to, make sure that, is required to или may result in уже не переводятся в голове. Они просто считываются.
Не переводите документацию по одному слову
Самый медленный способ чтения выглядит знакомо: прочитать слово, перевести, перейти к следующему, потом попытаться собрать русский вариант предложения. На короткой подсказке это ещё терпимо. На странице документации превращается в пытку.Возьмём обычную фразу:
If the connection cannot be established, verify that the firewall allows incoming traffic on port 443.
Если разбирать её слово за словом, легко потерять мысль. Проще сразу видеть куски:
If the connection cannot be established
если соединение не удаётся установить
verify that
проверьте, что
the firewall allows incoming traffic
межсетевой экран разрешает входящий трафик
on port 443
на порту 443
Тут важен не красивый перевод. Нужен смысл: соединение не устанавливается, надо проверить firewall и порт 443. Всё.
Так же работает более длинная фраза:
This issue may occur when the service is running under an account that does not have sufficient permissions to access the specified directory.
Главные куски здесь: issue may occur, service is running under an account, does not have sufficient permissions, access the specified directory. Как только они узнаются, предложение перестаёт выглядеть монстром.
Кстати, именно поэтому полезнее запоминать не отдельное permission = разрешение, а сочетания: insufficient permissions, grant permission, permission denied. В реальной документации они потом встречаются готовыми блоками.
Есть и слова, которые в технических текстах попадаются постоянно:
- require - требовать, быть необходимым;
- enable - включить, активировать;
- disable - отключить;
- allow - разрешать;
- prevent - предотвращать, не допускать;
- occur - происходить, возникать;
- affect - затрагивать;
- available - доступный;
- provide - предоставлять;
- support - поддерживать.
Ошибка часто уже объясняет, что сломалось
Когда на экране появляется красный текст, рука автоматически тянется копировать его в Google. Иногда это правильно. Но сперва стоит прочитать саму ошибку, причём целиком.Authentication failed because the supplied credentials are invalid.
Даже если слово supplied незнакомо, ключи понятны: authentication failed, credentials, invalid. Аутентификация не прошла из-за неверных учётных данных.
Или:
The application cannot start because a required component is missing.
Приложение не запускается, потому что не хватает необходимого компонента. Искать отдельно перевод каждого слова тут просто незачем.
Очень быстро запоминается небольшой набор:
failed to - не удалось;
unable to - невозможно / не удалось;
not found - не найден;
denied - отказано;
timed out - вышло время ожидания;
invalid - неверный, недопустимый;
missing - отсутствует;
required - необходимый;
unexpected - неожиданный.
Есть полезная привычка: перед поиском сформулировать себе в одном предложении, что именно сообщает ошибка. Не как её исправить, а что произошло. "Служба не стартовала из-за прав". "Сертификат истёк". "Файл конфигурации не найден". Уже после этого поиск становится заметно точнее.
И ещё одна мелочь. Не отбрасывайте вторую половину сообщения. Часто пользователь копирует только Error 0x..., хотя ниже прямо написано, какой файл, порт или компонент вызвал сбой.
Отдельная история - логи. Их вообще не стоит читать как обычный текст сверху вниз. В логе важнее сначала найти момент, где всё пошло не так: ERROR, FATAL, exception, failed, иногда warning. Потом посмотреть несколько строк до события и после него.
Допустим, в середине большого лога есть:
Failed to bind to address 0.0.0.0:8080: address already in use.
Даже без идеального английского видно главное: приложение не смогло занять 8080, потому что адрес уже используется. Следующий вопрос уже технический: кто слушает этот порт?
Или:
Certificate verification failed: certificate has expired.
Здесь вообще достаточно двух кусков: verification failed и certificate has expired. Сертификат истёк, проверка провалилась.
В логах особенно вредно пытаться переводить служебные строки подряд. Там рядом могут лежать timestamp, имя потока, путь к файлу, stack trace и текст исключения. Переводчик смешивает всё это в одну кашу. Лучше сначала отделить данные от обычного английского.
Если есть stack trace, начните с первой осмысленной строки ошибки и места, где вызывается ваш код. Длинный хвост внутренних вызовов библиотеки часто можно оставить на потом. Английский здесь нужен не для красивого перевода, а чтобы быстро выцепить причину: connection refused, out of memory, permission denied, invalid argument, dependency not found.
GitHub учит живому техническому английскому
Документация обычно сухая. GitHub интереснее: там виден язык, которым разработчики действительно обсуждают проблемы.
В Issues постоянно встречается что-то вроде:
I can reproduce this issue.
То есть проблему удалось воспроизвести.
This seems to be related to the latest update.
Похоже, причина связана с последним обновлением.
As a workaround, you can disable...
В качестве временного решения можно отключить...
This has been fixed in version 4.2.
Это исправили в версии 4.2.
Could you provide the logs?
Можете приложить логи?
Через десяток обсуждений начинаешь замечать, что язык там довольно повторяемый. И это удобно. Не нужно знать весь английский, чтобы понять, воспроизводится ли баг, подтвердили ли его разработчики и есть ли исправление.
Особенно полезно слово workaround. Это не fix. Fix исправляет причину, а workaround помогает пережить проблему до нормального исправления. Например, отключить одну функцию, изменить параметр или откатиться на предыдущую версию.
Это слово пригодится и в поиске. Запрос Windows 11 VPN issue может выдать всё подряд. А Windows 11 VPN issue workaround уже ищет временное решение.
Вообще технический поиск на английском не требует красивых предложений. Скорее наоборот.
Есть ещё одна привычка, которая экономит время: всегда цепляйтесь за версии и даты. Фраза fixed in 3.8.1 намного важнее общего обсуждения на двадцать комментариев, если у вас стоит 3.8.0. То же самое с introduced in, since version, deprecated in и no longer supported. Иногда весь нужный английский сводится к тому, чтобы правильно прочитать одну строку рядом с номером версии.
После обновления перестал запускаться OpenVPN:
OpenVPN not starting after Windows update
Служба падает при старте:
OpenVPN service fails to start Windows 11
Программа начала вылетать после обновления:
program name crash after update
Нужно отключить конкретную функцию:
how to disable feature name
Есть текст ошибки:
"exact error message" software name
Русскую историю в духе "вчера всё работало, потом Windows что-то обновил и теперь не запускается" переводить целиком не надо. Поисковику полезнее несколько точных слов.
В security-текстах свой небольшой словарь
Для информационной безопасности английский особенно важен: первичное описание уязвимости, advisory производителя и обсуждение исправления часто выходят раньше переводов.Но и здесь лексика довольно быстро повторяется.
vulnerability - уязвимость;
affected - затронутый;
attacker - атакующий, злоумышленник;
remote attacker - удалённый злоумышленник;
arbitrary code - произвольный код;
execute - выполнять;
privileges - привилегии, права;
exploit - эксплуатировать уязвимость;
patch - исправление;
mitigation - мера, которая снижает риск;
impact - последствия, влияние;
disclosure - раскрытие информации.
Фраза вроде
An unauthenticated remote attacker may exploit this vulnerability to execute arbitrary code.
сначала выглядит тяжеловато. Но если знакомы unauthenticated, remote attacker, exploit и execute arbitrary code, смысл читается почти без перевода: удалённый злоумышленник без аутентификации может использовать уязвимость для выполнения произвольного кода.
Здесь особенно важно не проглатывать маленькие слова. May означает возможность, а не гарантированный результат. Can описывает способность или возможность. Must уже задаёт обязательное действие.
Сравните:
The update may cause the service to restart.
Служба может перезапуститься.
The update will cause the service to restart.
Служба перезапустится.
И ещё:
You should restart the system.
Систему рекомендуется перезапустить.
You must restart the system.
Систему необходимо перезапустить.
На бытовом уровне разница кажется небольшой. В инструкции или security advisory она может менять решение администратора.
Переводчик полезен, пока не начинает думать вместо вас
Машинный перевод сейчас достаточно хорош, чтобы быстро разобраться в сложном абзаце. Проблема появляется, когда его используют раньше собственной попытки прочитать текст.У многих технических слов несколько значений. Issue бывает проблемой, вопросом, выпуском или задачей в bug tracker. Thread - потоком выполнения или веткой обсуждения. Port - сетевым портом, разъёмом или переносом программы на другую платформу. Даже driver вне контекста не обязан быть драйвером устройства.
Поэтому рабочая схема простая: сначала прочитать самому, отметить место, где смысл разваливается, и только его проверить переводчиком. Если перевод получился странный, смотреть исходное предложение ещё раз, а не пытаться понять странный русский текст.
Иногда лучше открыть англоязычное определение. Особенно для терминов, у которых русский перевод формально правильный, но мало что объясняет.
Есть ещё грамматика, и её не нужно учить целым учебником ради чтения документации. Достаточно узнавать несколько частых моделей.
Например:
If enabled, this option allows remote users to connect to the server.
Здесь if enabled значит "если опция включена". Автор просто сократил полное if this option is enabled.
Или:
Unless specified otherwise, the service uses the default port.
Unless specified otherwise - "если не указано иное".
Подобные обороты лучше собирать по ходу работы. Пять реально встреченных конструкций обычно полезнее пятидесяти правил, которые пока нигде не понадобились.
Как тренироваться, если отдельного времени на английский нет
Не обязательно заводить ещё один учебный проект. Материал уже открыт на вашем мониторе.Сегодня это README новой библиотеки. Завтра issue, где описан ваш баг. Потом release notes, лог или advisory. Можно брать небольшой фрагмент и сначала читать его без переводчика. Неизвестное слово искать только тогда, когда без него действительно теряется смысл.
Если выражение появляется второй или третий раз, сохранить его целиком. Не access = доступ, а gain access to, deny access, unauthorized access. Не permission, а grant permission, insufficient permissions, permission denied.
Со временем меняется даже не столько словарный запас, сколько скорость. Сначала сообщение из двух строк приходится перечитывать три раза. Потом глаз сразу выхватывает due to, caused by, fixed in, not supported, affected versions. И уже понятно, куда смотреть дальше.
Не стоит добиваться понимания каждого слова. В реальной работе обычно нужны ответы на несколько вопросов: что произошло, почему, какие версии затронуты, что предлагает автор, есть ли ограничения и что делать сейчас. Если незнакомое прилагательное не меняет ни один из этих ответов, его вполне можно пропустить.
И вот здесь технический английский даже удобнее общего. Словарь ограничен вашей областью, конструкции повторяются, а документацию обычно пишут ради точности, а не ради литературного эффекта.
Через какое-то время происходит забавная вещь. Вы открываете GitHub issue, читаете This appears to be a regression introduced in the latest release, понимаете смысл и идёте дальше. И только потом замечаете, что ничего не переводили.
Это и есть полезная цель. Не "знать английский идеально", а перестать считать его отдельной преградой между проблемой и её решением.