Консультация по интернационализации: исправим то, что ломается, и спланируем дальнейшие шаги
Вы и так знаете, что 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 logical properties (margin-inline-start вместо margin-left)
- Аудит дизайн-систем для обнаружения RTL-мин до выкатки в продакшен
- Рекомендации для конкретных фреймворков (Tailwind, shadcn, MUI) по RTL-first стилизации
Ручное исправление 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 (согласование языка, стратегии фолбеков)
- QA-процессы, которые ловят эти проблемы раньше, чем переводческие агентства
Рабочий процесс — вот где настоящая сложность
Как синхронизировать 8 языков, если вы деплоите каждый день?
С технической частью вы разобрались. Теперь вы застряли на процессах:
Разработчики мёржат код с новыми английскими строками. Переводы отстают на 2 недели. Пользователи видят наполовину переведённый интерфейс.
Вы не знаете, какие строки можно безопасно удалить (они используются? переведены? в работе у агентства?)
Продакт хочет обновить текст. Никто не знает, сломает ли замена «Отправить» на «Послать» 12 языков.
Файлы переводов неделями рассинхронизированы с продакшеном
Вопросы, которые мне задают команды:
Что я видел ломающимся:
- Файлы переводов в git, которые расходятся с продакшен-строками
- Предупреждения «Не трогайте файл с испанским», потому что никто не знает, что можно безопасно менять
- Фичи запускаются на английском, а переводятся через 6 месяцев (если вообще переводятся)
Чем я помогаю:
- Проектирование пайплайна переводов (когда использовать i18n-библиотеки, когда TMS, когда ИИ)
- Git-воркфлоу для синхронизации исходных строк и переводов
- Автоматизация, блокирующая PR, если новые строки не помечены для перевода
Техническая часть решаема. Процессы — вот где всё буксует. Я выстраиваю такие воркфлоу, которые не требуют героизма для поддержки.
Команды, с которыми я работал
Глобальные продукты, региональная экспертиза
LINE (Япония, Тайвань, Таиланд)
Мессенджер, работающий на 3 основных рынках Восточной Азии. Работал над задачами, связанными с обработкой CJK-символов, интеграцией с платформенными экосистемами и различиями в ожиданиях пользователей в Японии, Тайване и Таиланде.
KakaoTalk (Южная Корея)
Главный мессенджер Кореи. Решал задачи, специфичные для корейского рынка: требования к вежливому стилю языка в интерфейсе и интеграция с платформой.
Change.org (196 стран, 20+ приоритетных языков)
Глобальная петиционная платформа, где важны и скорость, и качество контента. Помогал выстраивать процесс перевода пользовательского политического и социального контента для разных рынков.
Airbnb (220+ стран, 60+ языков)
Глобальный маркетплейс со сложными требованиями к i18n. Помогал с безопасностью и доверием в мультиязычной среде и культурной адаптацией концепций платформы.
Intercom (30+ языков, глобальный B2B SaaS)
Платформа для коммуникации с клиентами, обслуживающая глобальных корпоративных клиентов. Работал над интернационализацией продукта для инструментов поддержки в реальном времени и локализации баз знаний.
Lilith Games (Китай, Япония, Корея, США, ЕС)
Издатель мобильных игр с глобальной дистрибуцией. Решал рыночно-специфичные задачи по локализации контента и региональным платформенным требованиям.
Рынки, на которых я запускал продукты:
Восточная Азия (Япония, Корея, Китай):
CJK-типографика, интеграция с платформенными экосистемами, поддержка вертикального текста
Юго-Восточная Азия (Таиланд, Вьетнам, Индонезия):
Поддержка нескольких письменностей, ожидания mobile-first пользователей
MENA (арабоязычные регионы):
Требования к RTL-вёрстке, ожидания по формальному vs. разговорному языку, культурная адаптация контента
Европа:
24 официальных языка, мультистрановые запуски продуктов
Америка:
Региональные вариации языка (латиноамериканский испанский vs. испанский, бразильский португальский), двуязычные рынки
Я знаю, что работает, а что проваливается на этих рынках — не из теории, а из опыта запуска продуктов, которыми пользуются реальные люди.
Давайте починим то, что ломается
Вам не нужна лекция о том, почему i18n важен. Вам нужен кто-то, кто дебажил RTL-поповеры в 2 часа ночи, спорил с продактом о лимитах символов и проектировал пайплайны переводов, которые реально работают.
Ревью архитектуры и стратегии (1–2 недели):
Я скажу, что сломается при добавлении следующих 3 языков и сколько будет стоить исправление
Поддержка выхода на рынок (4–8 недель):
Вы запускаетесь в Японии/MENA/ЕС и вам нужны эксперты с опытом
Долгосрочное партнёрство:
Постоянное сопровождение при масштабировании с 2 до 20 языков
Я не занимаюсь теорией. Я занимаюсь приоритизацией, планированием и выкаткой.