Интерфейс приложения: строки и длина

Интерфейс приложения: строки и длина

Строки интерфейса кажутся простым материалом: короткие фразы, понятные действия. На деле это самый ограниченный жанр перевода, где длина, контекст и переменные значат больше, чем стиль.

Ошибка в кнопке заметна всем пользователям сразу.

Ограничения места

Кнопка, вкладка и пункт меню имеют фиксированную ширину. Перевод, который длиннее оригинала, обрезается или ломает вёрстку.

Проверяйте длину на реальных экранах, а не только в файле строк.

Контекст строки

Одно и то же слово может означать действие и существительное. Без контекста переводчик выбирает наугад.

Передавайте разработчикам комментарии к строкам: где она появляется и что делает.

Согласованность

Один и тот же объект должен называться одинаково во всех экранах. Пользователь ищет «корзину», а не «тележку» в одном месте и «пакет» в другом.

Глоссарий интерфейса важнее литературного вкуса.

Действия и объекты

Глаголы действий формулируются одинаково: «Сохранить», «Удалить», «Отменить». Смешение инфинитива и существительного сбивает.

Кнопка должна называть результат, а не процесс.

Сообщения об ошибках

Сообщение объясняет, что произошло и что делать. Фраза «Ошибка» без пояснения бесполезна.

Тон нейтральный: пользователь уже расстроен, ему не нужны нравоучения.

Подсказки и справка

Подсказки коротки и конкретны. Справка может быть длиннее, но должна использовать те же термины, что интерфейс.

Расхождение между подсказкой и кнопкой воспринимается как ошибка.

Переменные и разметка

Плейсхолдеры, теги и переменные нельзя переводить или менять местами без понимания. Ошибка в переменной ломает отображение данных.

Проверяйте, что порядок переменных допустим в языке перевода.

Числа, даты и валюты

Форматы зависят от локали и должны соответствовать настройкам пользователя. Перевод строки не решает задачу, если формат остался прежним.

Проверьте склонение числительных в строках с подстановкой.

Псевдолокализация

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

Особенно полезно для языков с длинными словами.

Тестирование

Проверяйте интерфейс после сборки: пройдите основные сценарии на каждом языке. Ошибки видны только в работе.

Скриншоты с переводом помогают обсуждать правки с командой.

Работа с разработчиками

Строки должны попадать в файл ресурсов, а не в код. Тогда перевод не требует пересборки.

Договоритесь о формате передачи и о том, кто обновляет файлы.

Версии и обновления

При изменении интерфейса часть строк устаревает. Ведите список неиспользуемых строк, чтобы не переводить лишнее.

Новые строки переводятся до релиза, а не после.

Типичные ошибки

Первая — переводить без контекста. Вторая — превышать длину. Третья — переводить переменные.

Четвёртая — оставлять разные названия одного объекта.

Тон и обращение

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

Смешение стилей внутри одного экрана выглядит как ошибка сборки. Пользователь замечает это раньше, чем сами слова.

Избегайте шуток и оценок: они плохо переводятся и быстро устаревают. Нейтральный текст стабильнее и безопаснее при локализации.

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

Терминология экранов

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

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

При изменении названия раздела обновите все экраны и справку. Частичное обновление хуже, чем отсутствие изменений.

Проверяйте термины поиском по файлу ресурсов, а не по памяти.

Доступность строк

Текст кнопок и ссылок должен быть понятен вне контекста, потому что скринридер читает элементы по отдельности. «Подробнее» без уточнения бесполезно.

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

Не полагайтесь на цвет и иконки как единственный носитель смысла: текст должен работать сам по себе.

Проверьте, что перевод не делает подписи двусмысленными при чтении вслух.

Совместная работа

Переводчик, дизайнер и разработчик должны видеть строки в контексте. Скриншот экрана помогает больше, чем список фраз.

Обсуждение спорной строки занимает минуту, если есть макет, и полчаса, если есть только текст.

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

Регулярная синхронизация команды снижает число правок на этапе тестирования.

Итог

Перевод интерфейса — работа с ограничениями: длина, контекст, единообразие и переменные. Свободный литературный перевод здесь почти всегда ошибка.

Проверяйте строки в работающем приложении и обновляйте глоссарий после каждого релиза.

Пример из практики

Команда перевела кнопку как «Продолжить покупки», и она перестала помещаться на экране телефона. Сокращение до «Продолжить» решило проблему, но потеряло смысл подсказки.

Вариант «К покупкам» оказался короче и понятнее в контексте корзины. Такие решения находятся при просмотре экрана, а не в файле строк.

Итог для команды

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

Проверяйте интерфейс на маленьком экране: большинство проблем видно именно там.

Чек-лист

• Контекст строк известен.
• Длина проверена.
• Термины согласованы.
• Переменные сохранены.
• Форматы локализованы.
• Интерфейс протестирован.
• Строки в файле ресурсов.

Частые вопросы

Можно ли сокращать слова?

Только если это не меняет смысл.

Кто пишет строки?

Разработчик или дизайнер, но переводчик может предложить вариант.

Как проверять длину?

На реальных экранах и в псевдолокализации.