Каждая версия Windows не перестает толстеть, и отчасти в этом виноваты переводы: Microsoft никогда их не стирает

Когда пользователь Windows видит в интерфейсе операционной системы какой-то запутанный, устаревший или ошибочный текст, обычная реакция — подумать, что это недосмотр или отсутствие исправления; возможно, он даже думает, что он первым заметил проблему, потому что, если бы не «кто-то исправил бы это уже». Однако реальность Windows немного сложнее.

Согласно объяснениям опытного инженера Microsoft Раймонда Чена, ответ кроется не в отсутствии отточенности, а в том, как Windows управляет своими переводами, а именно в своих внутренних правилах замораживания текстовых строк и в необходимости обеспечения совместимости между версиями и языковыми пакетами.

Эти факторы приводят к малоизвестному, но фундаментальному явлению: чрезвычайной сложности изменения текста интерфейса Windows после его перевода и распространения.

Перевод как тормоз: крайний срок, который наступает раньше, чем код

Давайте представим процесс разработки Windows как производственную линию, на которой дизайнеры, программисты, переводчики и тестировщики работают одновременно. Можно было бы ожидать, что тексты будут одним из элементов, которые подходят в конце, когда функциональность ясна. Но… происходит прямо противоположное.

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

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

Постоянная блокировка

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

Изменение ее может вызвать волновой эффект в языковых пакетах:

• Переводы перестанут соответствовать исходному тексту.
• Языковые пакеты могут «жаловаться» и перестать работать.
• Система может понизить статус сообщения до базового языка или, в некоторых случаях, даже до английского.

По этой причине единственный способ обернуть текст в обновлении — это создать новую строку и отказаться от старой, которая продолжает существовать во внутренних файлах, даже если она больше не используется.

Кладбище строк: как Windows накапливает заброшенные тексты

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

Есть ли время, когда этот хаос можно было бы навести порядок? Если обновления не могут удалить старые строки, не нарушая перевод, когда можно провести глубокую очистку? Ответ: только во время «большого выпуска» операционной системы (то есть перехода с Windows 10 на Windows 11 или аналогичного). Конечно, это не значит, что это делается всегда.

Когда язык определяет взаимодействие с пользователем

Все эти факторы имеют любопытные последствия:

• Строки, которые десятилетиями остаются не обновленными: Неправильно подобранный термин или двусмысленный текст могут быть «заморожены» с Windows XP и сохранятся практически нетронутыми до Windows 11.
• Переводы, которые не отражают модернизированные функции: Если функция изменяется, но исходная строка не может быть затронута, перевод может быть устаревшим по сравнению с фактической работой.
• Сообщения, которые кажутся написанными разными людьми: Поскольку некоторые строки создаются новыми, а другие остаются заблокированными, система накапливает разнородные стили, при этом разные эпохи языкового дизайна сосуществуют в одном интерфейсе.
• Более сложный дизайн для разработчиков: необходимость генерировать новую строку вместо изменения существующей усложняет архитектуру программного обеспечения и требует дополнительной дисциплины.

Редактор: AndreyEx