Консультація з інтернаціоналізації: виправити те, що ламається, спланувати, що далі
Ви вже знаєте, що i18n — це складно. Я бачив ці симптоми: макети RTL, що ламаються, німецький текст, який виходить за межі кнопок, відповіді API не тією мовою та переклади, які поступово втрачають синхронізацію за лічені тижні після запуску. Я не продаю чарівних пігулок. Я допомагаю Вам розв'язати конкретні проблеми, у які потрапила Ваша команда, — і побудувати системи, які не зламаються так само вдруге.
«Нам треба було спланувати це раніше»
Архітектурний податок, який Ви платите вже зараз
Ви запустилися англійською. Все працювало. Потім Ви додали французьку — «лише для цільової сторінки». І ось Ви тут, бо:
У Вашій кодовій базі перевірки lang= розкидані по 47 файлах
Продакт-менеджери питають «а можемо ми A/B-тестувати текст?», а інженери відповідають «тільки якщо все переписати»
У Вас три різні процеси перекладу, і жоден із них не працює надійно
Що ламалося на моїх очах:
- Команди, які витрачають понад 6 місяців на впровадження i18n у застосунок на Next.js, бо рядки були захардкоджені в компонентах
- Файли перекладів розсинхронізуються, бо розробники не знають, який файл оновлювати
- Періоди «заморожування локалізації» перед релізами, бо ніхто не довіряє процесу перекладу
- Небажання змінювати будь-який перекладений контент, бо робочий процес надто болісний
Чим я допомагаю:
- Стратегії рефакторингу, що дають змогу впроваджувати i18n поступово (я не вимагаю «зупиніть усе й перепишіть»)
- Організація процесу для підтримки синхронізації перекладів без блокування розробки
- Огляди архітектури, щоб визначити, де Ваш поточний підхід не впорається з 10+ мовами
i18n — це архітектура, а не функція. Намагатися додати її пізніше — це як вирішити, що Вашому будинку потрібен підвал, коли Ви його вже збудували.
Я допоможу Вам викопати той підвал — або вирішити, чи справді він Вам потрібен.
RTL ламає все
Ваш інтерфейс не розрахований на арабську, іврит чи урду
Ви змінили dir=«rtl» і побачили, як Ваш макет розсипався:
Що я бачив:
- Дизайн-системи з понад 200 компонентами, де лише 12 коректно обробляють RTL
- Команди, які використовують float: left замість логічних властивостей, що породжує баги RTL у кожній новій функції
- Спливаючі вікна та модальні вікна, що потребують окремих перевизначень RTL для кожного компонента
- Фреймворки, що заявляють про підтримку «RTL», але лише змінюють напрямок макета й ламають логіку розташування
Чим я допомагаю:
- Міграція на логічні CSS-властивості (margin-inline-start замість margin-left)
- Аудити дизайн-системи для виявлення прихованих проблем із RTL до того, як вони потраплять у продакшн
- Рекомендації для конкретних фреймворків (Tailwind, shadcn, MUI) щодо стилізації з пріоритетом RTL
Ручне виправлення багів RTL у кожному компоненті — це нежиттєздатний підхід. Я роблю підтримку RTL системною, а не постійним гасінням пожеж.
«Німецький текст зламав нашу кнопку»
Інтерфейс, не пристосований до перекладу
Англійська вміщується. Німецька — ні. Ваш дизайн передбачав:
Потім Ви переклали німецькою, фінською чи тайською і виявили:
Кнопки обрізаються посередині слова
Таблиці з горизонтальною прокруткою в кожному рядку
Текст, що переноситься в нечитабельні блоки
Нелатинський текст обрізається через фіксовану ширину контейнерів
Чим я допомагаю:
- Еластичні UI-шаблони, що адаптуються до довжини контенту
- Планування бюджету символів (враховуючи, що німецька розширюється на 30 %, а тайська не використовує пробілів)
- Системи типографіки, які працюють із CJK, арабською та деванагарі без збоїв
Я допомагаю створити інтерфейс, який витримає переклад — перш ніж Ви заплатите за 10 000 слів, які не вміщуються.
Вам не потрібна лекція про те, чому i18n важливий. Вам потрібен хтось, хто налагоджував RTL-поповери о 2 ночі, сперечався з продуктовою командою щодо бюджетів символів і проєктував конвеєри перекладу, які справді працюють.
Підводні камені, про які ніхто не попереджав
Історії з окопів від команд, які через це пройшли
Це не теорія. Це те, що зламалося в продакшені:
Пекло множини
Англійська: «1 item» проти «2 items»
Польська: «1 przedmiot» / «2 przedmioty» / «5 przedmiotów» (3 форми множини)
Арабська: 6 форм множини
Ваша логіка count === 1 ? 'item' : 'items' більше не працює.
Хаос із датою та часом
Ви форматували дати за допомогою toLocaleDateString(). А потім користувачі в Японії побачили «2025年2月9日» у Ваших CSV-експортах — і Excel задихнувся.
Невідповідність мови в API
Ваш фронтенд запитує французьку. Ваш API повертає англійську, бо токен автентифікації не передає локаль. Результат — інтерфейс із змішаними мовами, і користувачі думають, що це баг.
Тестування з псевдолокалями
Ви не протестували з [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] перед запуском у продакшн. Тепер Ваш польський сайт непридатний для використання.
Невидиме припущення
Ви думали, що перекладати треба лише рядки. А потім зіткнулися з датами, числами, валютами, сортуванням, пошуком — усе це залежить від локалі.
Чим я допомагаю:
- Реалізація ICU MessageFormat (обробка множини, роду, контексту)
- Патерни i18n для API (узгодження мови, стратегії відкату)
- Процеси контролю якості, які виявляють ці проблеми раніше за перекладацькі агенції
Найскладніше — це робочий процес
Як підтримувати синхронізацію 8 мов, коли Ви випускаєте оновлення щодня?
З технологіями Ви розібралися. Тепер Ви застрягли на процесах:
Розробники вливають код із новими англійськими рядками. Переклади відстають на 2 тижні. Користувачі бачать напівперекладений інтерфейс.
Ви не знаєте, які рядки можна безпечно видалити (вони використовуються? перекладені? на етапі обробки в агенції?)
Продукт хоче оновити текст. Ніхто не знає, чи зміна «Submit» на «Send» не зламає 12 мов.
Файли перекладу тижнями не синхронізовані з продакшном
Питання, які команди ставлять мені:
Що ламалося на моїх очах:
- Файли перекладу в git, що розходяться з рядками продакшену
- Попередження «Не чіпайте іспанський файл», бо ніхто не знає, що можна безпечно змінювати
- Функції запускаються англійською, а перекладаються через 6 місяців (якщо взагалі)
Чим я допомагаю:
- Проєктування конвеєра перекладу (коли використовувати бібліотеки i18n, коли — TMS, а коли — ШІ)
- Робочі процеси Git для синхронізації вихідних рядків і перекладів
- Автоматизація, що блокує pull request'и, якщо нові рядки не позначено для перекладу
Технічні проблеми можна розв'язати. Робочий процес — ось що гальмує. Я проєктую робочі процеси, які не потребують надлюдських зусиль для підтримки.
Команди, з якими я працював
Глобальні продукти, регіональна експертиза
LINE (Японія, Тайвань, Таїланд)
Платформа обміну повідомленнями, що працює на 3 основних ринках Східної Азії. Працював над викликами обробки CJK-символів, інтеграції з екосистемою платформи та відмінностями в очікуваннях користувацького досвіду між Японією, Тайванем і Таїландом.
KakaoTalk (Південна Корея)
Провідна платформа обміну повідомленнями в Кореї. Працював над специфічними вимогами до продукту для корейського ринку, зокрема очікуваннями щодо формальності мови в інтерфейсі та потребами інтеграції з платформою.
Change.org (196 країн, понад 20 пріоритетних мов)
Глобальна платформа для петицій, де однаково важливі швидкість і якість контенту. Налагодив процес перекладу створеного користувачами політичного й соціального контенту для різних ринків.
Airbnb (понад 220 країн, понад 60 мов)
Глобальний маркетплейс зі складними вимогами інтернаціоналізації. Консультував щодо викликів у сфері довіри та безпеки різними мовами й культурної адаптації концепцій платформи на різних ринках.
Intercom (понад 30 мов, глобальний B2B SaaS)
Платформа комунікації з клієнтами для глобальних корпоративних клієнтів. Працював над інтернаціоналізацією продукту для інструментів підтримки в реальному часі та локалізацією бази знань.
Lilith Games (Китай, Японія, Корея, США, ЄС)
Видавець мобільних ігор із продуктами, що поширюються по всьому світу. Розв'язував специфічні для ринку завдання щодо локалізації контенту та вимог регіональних платформ.
Ринки, на яких я запускав продукти:
Східна Азія (Японія, Корея, Китай):
Типографіка CJK, інтеграція з екосистемою платформи, підтримка вертикального тексту
Південно-Східна Азія (Таїланд, В'єтнам, Індонезія):
Підтримка кількох систем письма, пріоритет мобільного досвіду для користувачів
MENA (арабомовні регіони):
Вимоги до макета RTL, очікування щодо формальної та розмовної мови, культурна адаптація контенту
Європа:
24 офіційних мов, запуск продуктів у кількох країнах
Америки:
Регіональні варіації мов (латиноамериканська іспанська та іспанська з Іспанії, бразильська португальська), двомовні ринки
Я бачив на власні очі, що працює, а що ні на цих ринках — не з теорії, а з досвіду випуску продуктів, якими користуються реальні люди.
Виправмо те, що ламається
Вам не потрібна лекція про те, чому i18n важливий. Вам потрібен хтось, хто налагоджував RTL-поповери о 2 ночі, сперечався з продуктовою командою щодо бюджетів символів і проєктував конвеєри перекладу, які справді працюють.
Огляд архітектури та стратегії (1–2 тижні):
Я скажу Вам, що зламається, коли Ви додасте наступні 3 мови, і скільки коштуватиме це виправити
Підтримка виходу на ринок (4–8 тижнів):
Ви виходите на японський ринок / MENA / ЄС і потребуєте експертів, які вже це робили.
Постійне партнерство:
Вбудоване консультування під час масштабування з 2 до 20 мов
Я не займаюся теорією. Я займаюся пріоритизацією, дорожніми картами та випуском продукту.