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

Да, люблю их нежно

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

Например. Моё мнение что branch нельзя переводить как ветка, а писать именно - бранч.

Или понятие - замерджить.

Большие корпорации вообще разрабатывают свой глоссарий и всё пишут с оглядкой на них. "Безобразно, зато однообразно" :)

На то они и большие)

Пример похожей конструкции (см. «должен ли телефон отправлять HTTP-запрос ») в документации Cisco:
https://www.cisco.com/c/ru_ru/td/docs/voice_ip_comm/cuipph/MPP/8800/english/AG/p881_b_8800-mpp-ag_new/p881_b_8800-mpp-ag_new_chapter_0111.html?dtid=osscdc000283

Пища для досуга
Вопрос был про употребление применительно к «авторизации», но на странице Mozilla из Вашего скрина ссылки на соответствующие RFC про аутентификацию.
Пример употребления «аутентификации» на популярном ресурсе
( см. «Пример HTTP аутентификации с использованием Basic схемы»,
+ конструкция см. «HTTP-запроса»):
https://habr.com/ru/company/dataart/blog/262817/

Пример того, как употребляется «аутентификация» в документации Cisco
(См. «...Веб-аутентификация по HTTP»):
https://www.cisco.com/c/ru_ru/support/docs/wireless-mobility/wlan-security/115951-web-auth-wlc-guide-00.html?dtid=osscdc000283

Дополнительно, вероятно, авторский и/или машинный перевод RFC:
https://efim360.ru/rfc-7617-bazovaya-shema-autentifikatsii-http/#2-The-Basic-Authentication-Scheme

Удачного ✌️

Спасибо за мнение!
Интересные акценты про целевую аудиторию и технические требования.

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

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

То есть есть какое-то изменение, к примеру:
- цены продукта в какой-то из статьи (если это важный момент для настройки)
- изменение название кнопки
- перемещение кнопки/вкладки в другую секцию
- добавление/удаление вообще кнопки и функции
- добавление ограничений/ убрали ограничение

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

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

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

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

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

Следить самому за трекером... это утопия, ведь много комментариев связанных просто с разработкой/тестированием.. то есть это или просто размышление или пишут не, не работки или что они добавили но просто называют это словами какой-то папки/функции понятной вероятно только из контекста просмотра всего кода (не всегда понятно из темы задачи вообще где это)
И таких задач от 12 направлений одновременно просто масса

Ищите союзников и поднимайте важность хорошей документации у руководства. Аргументируйте недовольством клиентов и временем, которое тратит СП.

Уведомления об изменениях должны быть включены в процесс выпуска продукта. Это так естественно

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

Пока ещё там никто не писал о плохой документации) поэтому может и не верят когда об этом говорят «изнутри»

А кто может быть союзником? Кажется все стараются уйти от этого будто его лично и его круга вопросов не касается 😅

а если кто и напишет (гипотетически) - то виноват будет райтер, а не тот кто не сообщил

ну так обычно по другим фидбека работает.

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

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

Службе поддержки разве нравится такие вопросы решать?)

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

Изменения лучше отслеживать самим писателям

Если вышестоящее начальство по какими-то причинам не понимает, не осознаёт или не хочет осознавать (если до его сведения доводят всю необходимую информацию, разумеется), что подобные вопросы приводят к финансовым потерям, то вряд ли Вам удастся кардинально на что-то повлиять и переломить ситуацию.
Ключевая мысль здесь, как и везде — деньги. Плохо настроены процессы — убытки, трата времени сотрудников — снова убытки, не налажена коммуникация — убытки.
По-моему, взрослые люди должны понимать такие вещи.