Реализация локализации мобильного приложения на узбекский язык

Локализация мобильного приложения на узбекский: где ломается

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

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

Цена такой схемы видна на второй-третьей итерации: правку вносят в одном месте, а заказчик находит старый текст ещё в трёх; поддержка переводов приложения превращается в ручной перенос строк из таблицы в код перед каждым выпуском, и очередной релиз уходит с устаревшими формулировками, потому что перевод пришёл после заморозки ветки. Разбираем, как это закрывается: единый источник строк, обращение по смысловым ключам вместо литералов, отдельный слой для серверных текстов и порядок, при котором перевод перестаёт блокировать выпуск.

Что даёт локализация: измеримый результат для продукта

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

Скорость выпуска и предсказуемость вёрстки

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

Меньше правок и обращений в поддержку

Доля обращений в поддержку по текстам падает, когда термины зафиксированы в глоссарии, а подписи кнопок совпадают с тем, что человек ожидает прочитать. Число правок на выпуск снижается: повторяющиеся формулировки переиспользуются из памяти переводов, а не переводятся заново под каждую сборку. Стоимость поддержки переводов перестаёт расти вместе с числом обновлений — переводится только дельта новых строк, а формы множественного числа, форматы даты и разделителей закрыты отдельным набором тестов.

Способы реализации перевода интерфейса: сравнение вариантов

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

Как выбрать вариант под продукт

На практике схема почти всегда комбинированная: навигация и постоянные подписи живут в ресурсных файлах переводов, изменяемые блоки приходят с сервера, а отдельная сборка нужна там, где расходятся сами сценарии. Для узбекского на старте обычно берут поэтапный перевод — сначала путь до оплаты и ключевые экраны, затем остальное. Обязательное условие — запасной язык-источник: непереведённая строка показывает осмысленный текст, а не пустоту.

Этапы работы: от аудита интерфейса до передачи сборки

Локализация на узбекский — не замена строк в файле ресурсов. Узбекский бывает в латинской и кириллической графике, а переведённые фразы меняют длину: подпись вылезает за кнопку, длинный составной термин ломает сетку экрана. Поэтому этапы локализации приложения начинаются с аудита текстов интерфейса, а не с перевода.

1. Аудит текстов интерфейса. Собираем все строки: подписи, подсказки, сообщения об ошибках, пустые состояния, уведомления — включая те, что остались только в макетах.
2. Схема ключей переводов. Приводим строки к единым ключам и глоссарию: одна сущность называется одинаково на всех экранах, ключ не меняется при правке текста.
3. Перевод и вычитка носителем. Переводит носитель с продуктовой лексикой; термины согласуем заранее, иначе «корзина» на разных экранах станет тремя разными словами.
4. Графика и язык по умолчанию. Определяем латиницу или кириллицу, логику выбора языка по настройкам устройства и откат на русский вместо пустых строк.
5. Интеграция и проверка вёрстки. Подключаем ресурсы к обеим платформам и прогоняем каждый экран на длинных строках: где можно — переносим, где нельзя — сокращаем текст, а не шрифт.
6. Тестирование и передача сборки. Проходим вход, оплату, заказ и уведомления на узбекском, проверяем смену языка на ходу; отдаём сборку, глоссарий, схему ключей и инструкцию по новым строкам.

Приёмка локализации

Приёмка идёт по списку экранов: непереведённых строк нет, термины совпадают с глоссарием, подписи не обрезаны, даты и числа в узбекском формате. Замечания фиксируем списком, правим и показываем повторно — в публикацию сборка уходит только после закрытия всех пунктов.

Что остаётся у заказчика: файлы переводов, схемы, регламенты

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

Файлы, схемы и профили

• Файлы переводов — ресурсы по языкам с единой структурой ключей: узбекский набор лежит рядом с исходным, добавление новой строки не ломает остальные языковые версии.
• Словарь терминов приложения — закреплённые переводы продуктовых понятий, названий кнопок и статусов, чтобы один и тот же термин не звучал по-разному на соседних экранах.
• Схема прохождения строк — карта: где строка задана в коде, какой ресурс её перекрывает, что видит пользователь при неподдерживаемом языке и на какой набор идёт откат.
• Профили языков — язык по умолчанию, порядок выбора и правила подстановки для регионов; подключение нового языка сводится к добавлению набора ресурсов.

Регламенты и документация

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

Кейс: как мы убрали расхождения текстов между платформами

Заказчик — сервис доставки с приложениями на двух платформах и веб-кабинетом. Узбекская версия держалась на ручной работе: строки были вшиты прямо в код экранов, часть переводов велась в таблицах, часть — в Crowdin у подрядчика. Расхождения нашлись на 96 экранах из 240 — около 1 800 строк: на одной платформе кнопка называлась «Buyurtma berish», на другой — «Buyurtma», а в веб-кабинете текст отставал на две недели.

Новая формулировка доезжала до пользователя 18–20 дней: правка в коде, две проверки, сборка и модерация в магазинах приложений. Мы собрали единый каталог переводов с ключами вида checkout.button.submit, контекстом для переводчика и разбивкой по экранам, а сборка стала подтягивать актуальные строки автоматически.

Что именно переносили

Инвентаризацию вели не по файлам, а по экранам — так видно пропуски и дубли:

• подписи кнопок, полей и заголовков экранов;
• тексты ошибок и уведомлений;
• форматы даты, времени и разделителей разрядов;
• названия категорий и статусов заказа;
• шаблоны сообщений и писем.

Через два месяца обращения в поддержку с жалобами на непонятный или несовпадающий текст упали с 250–270 до 60–70 в месяц. Время выпуска обновления с новыми формулировками сократилось с 18–20 дней до 2–3, и ушёл целый класс ошибок: правку больше нельзя внести в одном месте, а в двух других не заметить.

Что делать, если продукт уже выпущен, а перевод нужен сейчас?

Выпущенное приложение с зашитыми в экраны строками — обычная ситуация, и она не требует переписывать логику. Интерфейс, навигация и бизнес-правила остаются как есть: новый язык добавляется поверх, потому что текст для пользователя и код, который им управляет, — разные слои. Мы начинаем с инвентаризации: собираем подписи, кнопки, подсказки, тексты ошибок, письма и push-сообщения, служебные статусы, приходящие с сервера. Всё это выносится в словари «ключ — значение», где ключ описывает роль строки, а не её текущее содержимое.

Главная работа — не перевод, а вынос строк из кода и вёрстки. Пока текст лежит внутри экрана, его нельзя ни перевести, ни поправить без новой сборки. Мы расставляем ссылки на словари по всем местам вывода, включая всплывающие сообщения и динамические шаблоны, и оставляем один резервный язык, на который приложение откатывается, если ключ почему-то не найден. Так пропадает класс ошибок, когда в новом языке внезапно появляется пустая кнопка или английская заглушка посреди экрана.

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

Что с уже опубликованными версиями? Строки, вынесенные в словари, можно обновлять удалённо — пользователь получает новый язык, не дожидаясь сборки в магазине. А вот название приложения, описание, скриншоты и системные подписи обновляются только вместе с версией, поэтому их мы готовим заранее и сопровождаем регрессом по всем локалям: длинные строки, переносы, обрезанные подписи в кнопках. Дальше — как это разложить по этапам без остановки продукта.

Частые сомнения: длина строк, шрифты, форматы дат

Узбекский — агглютинативный язык: слово «привязывается» аффиксами и удлиняется в полтора-два раза против английского. Если строка не ограничена по ширине, кнопки распирает, а подписи в две строки ломают вёрстку. Отдельная тема — шрифты: кириллический набор требует гарнитуры с полным покрытием глифов, иначе текст уезжает в системный фолбэк и выбивается из макета.

Ниже — вопросы, которые чаще всего поднимают до старта работ.

Что делать с текстами, которые приходят с сервера?

Часть контента формируется на стороне сервера, и её нельзя положить в ресурсы приложения. Такие тексты локализуем по заголовку выбранной локали, а шаблоны подстановки и падежи переносим в серверные словари. Фолбэк на базовый язык оставляем, чтобы при пропущенном ключе пользователь видел осмысленную фразу, а не пустой блок.

Как проверить качество, если носителя нет в штате?

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

Нужно поддерживать и латиницу, и кириллицу?

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

Можно ли поправить перевод после релиза?

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

Обсудим задачу: что прислать для оценки объёма перевода

Чтобы вернуться с оценкой объёма перевода и планом работ по локализации, а не с уточняющими вопросами, нам достаточно исходных данных от заказчика. По ним мы считаем реальное число строк, а не «примерно по экранам», и раскладываем работу на этапы.

• Файлы локализации в том виде, в котором они лежат в проекте — строковые ресурсы Android и iOS. По ним видно объём, дубли и строки, которые собираются динамически и требуют отдельного разбора.
• Список экранов или доступ к тестовой сборке: помогает отделить видимый текст от служебных значений — идентификаторов, ключей, технических подписей, которые переводить не нужно.
• Глоссарий продукта и термины предметной области: названия разделов, тарифов, статусов заявки. Без него один термин получает три разных перевода на разных экранах.
• Решение по алфавиту: узбекский на латинице и кириллице — это две полноценные ветки текста, и от выбора зависит и объём, и структура строковых файлов.
• Правила отображения данных: даты, суммы, разделители разрядов, формат телефона и адреса. Значения по умолчанию почти всегда требуют согласования с вашей стороной.
• Тексты вне приложения: описание и заголовки в магазинах приложений, шаблоны уведомлений, письма, надписи на изображениях и экранах первого запуска.
• Контактное лицо со стороны заказчика, которое согласует термины, и ориентир по датам релиза — под них мы выстраиваем этапы.

Опишите задачу и передайте то, что уже есть: часть данных обычно дособирается по ходу. Вернёмся с оценкой объёма перевода, планом работ по локализации и составом этапов — с указанием, что нужно от вас на каждом из них.