Какими инструментами проверял интернационализацию на проекте

Инструменты для проверки интернационализации (i18n) и локализации (l10n)

Проверка интернационализации — это комплексный процесс, выходящий за рамки простого перевода текста. В своей практике я использовал и комбинировал несколько категорий инструментов, чтобы обеспечить полноценную поддержку продукта на международных рынках.

1. Инструменты для извлечения и управления переводами

Это основа любого проекта с i18n. Их цель — вынести строки из кода в отдельные ресурсные файлы.

• i18next / react-i18next: Стандарт для React-приложений. Позволяет легко помечать строки для перевода, управлять пространствами имён (namespaces) и загружать переводы асинхронно. Для проверки я часто смотрю структуру JSON-файлов переводов и корректность ключей.

  // Пример файла перевода (en/translation.json)
  {
    "welcome": "Welcome, {{name}}!",
    "products": {
      "title": "Our Products",
      "count": "{{count}} product",
      "count_plural": "{{count}} products"
    }
  }
  

• gettext (.po/.mo файлы): Классический инструмент, особенно распространённый в бэкенд-разработке (Python, PHP). Утилиты вроде xgettext извлекают строки из кода, а msgfmt компилируют .po файлы в бинарный формат .mo.
• Сервисы управления переводами (TMS): Crowdin, Phrase, Transifex. Они предоставляют UI для переводчиков, контекст (скриншоты), управление версиями и прямое взаимодействие с Git-репозиторием. Моя проверка здесь фокусируется на корректности конфигурации синхронизации и отсутствии конфликтов при мерже переводов.

2. Инструменты для функционального и визуального тестирования

• Ручное тестирование с подменой локали:

    *   В браузере: смена языка в настройках, использование расширений для подмены локали.
    *   В мобильных приложениях: смена языка и региона в настройках устройства/симулятора.
    *   На бэкенде: передача заголовка `Accept-Language` через инструменты вроде **Postman** или **Swagger**.

    ```http
    GET /api/v1/products HTTP/1.1
    Host: api.example.com
    Accept-Language: fr-CH, fr;q=0.9, en;q=0.8
    ```

• Автоматизация с помощью Selenium/Playwright/Cypress: Пишем тесты, которые запускают сценарии на разных языках, проверяя не только наличие текста, но и его корректность в UI.

  // Пример на Playwright
  import { test } from '@playwright/test';
  const locales = ['en', 'fr', 'ja'];
  
  for (const locale of locales) {
    test(`Check login page for ${locale}`, async ({ page }) => {
      await page.goto(`https://app.com?lang=${locale}`);
      await expect(page.locator('h1')).toHaveText(locale === 'fr' ? 'Connexion' : 'Login');
      await expect(page).toHaveScreenshot(`login-${locale}.png`);
    });
  }
  

• Визуальный регрессионный тест (например, Percy, Chromatic): Критически важен для i18n, так как длина текста может сильно отличаться. Эти инструменты ловят "поломки" вёрстки: обрезанный текст, наезжающие друг на друга элементы, сломанные контейнеры.

3. Инструменты для проверки качества контента и форматов

• Скрипты для проверки псевдолокализации: Это не перевод, а подмена строк на "фейковый" язык, который помогает выявить проблемы хардкода, конкатенации строк и недостаточной гибкости UI (например, "Hello" → "[Ĥéļļö]"). Пишется кастомно или с помощью библиотек.

  # Упрощённый пример псевдоперевода
  def pseudo_localize(text):
      mapping = {'a': 'α', 'e': 'ë', 'o': 'ø', 'l': 'ł', 'H': 'Ĥ'}
      for char, replacement in mapping.items():
          text = text.replace(char, replacement)
      return f"[{text}]"
  

• Проверка форматов (ICU): Использование библиотеки formatjs или аналогов для проверки корректности плюральных форм (one, few, many, other), интервалов, форматирования дат, чисел и валют.

  // Проверка плюральной формы
  new Intl.PluralRules('ru').select(5); // Вернёт 'many' для числа 5
  

• Линтеры и статический анализ: Инструменты вроде eslint-plugin-i18n или i18next-scanner для поиска непереведённых строк прямо в коде на этапе разработки.

4. Инфраструктурные и кросс-культурные проверки

• Тестирование RTL (Right-to-Left): Для арабского, иврита. Проверяем не только зеркальное отображение интерфейса, но и положение элементов (иконок, числительных) с помощью CSS-атрибутов типа dir="rtl". Инструменты — те же фреймворки автоматизации.
• Чек-листы и тест-кейсы: Самый важный "инструмент". В них я фиксирую проверки:

    *   **Кликабельность и отображение** всех переведённых элементов.
    *   **Длина текста** (обрезание, переносы).
    *   **Форматирование**: даты (`DD/MM/YYYY` vs `MM/DD/YYYY`), время (12/24ч), числа (разделители тысяч и десятичные), валюта (символ и позиция).
    *   **Кодировка и шрифты** (поддержка CJK-символов, диакритических знаков).
    *   **Культурная уместность**: цвета, изображения, символы.
    *   **SEO-метаданные** (title, description) для каждой локали.
    *   **Производительность**: не "скачивается" ли весь словарь разом, а только нужная локаль.

Вывод: Не существует одного "волшебного" инструмента. Эффективная проверка i18n — это стратегия, сочетающая автоматизацию (линтеры, скрипты псевдолокализации, UI-тесты) для отлова технических ошибок и скрупулёзное ручное тестирование с привлечением носителей языка для проверки смысла, культурного контекста и общего UX. Ключевая цель — убедиться, что продукт не просто говорит на другом языке, но и чувствует себя "как дома" в целевой культуре.