Чем Agile-локализация отличается от классической
В классической схеме разработка заканчивается, тексты собирают в пакет, отправляют переводчикам и ждут результата. При релизах раз в несколько месяцев с этим можно мириться. Когда версии выходят каждые одну-две недели, такая схема превращается в узкое место (bottleneck): тексты ждут передачи, перевод ждет текстов, а релиз ждет перевода.
В гибкой локализации строки попадают на перевод сразу после появления, переводчики работают с небольшими партиями, а готовые переводы возвращаются в продукт автоматически. Для этого процесс переводят на непрерывную локализацию: источник текстов связан с платформой, и ручные передачи исчезают.
Принципы локализации в гибкой разработке
Первый принцип — перевод следует за изменением: строки уходят на платформу сразу после добавления в репозиторий, без ручной сборки пакетов. Второй — контекст передается вместе со строкой: идентификаторы, комментарии и скриншоты помогают переводчику понять, где используется текст. Третий — ошибки ловят автоматические проверки, например на пропущенные плейсхолдеры. Четвертый — человек остается там, где нужны решения и экспертиза: менеджер определяет приоритеты, а переводчики и лингвисты отвечают за качество текста. Автоматизация убирает передачи, а не специалистов.
Что нужно, чтобы Agile-локализация работала
Нужен общий процесс для разработки и локализации. Тексты должны храниться в репозитории или CMS и иметь стабильные идентификаторы. Нужна интеграция с платформой перевода, например через API или инструмент синхронизации. Нужны память переводов и глоссарии, чтобы маленькие партии не стоили дороже и термины оставались едиными. Наконец, локализацию стоит включить в определение готовности задачи: функция не считается завершенной, пока перевод не подтвержден.
Как внедрить Agile-локализацию
Начните с оценки текущего процесса и найдите шаги, на которых тексты ждут передачи. Затем автоматизируйте самые частые из них: выгрузку строк, передачу на перевод и возврат. Проверьте цепочку на одной ветке и одном приложении, затем масштабируйте на остальные продукты и языки. Отдельно решите, как передавать контекст, например скриншоты экранов, и кто проверяет результат в интерфейсе.
Платформа перевода помогает встроить перевод в разработку: ее открытый API и связка с инструментами синхронизации позволяют подключить репозиторий, а менеджер подтверждает готовые переводы и общается с командой в чате. Подробнее — на странице Платформы перевода.
Частые ошибки
Типичная ошибка — оставить локализацию отдельным этапом после разработки, сохранив ручные передачи. Другая — переводить без контекста, из-за чего переводчик задает вопросы и релиз задерживается. Третья — отсутствие автоматических проверок: ошибки обнаруживаются только после сборки. Четвертая — отсутствие владельца процесса: автоматизация не отвечает за терминологию и приоритеты.
FAQ
Что такое Agile-локализация?
Это подход, при котором перевод идет параллельно с разработкой небольшими порциями в рамках спринтов.
Чем она отличается от обычной?
Обычная локализация начинается после готовой версии. В гибкой тексты переводят сразу, не дожидаясь конца разработки.
Нужна ли автоматизация?
Да. Без автоматической передачи строк и возврата переводов небольшие партии превращаются в постоянную ручную работу.
Нужна ли память переводов?
Да, она помогает не переводить повторяющиеся тексты заново и держит термины едиными в каждом спринте.
Подходит ли она для небольших команд?
Да, если релизы выходят часто и тексты постоянно меняются. Для редких релизов выгода будет меньше.