Как улучшить английский в документации. Часть 3: мировая аудитория

Привет, Хабр!

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

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

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

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

Зачем это нужно?

Мировая статистика говорит, что английским владеет примерно 1,4 миллиарда человек, но носителей среди них всего 380 миллионов. То есть статистически семь из десяти читателей англоязычной документации — не носители языка.

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

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

Восстание машин

Конечно, первое что сделает современный пользователь со слабым английским — засунет доку в условный Google Translate. Это решит проблему, но лишь отчасти. Качество машинного перевода всё ещё сильно зависит от исходного текста.

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

❓ Do not dip your bread or roll into your soup.
❌ Не макайте хлеб и не катайте его в суп.

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

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

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

✅ Do not dip your bread or your roll into your soup.
✅ Не макайте хлеб или булочку в суп.

Что же делать?

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

Обойтись без слов

Самый радикальный способ — не писать документацию, а рисовать её. Обойтись вообще без слов. Так тоже можно, если специфика продукта позволяет, производители мебели и Lego не дадут соврать. Например, недавно наткнулся в сети на историю про то, как одна девушка сделала для своей бабушки вот такую книжку с инструкциями к смартфону:

Писать упрощённым английским

Менее радикальный способ — упрощённый технический английский (Simplified Technical English — STE). Не дайте этому названию себя обмануть — английский-то упрощённый, но придерживаться его при написании доки совсем не просто.

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

• Ввели строгие грамматические и стилистические правила, которые, например, банят многие формы глагола, включая инговую.

• Составили словарь утверждённых слов. Для каждого слова в словаре прописана его часть речи и утвержденный смысл. Например, слово test является утвержденным существительным, и по правилам STE его нельзя использовать как глагол: