Localization Engineering Vocabulary: i18n, l10n, XLIFF, and TMS Explained (англійською)

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

i18n vs l10n — Основне відмінність

Інформаційна індустрія стискає довгі слова, зберігаючи першу і останню літери і підраховуючи символи між ними. Інтернаціоналізація має 18 символів між i і n, отже i18n. Локалізація має 10 символів між l і n, отже l10n. Такий же шаблон дає нам g11n (глобалізація, загальна бізнес-стратегія) і t9n (переклад, один компонент l10n).

Це не синонім. Вони описують різні фази одного і того ж конвеєра:

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

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

«Ми закінчили i18n framework — всі рядки екстерналізовані, а форматування дати є локально-чутливим. Робота над l10n починається, коли ми передаємо файли XLIFF команді перекладачів і додаємо французьку.»

Ви збираєте i18n один раз. Ви робите l10n для кожної нової локалі.

---

47 тис. мовців

** BCP 47 ** (IETF Best Current Practice 47) визначає стандартний формат для міток мови. Повна структура — language-Script-REGION, де кожен елемент є необмеженим поза базової мови:

• en — англійська (не вказаний регіон)
• en-GB — англійська, якою говорять у Великій Британії
• zh-Hant-TW — традиційна китайська (Hant письмо), як використовується на Тайвані
• sr-Latn-RS — Сербська письмова латиницею, як використовується в Сербії
• pt-BR — бразильська португальська

Критична точка для інженерних розмов: en сам по собі не є повною локалізацією для продукту. Американська англійська, британська англійська і австралійська англійська відрізняються правописом, форматом дати і словником. Продукт, що відправляється до всіх трьох, повинен явно націлюватися на en-US, en-GB і en-AU.

Резервний локальний ланцюг

На практиці, не кожен рядок буде мати переклад для кожної локалі. Системи реалізують ** локальну резервну мережу ** для елегантного зниження якості:

«Якщо користувач запитує pt-BR, ми повертаємося до pt (загальна португальська), а потім повертаємося до en-US як бази локалі»

Під час планування розмов, стандартно розрізняти локалі рівня- 1 (повністю перекладені і перевірені під час запуску) від локалів рівня- 2 (машинно перекладені або створені спільнотою):

«Ми націлюємося на локалі Tier-1 для запуску: en-US, fr-FR, de-DE, ja-JP, zh-CN, pt-BR, і es-MX. Tier-2 буде доставлений в Q3»

---

ICU MessageFormat і CLDR Правила множини

Найбільш поширеною помилкою i18n в англомовних інженерних командах є створення логіки множинності, яка працює в англійській мові і не працює в будь- якій іншій мові. Канонічний поганий приклад:

"You have %d message(s)" // untranslatable — "message(s)" is an English hack

Цей шаблон не локалізований. Польська має чотири форми множини. Арабська має шість. У росіян три. Закодування одного рядка на ціле число (message_0, message_1, message_5, тощо) стає непрактичним в будь-якому масштабі.

Формат повідомлення ICU

** ICU MessageFormat ** — це стандартне рішення, розроблене проектом IBM International Components for Unicode, яке зараз підтримується всіма основними бібліотеками i18n. У ньому використовується декларативний синтаксис, який міститься у самому рядку повідомлення:

{count, plural,
  one {You have # message}
  other {You have # messages}
}

Для мови з більшою кількістю форм множини (російська):

{count, plural,
  one {У вас # сообщение}
  few {У вас # сообщения}
  many {У вас # сообщений}
  other {У вас # сообщения}
}

Категорії множини — zero, one, two, few, many, other — визначені CLDR (Unicode Common Locale Data Repository). CLDR є авторитетним джерелом даних для правил, що стосуються локалі: категорій множини, шаблонів форматування чисел, впорядкування дат тощо.

«Ми перейшли на ICU MessageFormat, щоб правильно обробляти правила множини у всіх 20 локалях цілі. Раніше у нас була твердо кодована система ключів, що вже була пошкоджена в польській мові і ніколи не працювала б для арабської.»

---

Переклади та словники

XLIFF

** XLIFF ** (XML Localization Interchange File Format) — це стандартний формат обміну даними локалізації ISO. Він структурує джерельні рядки разом з їх перекладами в портативному форматі XML, який може використовувати і виробляти будь-яка велика система TMS.

Мінімальний елемент <trans-unit> — запис на рядок у файлі XLIFF — виглядає так:

<trans-unit id="nav.home">
  <source>Home</source>
  <target state="translated">Accueil</target>
</trans-unit>

Атрибут state відстежує прогрес: new, needs-translation, translated, final. У інженерних розмовах ви почуєте “скільки одиниць не перекладено” як метрику готовності до запуску.

Пам’ять перекладу

** Пам’ ять перекладів (ПП) ** — це база даних попередньо перекладених пар рядків джерело- призначення. Коли новий рядок надсилається для перекладу, TMS перевіряє пам’ ять перекладу на наявність подібних попередніх перекладів:

• ** 100% збіг ** — рядок ідентичний попередньо перекладеному рядку; автоматично застосовується без додаткових витрат на переклад
• ** Нечітке збігнення ** — рядок схожий, але не ідентичний, зазвичай, вище порогу подібності 85% або 95%; перекладач переглядає і підтверджує, а не перекладає з нуля
• ** Повторення ** — один і той же рядок з’ являється декілька разів у файлах джерела; підраховується один раз для перекладу

TM зменшує витрати і забезпечує послідовність. Фраза, перекладена у одному напрямку у потоці впровадження програми, має бути перекладена ідентично у документації довідки.

Інструменти ТМС

** TMS (Translation Management System) ** організовує роботу з локалізації: введення файлів, призначення перекладачів, пошук пам’ яті, створення проектів машинних перекладів, перевірка якості і експортування назад до сховища. Основними платформами в інженерних контекстах є Phrase (раніше Phrase Strings), Crowdin і Lokalise.

Ключові можливості TMS, на які посилаються у технічних розмовах:

• ** Інтеграція з GitHub ** — файли XLIFF або JSON автоматично витягуються зі сховища і відсилаються назад, уникаючи вручну обробляти файли
• ** MT + процес перегляду людьми ** — рушій машинного перекладу (DeepL, Google або нетипова модель) створює проект перекладу; людина- перекладач переглядає і підтверджує його
• ** Примусове виконання глосарію** — терміни, що стосуються продуктів (назва бренду, назви можливостей) буде заблоковано для схвалених перекладів у всіх рядках
• ** Перевірка якості ** — автоматична перевірка на відсутність символів заміщення, невідповідності пунктуації, невідповідності формату чисел і надто довгі перекладені рядки, які можуть пошкодити компонування інтерфейсу користувача

---

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

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

Hello, World! → [Ĥéļļö, Ŵöŗļð!]

Ця одна методика механічно виявляє чотири класи помилок локалізації:

1. ** Закодовані рядки ** — будь- який рядок, який обходить конвеєр локалізації, залишається у початковій формі, що робить його візуально відмінним від псевдо- локалізованих рядків у інтерфейсі користувача
2. ** Розрив макету від розширення тексту ** — перекладені рядки зазвичай на 30- 50% довші за англійські; псевдо- локаль використовує довші заміни, щоб імітувати це розширення, негайно виявляючи обрізання і помилки переповнення
3. ** Вади з’ єднання рядків ** — динамічно зібрані рядки (наприклад, "You have " + count + " messages" ) не можна правильно локалізувати, оскільки перекладач не може змінити порядок фрагментів; обгортання дужками робить ці вади візуально очевидними
4. ** Вади відтворення RTL ** — псевдо- локалі можуть включати двосторонні символи перевизначення Unicode для імітації розкладки справа ліворуч, що спричиняє регресію відтворення, властиву RTL

«Ми запускаємо псевдо-локал як частину нашого CI візуального регресійного набору — він ловить регресії макету і твердо кодовані рядки до початку реальної роботи з перекладом. Це врятувало нас від щонайменше трьох неприємних виробничих помилок»

---

Локалізація інженерії є дисципліною, де точність англійської лексики безпосередньо впливає на якість реалізації: команда, яка об’єднує i18n і l10n буде архітектором систем, які вирішують тільки половину проблеми. Для практики, досліджуйте CoderLingo вправи з локалізації словника і Розмовник i18n, щоб підсилити ці терміни в контексті.