Переклад в ІТ та інноваціях: коли текст є частиною продукту, а не документом про нього

Усі попередні статті цього циклу описували роботу з документами. Інструкція, регламент, проєкт, контракт — це завершені тексти з автором, датою і версією. Перекладач отримує файл, повертає файл, проєкт закривається.

В ІТ так не працює.

Тут текст вбудований у продукт. Він живе в ресурсних файлах разом із кодом, змінюється з кожним релізом, з’являється в інтерфейсі поруч зі змінними та плейсхолдерами й відображається в просторі, який має фізичні межі. Проєкт не закривається — він триває стільки, скільки живе продукт.

Саме тому в цій сфері вживають слово «локалізація», а не «переклад». І це не маркетингова заміна терміна, а точний опис іншого типу роботи.

Що входить у сферу

Програмні продукти. Інтерфейси десктопних, веб- і мобільних застосунків, SaaS-платформи, вбудоване програмне забезпечення, адміністративні панелі.

Документація. Посібники користувача й адміністратора, довідкові системи, документація API, примітки до випусків, бази знань і матеріали служби підтримки.

Маркетинг. Сайти й лендінги, описи в магазинах застосунків, розсилки, кейси, блоги, презентації.

Юридичні тексти. Умови використання, ліцензійні угоди, політики конфіденційності, угоди про обробку даних.

Навчальні матеріали. Онбординг, курси, сертифікаційні програми, відео й субтитри.

Інновації. Патентні заявки, грантові проєкти, матеріали для інвесторів, документація R&D, due diligence.

Ігрова локалізація формально теж належить сюди, але має настільки власну специфіку — це й персонажі, і озвучення, і культурна адаптація, і обмеження платформ — що заслуговує на окремий розгляд.

Особливість перша: текст живе в коді

Локалізаційний файл — це не документ, а структура даних. Практичні наслідки:

• Плейсхолдери й змінні. Рядок «Deleted %d files from %s» містить два підставні значення. Їх не можна перекладати, губити чи міняти місцями без спеціального синтаксису. У мовах, де порядок слів природно інший, потрібні позиційні аргументи (%1$s, %2$s), і якщо розробник їх не передбачив — це проблема розробника, яку локалізатор має помітити й повідомити.
• Розмітка всередині рядків. HTML-теги, посилання, форматування. Теги зберігаються, текст усередині перекладається, атрибути — залежно від типу.
• Керівні послідовності. Переноси рядків, табуляції, екрановані лапки. Втрачений символ ламає відображення.
• Ключі рядків. Ідентифікатори, за якими застосунок звертається до тексту. Не перекладаються ніколи.

Множина: головний технічний виклик української локалізації

Англійська має дві форми множини: 1 file / 2 files. Українська має чотири: 1 файл, 2 файли, 5 файлів, 1,5 файлу.

Це означає, що рядок, у якому розробник передбачив дві форми, фізично не може бути коректно локалізований українською. Правильне рішення — використання стандартного механізму плюралізації (ICU MessageFormat або plural forms у gettext), який підтримує потрібну кількість форм.

Локалізатор, який просто пише «файл(ів)» або «5 файли», приховує проблему замість того, щоб її розв’язати. Професійний підхід — зафіксувати дефект інтернаціоналізації і передати команді розробки.

Відмінювання й рід

Дві пов’язані між собою складнощі, яких немає в англійській:

1. Підставлені значення не відмінюються. «Видалити {filename}?» працює, а «Перейти до {section}» уже може вимагати родового чи знахідного відмінка залежно від слова, якого локалізатор не бачить. Рішення — перебудувати фразу на конструкцію, яка не потребує узгодження.
2. Рід не визначений. «User added a comment» українською вимагає вибору форми дієслова: додав чи додала. Варіанти — знеособлена конструкція («Додано коментар») або технічне рішення на боці продукту.

Конкатенація рядків — окремий антипатерн. Коли інтерфейс склеює фразу з двох-трьох частин, кожна з яких перекладається окремо, отримати граматично коректну українську неможливо в принципі.

Особливість друга: рядок без контексту

Найпоширеніша причина помилок локалізації — не незнання мови, а відсутність контексту.

Слово Open може бути дією на кнопці (Відкрити) або статусом у списку (Відкритий). Post — іменник чи дієслово? Free — «безкоштовний» або «вільний»? Set — «набір» чи «встановити»? Home — «головна сторінка», «домівка» чи «початок»? У ресурсному файлі це просто рядки, вирвані з інтерфейсу.

Що допомагає зорієнтуватися:

• скріншоти;
• коментарі розробника до рядків (максимальна довжина, тип елемента, пояснення);
• інформативні ключі: button.settings.save замість str_0147;
• перегляд перекладу безпосередньо в інтерфейсі перед релізом.

Прохання «дайте контекст» від локалізатора — це не ознака непрофесійності, навпаки. Виконавець, який ніколи не ставить таких запитань, просто вгадує.

Особливість третя: обмеження простору

Текст, перекладений з англійської на українську, у середньому довший на 15–20%, а на коротких рядках — удвічі й більше. Найгостріші зони:

• кнопки й пункти меню фіксованої ширини;
• мобільні екрани;
• таблиці й колонки з даними;
• заголовки в магазинах застосунків, де ліміт символів жорсткий і рахується автоматично;
• сповіщення й тости.

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

Особливість четверта: процес не має кінця

Продукт випускається спринтами. Кожен реліз приносить нові рядки, змінені рядки й видалені рядки. Пакетна модель «зібрали за квартал — відправили на переклад» тут не працює: локалізація має рухатися разом із розробкою.

Це означає інтеграцію на рівні інструментів: система керування локалізацією підключається до репозиторію або дизайн-файлів, нові рядки надходять автоматично, готовий переклад повертається в збірку. Ми працюємо в такому режимі, зокрема через Crowdin, поряд зі стандартним стеком перекладацьких інструментів.

Наслідки для якості:

• терміни виконання вимірюються годинами, а не тижнями;
• порції маленькі, а вимога узгодженості — така сама, як для великого документа;
• пам’ять перекладів і термінологічна база стають не інструментом економії, а умовою зв’язності продукту;
• один і той самий виконавець має вести продукт довго, бо він накопичує розуміння контексту, якого немає у файлах.

Термінологія: три різні проблеми

Проблема перша: відповідність платформі

Застосунок живе не сам по собі, а в середовищі операційної системи. Якщо в системі елемент називається «Налаштування», у застосунку не може бути «Установки». Якщо система каже «Обліковий запис», продукт не каже «Акаунт».

Джерела істини — офіційні термінологічні бази й стилістичні посібники платформ. Це не питання смаку: користувач сприймає невідповідність як помилку продукту.

Проблема друга: термінологія, яка ще не усталилася

Штучний інтелект, DevOps, блокчейн, кібербезпека — сфери, де українська термінологія формується просто зараз. Одні поняття мають кілька конкурентних варіантів, інші не мають жодного усталеного.

Правило, яке працює: послідовність усередині продукту важливіша за «правильність загалом». Рішення ухвалюється один раз, разом із клієнтом, фіксується в глосарії і дотримується. Найгірший варіант — коли в межах одного інтерфейсу з’являються і «розгортання», і «деплой», і «деплоймент».

Три можливі стратегії для нового терміна: український відповідник, транслітерація, збереження латиницею. Для кожного шару термінології стратегія може бути різною, і це нормально — ненормально, коли її обирають щоразу наново.

Проблема третя: хибні друзі ІТ-перекладу

• Application — «застосунок» у програмному контексті, але «заявка» в бізнес-контексті;
• image — «образ» (диска, контейнера) або «зображення»; два різні терміни;
• library — «бібліотека», і в цьому значенні це не книгозбірня;
• thread — «потік» виконання або «гілка» обговорення;
• instance — «екземпляр»;
• host — «вузол», «хост» або «приймати» (як дієслово);
• driver — «драйвер», а не «водій» і не «чинник»;
• commit, branch, merge — усталені відповідники в контролі версій, які не збігаються з побутовими значеннями;
• resolution — «роздільна здатність» або «розв’язання проблеми»;
• execute — «виконати».

Окремо — норми правопису: «застосунок», а не «додаток» (у значенні програми); слова «вебсайт», «вебсервіс», «онлайн» пишуться разом.

UX-текст: жанр, у якому буквальність шкодить

Мікрокопія інтерфейсу — кнопки, підказки, порожні стани, повідомлення про помилки, онбординг — потребує іншого підходу, ніж документація.

Тут працює не точність відтворення, а функція. Англійське Get started дослівно не перекладається; потрібно те, що виконує ту саму роль українською в тому самому обсязі символів.

Кілька практичних принципів:

• повідомлення про помилку має пояснювати, що сталося і що робити далі. «Сталася помилка» — неінформативно; технічний код без пояснення — теж;
• уникати звинувачення користувача: не «ви ввели неправильний пароль», а «пароль не підходить»;
• тон голосу фіксується стайлгайдом, включно з вибором між «ви» і «ти», ступенем формальності та ставленням до гумору;
• доступність — альтернативні описи зображень і мітки для екранних читачів перекладаються повноцінно, а не за залишковим принципом.

Юридичні тексти в ІТ: пастка невідповідності систем

Політики конфіденційності та угоди про обробку даних часто пишуться відповідно до європейського законодавства про захист даних, а застосовуються в українському правовому полі. Термінологія цих двох систем не збігається повністю: ролі учасників обробки в українському законодавстві названі інакше, ніж у GDPR.

Це той випадок, коли механічна підстановка «звичного» відповідника змінює юридичний зміст. Правильний підхід — уточнити з клієнтом, у якій системі має жити документ, і за потреби зберегти оригінальні терміни з поясненням.

Формати даних, які легко зламати

• Дата: український формат ДД.ММ.РРРР проти американського ММ/ДД/РРРР — 03.04.2026 читається по-різному в різних мовах.
• Час: 24-годинний формат.
• Десятковий роздільник — кома; розділювач розрядів — нерозривний пробіл.
• Валюта: позиція символу, скорочення, конвертація.
• Одиниці вимірювання й розміри файлів.
• Сортування за абеткою: кириличний порядок відрізняється від латинського.
• Часові пояси й перехід на літній час.
• Кодування: усе має бути в UTF-8, і поява «абракадабри» — ознака проблеми в конвеєрі, а не в перекладі.

Інновації: патенти, гранти, інвестиційні матеріали

Патентні заявки — окремий жанр із власними правилами. Формула винаходу традиційно будується як одне речення з фіксованою структурою, а термінологія має бути абсолютно послідовною між описом і формулою: одна деталь — одна назва протягом усього документа. Тут буквальність є не вадою, а вимогою: розширення або звуження формулювання змінює обсяг правової охорони.

Грантові заявки та звіти європейських програм мають власну лексику результатів, індикаторів і робочих пакетів, а також усталені формулювання, які краще брати з офіційних документів програми, ніж перекладати наново.

Матеріали для інвесторів — презентації, меморандуми, документи due diligence — вимагають поєднання технічної точності з бізнесовим регістром, а часто й стислості, якої в оригіналі немає.

Типові помилки в локалізації

• Перекладені або пошкоджені плейсхолдери та ключі рядків.
• Утворення на кшталт «файл(ів)» та інші обхідні шляхи замість коректної плюралізації.
• Переклад рядка в неправильному значенні через відсутність контексту.
• Текст, що не вміщується в елемент інтерфейсу.
• Розбіжність із термінологією операційної системи.
• Кілька варіантів одного терміна в межах продукту.
• Дослівний переклад мікрокопії, який звучить неприродно.
• Американський формат дати в українському інтерфейсі.
• Ігнорування альтернативних описів і міток доступності.
• Підстановка термінів GDPR у документ, який працює за українським правом.

Як ми працюємо з ІТ-проєктами

У «Профпереклад» локалізаційні проєкти ведуть лінгвісти з ІТ-спеціалізацією, з обов’язковим редагуванням, коректурою і автоматизованою перевіркою. Специфіка галузі додає до стандартного циклу такі елементи:

• закріплення сталої команди за продуктом, щоб контекст накопичувався, а не втрачався між релізами;
• інтеграцію із системою керування локалізацією клієнта, зокрема Crowdin, для безперервного потоку рядків замість пакетних передач;
• формування глосарію та стайлгайду на старті: термінологія, тон голосу, звертання, стратегія щодо нових понять;
• звіряння інтерфейсної термінології з офіційними базами платформ;
• автоматизовану перевірку плейсхолдерів, тегів, ключів і обмежень довжини;
• фіксацію дефектів інтернаціоналізації на боці продукту з поясненням, що саме треба виправити в коді;
• перевірку перекладу в контексті інтерфейсу перед релізом там, де клієнт може надати складання;
• окремих виконавців для маркетингових і юридичних матеріалів, бо це інші жанри, ніж інтерфейс.

Для продуктових компаній це означає, що локалізація припиняє бути вузьким місцем релізного циклу й починає рухатися з тією самою швидкістю, що й розробка.

«Профпереклад» — компанія № 1 на ринку перекладацьких послуг України за рейтингом CSA Research, сертифікована за стандартом ISO 17100:2015. Понад 18 років працюємо з локалізацією програмних продуктів, технічною документацією та матеріалами інноваційних проєктів.