Локалізація ламає терміни випуску: де губляться рядки
«Зберегти» вписано прямо в розмітку екрана, рядок не має ключа і в словнику він не значиться. За місяць формулювання змінюють, правка йде в код, а переклад залишається від старої версії — під час додавання мови цей рядок просто не знаходять. Втрата тиха: інтерфейс уже на тестуванні, а частина екранів новою мовою залишається попередньою.
Далі розходяться ключі. Один і той самий сенс живе під трьома іменами, перекладачі отримують їх як різні рядки й перекладають по-різному — для однієї кнопки в інтерфейсі з'являються «Видалити», «Стерти» і «Прибрати».
Локалізація інтерфейсів перетворюється на ручне звіряння: ніхто не знає, скільки рядків насправді в продукті й які з них уже не використовуються.
Випуск версії починає залежати від зовнішнього циклу перекладу. Рядки надсилають після заморозки коду, повертають частинами, і правки не встигають до дати.
Втрата рядків під час випуску стає нормою: щось вирушає неперекладеним, щось перекладено під стару версію тексту й розходиться з логікою екрана.
Терміни виходу нової мови рахуються тоді не днями роботи перекладача, а тижнями погоджень і пошуку зашитих місць.
Ми починаємо з i18n-аудиту: інвентаризуємо рядки, витягуємо жорстко зашитий текст, зводимо дублі ключів і налаштовуємо збірку так, щоб пропущений переклад зупиняв випуск, а не спливав у продакшені.
Після винесення тексту в ресурси нова мова — це набір словників і перевірок, а не правки в коді. Розбираємо, як це закривається.
Що дає контрольований контур перекладу: ефект у метриках
Контур перекладу вимірюється не числом мов у перемикачі, а часом до релізу локалізованої версії та часткою рядків, що пройшли без ручної правки. Нижче — що змінюється в метриках, коли рядки, пам'ять перекладів і перевірки працюють в одному процесі.
Час випуску версії новою мовою
Рядки йдуть на переклад під час злиття гілки: вивантаження, зіставлення з пам'яттю перекладів і повернення готових сегментів відбуваються без ручного складання файлів.
Нова мова заводиться без окремого циклу випуску — версія виходить за дні замість тижнів, а реліз уже заведеною мовою йде разом з основною збіркою.
Частка автоматичного перекладу
Пам'ять перекладів накопичує підтверджені сегменти, тому від релізу до релізу зростає частка рядків, закритих без перекладача: точні збіги — повністю, близькі — з правкою пари слів.
На зрілому проєкті автоматично закривається 80–90% обсягу, вручну залишаються нові розділи та юридичні тексти.
Класи дефектів локалізації
Помилки локалізації частіше структурні, ніж смислові: обрізаний інтерфейс, склеювання рядків, неправильні форми множини й дат, неперекладені заглушки.
Правила відмінювання та формати беремо зі стандарту Unicode CLDR, обрізання ловить автотест на найдовшому рядку мови, заглушки блокуються на збірці.
Обсяг ручних правок
Частка сегментів, які редактор править після автоперекладу, падає з третини до одиниць відсотків: спірні місця збираються в чергу вичитки за порогом упевненості, а не розмазуються по всьому тексту. Глосарій фіксує терміни, і ті самі правки не повертаються з релізу в реліз.
Режими локалізації: ручний, автоматичний, гібридний
Режим локалізації — наслідок трьох параметрів: обсягу тексту, частоти правок і ціни помилки в термінології. Якщо рядки змінюються щорелізу, а мов кілька, ручний прохід по всьому корпусу не окупається — перекладається лише дельта.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручний | Регуляторні та юридичні тексти, маркетинг, де важливий тон | Погано масштабується за частих релізів |
| Автоматичний з пост-редактурою | Великі обсяги однотипних рядків інтерфейсу, довідкові матеріали | Без глосарію втрачає однорідність, потрібна вичитка носієм |
| Гібридний | Продуктовий інтерфейс, документація, часті багатомовні релізи | Потребує налаштованої пам'яті перекладів і контролю якості |
Як це виглядає в проєкті
Гібридний режим будується навколо пам'яті перекладів: збіги підставляються автоматично, нові рядки йдуть в автоматичний переклад із редагуванням.
Глосарій термінів фіксує продуктові назви та заборонені варіанти, тому «особистий кабінет» не перетворюється на три різні терміни на трьох екранах.
Перед цим ми робимо i18n-аудит: шукаємо рядки, склеєні з фрагментів, жорстко зашитий порядок слів, місця, де довжина перекладу ламає верстку. Правка на рівні коду займає хвилини, правка після випуску — тижні вичитки всіма мовами.
Пост-редактура перекладу поділяється на легку й повну: службовим підписам достатньо перевірки термінів і підстановок, користувацькі сценарії читаються як готовий текст.
Метрика одна — частка рядків, що повернулися з автоматичного перекладу з правками; у міру наповнення пам'яті перекладів вона падає.
Етапи впровадження: від i18n-аудиту до приймання випуску
Локалізація ламається не на перекладі, а раніше — на рядках, зашитих прямо в код, склейках на кшталт «файл + число + закінчення» та розмітці всередині шаблонів.
Поки не видно, скільки тексту живе в інтерфейсі, листах, мобільних сповіщеннях і підказках, будь-яка автоматизація множить хаос. Нижче — маршрут робіт, після якого переклад стає регулярним кроком збірки, а не ручними перегонами перед випуском.
-
Інвентаризація рядків. Збираємо текстові ресурси з репозиторіїв, шаблонів, екранів, системних листів і сповіщень. Результат — реєстр: джерело, екран, стан (перекладено, застаріле, дубль). Він же стає основою оцінки обсягу.
-
Схема ключів локалізації. Проєктуємо простори імен і правила найменування: ключ прив'язаний до екрана або сутності, а не до самого тексту й не до порядкового номера. Тоді формулювання вихідною мовою можна правити без перевипуску перекладів.
-
Винесення рядків з коду. Замінюємо літерали на ключі, розбираємо склейки на шаблони з підстановкою — іншою мовою порядок слів інакше не зібрати. Окремо розмічаємо множинні форми, відмінки й роди.
-
Налаштування контуру. Підключаємо сховище перекладів, автоматичне вивантаження під час збірки та контроль, що у випуск не йде жоден ключ без перекладу. Резервна мова задається явно, а не залишається на розсуд налаштувань за замовчуванням.
-
Тестова мова й перевірка на псевдо-локалі. Прогоняємо інтерфейс тестовою мовою з псевдолокалізацією: штучно подовжуємо рядки, додаємо діакритику. Так до носія ловляться переповнення кнопок, обрізаний текст і жорстко задана ширина блоків.
-
Приймання випуску й передавання команді. Фіксуємо чек-лист: повнота ключів, відсутність неперекладеного, коректність форматів дати, числа й валюти, робота пошуку локалізованим контентом. Віддаємо схеми, скрипти перевірки та регламент оновлення — підтримка залишається у вашої команди.
Артефакти локалізації: що залишається у вашої команди
Переклад без супровідних документів живе до наступного релізу: рядки правлять прямо у файлах, терміни розходяться, приймання перетворюється на суперечку про смаки. Тому контур локалізації ми здаємо комплектом, який залишається у вашому репозиторії й не залежить від нас.
- Карта рядків — таблиця «ключ → файл → екран або сценарій → статус → відповідальний»: одразу видно, що ще не локалізовано і хто закриває прогалину.
- Глосарій — терміни з частиною мови, регістром і забороненими синонімами, підключений до пам'яті перекладів: спірний термін вирішується один раз, а не в кожному релізі.
- Політика ключів — правила найменування, заборона на склеювання фрази з фрагментів, вимоги до підстановок і узгодження числа.
- Налаштування контуру — вилучення рядків з коду, підключення каталогів перекладу, автоматичні перевірки на етапі збірки.
- Регламент приймання перекладу — що вважається блокуючим дефектом, хто приймає і за яким чек-листом повертає на доопрацювання.
- Звіт аудиту — зріз до і після: частка неперекладених рядків, дублі й «мертві» ключі, рядки, зашиті в код, втрачені підстановки.
Кожен артефакт вбудований у збірку, а не лежить окремим документом: неперекладений рядок або розходження з глосарієм гальмують випуск до релізу. Через один цикл ваша команда веде контур локалізації сама.
Кейс: як скоротили ручні правки та прискорили випуск версій
Продукт виходив чотирма мовами, а рядки для перекладу збирали вручну: розробники вивантажували таблиці, перекладачі повертали їх назад, ключі на той момент уже розходилися.
На кожній ітерації 28-30% рядків доводилося правити руками — частина втрачала підстановки, частина не вміщалася в кнопку, частина так і залишалася вихідною мовою.
Спочатку навели лад у самому каталозі: єдиний ключ, контекст екрана, межа довжини підпису й коментар для перекладача.
Потім збір рядків став частиною збірки продукту — нові та змінені фрагменти потрапляють у чергу перекладу самі, а перевірки до вивантаження відсікають склейки, втрачені підстановки й незакриті форми множини.
Через три цикли автоматично закривалося 96% рядків, частка ручних правок упала з 30% до 4%, випуск нової мови скоротився з 6-8 тижнів до п'яти робочих днів, а дефектів інтерфейсу на версію стало одиниці замість сорока з лишком.
Приймання перестало бути ручним перебором екранів: спірні місця приходять списком із зазначенням ключа й екрана.
Картина збігається з галузевою: за даними CSA Research, основний приріст у швидкості випуску мов дає автоматизація повторюваних операцій з текстом, тоді як якість тримається на глосарії, контексті та перевірках, вбудованих у конвеєр до публікації.
Чим i18n-аудит відрізняється від разової локалізації інтерфейсу?
Разова вичитка править текст у вже випущеному продукті: замовник бачить виправлені екрани, але джерело розходжень залишається.
Через реліз-два з'являються нові рядки, знову спливають склейки шаблонів, неправильний порядок слів у питаннях і відмінки в підстановках — це і є локалізаційний борг.
i18n-аудит іде від коду, а не від тексту: знаходить зашиті в розмітку фрази, перевіряє плейсхолдери та їхній порядок, множинні форми, формати дат і чисел, запас довжини підпису в кнопці, напрям письма справа наліво.
Те, що під час вичитки виглядає як друкарська помилка перекладача, часто виявляється дефектом структури рядка.
| Підхід | Коли підходить | Що залишається поза межами |
|---|---|---|
| Разова вичитка | Одна мова, потрібно швидко прибрати видимі розходження | Правила не змінюються: наступна партія рядків приносить ті самі помилки |
| i18n-аудит і постійний контур | Продукт розвивається, мов кілька, релізи регулярні | Потрібні доступ до репозиторію та узгоджений глосарій |
Постійний контур — це перевірки на збірці, ключі з контекстом для перекладача, глосарій і пам'ять перекладів. Новий рядок проходить їх до релізу, тому борг не накопичується, а переклад інтерфейсу перестає бути окремим проєктом на кожну хвилю правок.
Уже випущений продукт переводять на такий контур без зупинки релізів: спочатку правила й перевірки, потім посторінковий розбір спірних місць.
Часті запитання про автоматизацію перекладу та i18n-аудит
Замовники перевіряють не саму автоматизацію, а її краї: чи не поїде сенс, хто відповідає за термінологію, що робити з уже випущеним продуктом. Нижче — відповіді на сумніви, які спливають найчастіше.
Машинний переклад видає «майже правильно» — як зрозуміти, що результат придатний?
Оцінюємо не «красу», а частку рядків, які проходять без правки. Модель отримує глосарій продукту, пам'ять перекладів і контекст екрана — терміни та звертання не перезбираються заново в кожному релізі. Залишок править редактор-носій мови, але це одиниці відсотків рядків, а не весь обсяг.
Хто відповідає за єдину термінологію в інтерфейсі, листах і довідці?
Термінологія живе в глосарії: на кожне поняття — один переклад, частина мови, заборона синонімів. Глосарій підключається і до перекладу, і до перевірки: неприпустимий варіант зупиняє збірку локалізації до релізу. Різночитання між екранами й документацією не накопичуються.
Перекладені рядки ламають верстку — як це ловиться заздалегідь?
Підпис іншою мовою зростає, і кнопка або колонка роз'їжджається. До перекладу проганяємо псевдолокалізацію — інтерфейс на подовжених рядках, щоб вузькі місця знайшлися на тестовому стенді, а не в користувача. Окремі правила — на підстановки, відмінювання та формати чисел і дат.
Продукт уже випущено. Чи доведеться переписувати код?
Рядки виймаються з коду й шаблонів, спірні місця закриваються обгорткою, далі переклад іде тим самим контуром, що й у нових розділах. Зворотний шлях теж є: правку вносять у джерело, і контур перезбирає лише зачеплені файли, не торкаючись решти.
З чого почати: що підготувати до запуску контуру перекладу
Старт контуру перекладу — це не підключення сервісу, а інвентаризація. Поки не описано джерела рядків, правила сегментації та власників глосарію, автоматичний прохід дає різнобій у термінах і ламає змінні всередині рядків інтерфейсу.
- Карта рядків: які поверхні перекладаються (веб, мобільні збірки, листи, довідка), які залишаються мовою оригіналу, хто власник кожної.
- Аудит готовності до локалізації: склеювання рядків конкатенацією, зашиті в код формати дат, чисел і відмінків, множинні форми — усе, що заважає машинному проходу.
- Глосарій і правила термінології: усталені терміни із забороною синонімів, окремо — назви продукту та юридичні формулювання, які не перекладаються.
- Пам'ять перекладів і схема сегментації: повторювані блоки не перекладаються заново, частка збігів зростає з кожним релізом.
- Пілотна мова: один ринок із найбільшим навантаженням, на якому контур перевіряється повністю до масштабування.
- Критерії приймання: частка неперекладених рядків, кількість зламаних змінних на реліз, час вичитки, відтворюваність відкату до попередньої версії.
- Ролі та права доступу: хто погоджує термінологію, хто приймає реліз, кому надходить сповіщення про розходження.
Після пілота контур тиражується на решту мов без перезбирання процесу: змінюється лише набір глосаріїв і правила для конкретного ринку.
Опишіть задачу — обсяг рядків, поточні формати, цільові ринки та обмеження за термінами — і ми повернемося з оцінкою та планом робіт, включно з порядком пілота й чек-листом приймання.
