Как вычитывать технические термины, регистр букв и переведенные метки интерфейса
При проверке технической документации сверяйте каждый термин с четкой таблицей терминологии, а не полагайтесь на память или единое правило капитализации. Фиксируйте утвержденную форму, написание и регистр, которые должны видеть читатели, допустимые варианты, точные идентификаторы кода или API, а также любые переводы, по которым решение еще не принято. Затем вычитывайте основной текст, метки интерфейса и идентификаторы как отдельные сущности. Этот метод помогает устранить несогласованность терминологии, сохраняя в неизменном виде названия и фрагменты кода, требующие абсолютной точности.
Почему одно правило капитализации не может решить вопрос со всеми терминами?
Руководства по стилю задают полезные базовые правила, однако у конкретного продукта или предметной области могут быть устоявшиеся названия, требующие иного подхода. Руководство для разработчиков Google рекомендует стандартную капитализацию американского английского и строчные буквы с заглавной первой (sentence case) для заголовков, списков и таблиц, сохраняя при этом официальные названия продуктов и форматы кода. Руководство Microsoft также отдает предпочтение стилю предложений (sentence-style), но явным образом резервирует заглавные буквы для имен собственных, таких как бренды, продукты и службы компании. Их общий базовый подход — это отправная точка, а не доказательство того, что данный технический термин является нарицательным словом. [Руководство Google по капитализации](https://developers.google.com/style/capitalization) [Руководство Microsoft по капитализации](https://learn.microsoft.com/en-us/style-guide/capitalization)
Словарь терминов может ответить на вопрос, отличный от общей статьи о регистре: какое написание или употребление конкретных терминов предпочитает данное редакционное руководство. Например, словарь Google отсылает читателей к предпочитаемому общему словарю для статей, не вошедших в список, и разделяет стилистические рекомендации и проверку технического определения в авторитетной документации. Такое разделение полезно: редакционная последовательность и техническая правильность требуют подтверждения из источников, соответствующих каждой из этих задач. [Словарь терминов Google](https://developers.google.com/style/word-list)
Что должно входить в таблицу терминов для вычитки?
Создайте отдельную строку для каждого термина, который может быть изменен несогласованно или неверно переведен. Этот гипотетический пример демонстрирует поля и логику принятия решений; «Sync token» и его перевод приведены исключительно для наглядности, а не как утверждения о реальном продукте или утвержденной терминологии.
Задача таблицы — фиксировать принятые решения и границы их применимости. Разрешенное написание со строчной буквы не должно незаметно превратиться во второе официальное название продукта; идентификатор не должен «исправляться» под обычный текст; а нерешенный вопрос по переводу должен оставаться на виду как требующий решения. Если официальный источник вступает в противоречие с локальным глоссарием, зафиксируйте это расхождение и источник окончательного решения, вместо того чтобы объединять варианты в невнятный список.
Как определять отображаемое написание и регистр букв?
Сначала определите, к чему относится термин: к общему понятию, бренду или названию продукта, метке интерфейса или точному программному идентификатору. Проверьте официальную форму по документации продукта или глоссарию. Затем примените правила стиля целевого издания к обычному тексту, заголовкам и меткам, сохраняя задокументированные исключения для имен и идентификаторов. Google не рекомендует использовать капитализацию без необходимости и предостерегает от использования одного лишь регистра для различения значений; Microsoft аналогично рекомендует использовать строчные буквы везде, кроме начала предложений и имен собственных, в рамках своего подхода sentence-style. [Руководство Google по капитализации](https://developers.google.com/style/capitalization) [Руководство Microsoft по капитализации](https://learn.microsoft.com/en-us/style-guide/capitalization)
Затем при необходимости сверьте форму со списком слов и словарем целевой организации. Зафиксируйте источник, его версию или дату проверки, чтобы другой редактор мог проследить логику выбора. Не делайте вывод об официальном статусе термина лишь на основании привлекательного вида слова с заглавной буквы, результатов поиска или перевода, похожего на английский оригинал. Если источники расходятся во мнениях или не указывают конкретную форму, пометьте строку для принятия решения, а не выдавайте догадку за устоявшуюся терминологию.
Как проверять переводы и метки интерфейса?
Относитесь к переводу как к решению, основанному на смысле и контексте, а не как к механическому изменению регистра букв. На метку могут накладываться ограничения интерфейса, устоявшаяся терминология локализованного продукта или иная грамматическая форма в целевом языке. Сравните предложенный вариант с утвержденными локализованными материалами и контекстом, в котором его увидит читатель. Если авторитетная локализованная форма отсутствует, пометьте перевод как нерешенный вопрос и запросите решение по терминологии; не выдумывайте «официальный» эквивалент самостоятельно.
После утверждения термина вычитайте саму метку прямо по месту ее размещения. Проверьте, соответствует ли регистр правилам целевого языка, а также применимому руководству по стилю продукта или компании. Сохраняйте исходную метку в записи термина вместе с ее источником и статусом, чтобы при будущих правках временный перевод не приняли за утвержденный. Если на эту метку есть ссылки в инструкциях, убедитесь, что в тексте используется в точности та же формулировка, что и на экране.
Как защитить код и идентификаторы API?
Отделяйте неизменяемые литеральные строки от редакционного текста, прежде чем менять регистр букв. Сверяйте идентификаторы символ за символом с соответствующей документацией API, схемами, кодом или интерфейсом. Сохраняйте символы подчеркивания, регистр букв, пробелы и знаки препинания там, где они заданы источником: нормализация стиля уместна в окружающем пояснении, а не в самом значении литерала. Руководство Google прямо разрешает написание заглавными буквами или в camel-case в официальных названиях или при ссылке на код, в котором они используются. [Руководство Google по капитализации](https://developers.google.com/style/capitalization)
Практическая вычитка строится так: защищенные идентификаторы помечаются в таблице терминов, а затем каждое их вхождение сверяется с этим списком. Если в повествовательном предложении термин из кода используется как обычное существительное, решите, стоит ли объяснить его понятным для читателя языком, сохранив сам точный идентификатор в формате кода. Если само официальное определение неясно, зафиксируйте эту неопределенность: руководство по стилю не может определять поведение API или каноническое имя поля.
Какова надежная последовательность вычитки?
Эта последовательность действий служит вспомогательным инструментом для вычитки, а не средством автоматического перевода или универсальным правилом выбора регистра. Ее ценность в том, что каждое редакционное решение становится прозрачным: какая форма была выбрана, откуда она взята, где применяется и какие моменты еще требуют решения. Для небольшого документа может хватить компактной таблицы; для обширного набора терминологии сохраняйте те же поля в рамках установленного в команде процесса работы с глоссариями.