|
Документация
Заказать демоПлатформа
ПлатформаMCPCLIAPIРабочие процессы
Руководства
Журнал изменений

Локализация

  • Обзор
  • API локализации
  • Локализация веб-приложений
  • Локализация мобильных приложений
  • iOS и String Catalogs
  • Android и strings.xml
  • Локализация email-писем
  • Статический контент, например .md и .json
  • Next.js с Markdoc
  • Rails с i18n

Рабочие процессы

  • Настройка движка с MCP
  • Jira Triage
  • CI/CD

Локализация email-писем

CLI и API локализации Lingo.dev поддерживают два сценария локализации email-писем: перевод файлов шаблонов на этапе сборки с выпуском отдельных шаблонов для каждой локали или перевод контента во время выполнения перед отправкой. В обоих случаях используется настроенный движок локализации, который автоматически применяет правила глоссария, тональность бренда и выбранную модель.

Выберите подход#

ПодходОптимально дляКак это работает
На этапе сборки (CLI)Файлы шаблонов — JSON-строки react-emailПереводите файлы в репозитории и развёртывайте отдельные шаблоны для каждой локали
Во время выполнения (API)Динамического контента, шаблонов с рендерингом на стороне ESPВызывайте API локализации перед отправкой и передавайте переведённый контент вашему почтовому провайдеру

Какой подход выбрать?

Если переводимые тексты писем хранятся в репозитории как файлы ресурсов — используйте подход на этапе сборки. Если контент генерируется динамически или хранится у провайдера рассылок — используйте подход во время выполнения.

Что понадобится#

Каждый перевод работает через движок локализации — это конфигурация, которая задаёт модель LLM, глоссарий, тональность бренда и правила перевода. Создайте его в панели управления Lingo.dev, затем установите и авторизуйтесь в CLI:

bash
npm install -g @lingo.dev/cli
lingo login

CLI требует Node 22+. В CI задайте LINGO_API_KEY вместо запуска lingo login.

Локализация на этапе сборки#

CLI переводит контент писем из JSON-файлов ресурсов. Извлеките переводимые тексты в JSON, укажите CLI путь к ним — и рядом с исходником появятся файлы для каждой локали.

Шаблоны react-email — это React-компоненты, которые рендерятся в HTML. Вынесите переводимые строки в JSON-файлы ресурсов с помощью i18n-библиотеки, например react-i18next, а затем переведите эти JSON-файлы через CLI.

Запустите lingo init, чтобы создать конфигурацию, и lingo link, чтобы привязать организацию и движок. Итоговый файл .lingo/config.json выглядит так:

json
{
  "orgId": "org_abc123",
  "engineId": "eng_abc123",
  "sourceLocale": "en",
  "targetLocales": ["es", "fr", "de", "ja"],
  "files": [{ "pattern": "emails/locales/en.json" }]
}

Локаль задаётся в пути: CLI подставляет исходную локаль в шаблоне на каждую целевую, поэтому emails/locales/en.json даёт emails/locales/es.json, emails/locales/fr.json и так далее. Добавьте .lingo/config.json в репозиторий.

При первом запуске переводятся все локали, при последующих — только изменения:

bash
lingo push --backfill-missing   # first run / new locale
lingo push                      # delta on later runs

Во время рендеринга передайте локаль в компонент письма и загрузите соответствующий JSON-файл. Функция react-email render() создаст HTML для нужной локали, готовый к отправке.

Чтобы получить результаты последнего запуска push в любой момент, используйте lingo pull. Чтобы проверить актуальность переводов без записи изменений (например, в CI) — используйте lingo check.

Локализация во время выполнения#

Если контент писем динамический — персонализированные уведомления, сводки пользовательского контента или маркетинговые тексты из CMS, — переводите его во время выполнения перед отправкой. Этот сценарий основан на подходе, описанном в руководстве по API перевода.

javascript
async function sendLocalizedEmail(userId, templateId, content) {
  const user = await db.users.findById(userId);

  const response = await fetch("https://api.lingo.dev/process/localize", {
    method: "POST",
    headers: {
      "X-API-Key": process.env.LINGODOTDEV_API_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      engineId: "eng_abc123",
      sourceLocale: "en",
      targetLocale: user.locale,
      data: {
        subject: content.subject,
        preheader: content.preheader,
        body: content.body,
      },
    }),
  });

  const { data } = await response.json();

  await emailProvider.send({
    to: user.email,
    subject: data.subject,
    html: renderTemplate(templateId, data),
  });
}

Рекомендации#

ОбластьРекомендация
Темы писемНе превышайте 50 символов. Используйте глоссарий, чтобы названия брендов не переводились.
Превью-текстПереводите отдельно от основного текста — почтовые клиенты показывают его независимо.
Тональность брендаНастройте тон для каждой локали в движке локализации. Маркетинговым письмам на японском нужен иной регистр, чем на немецком.
RTL-языкиПроверяйте итоговое отображение в почтовых клиентах для арабского, иврита и персидского. Обработка HTML dir="rtl" отличается от клиента к клиенту.
Блокировка ключейИспользуйте locked keys для URL, названий продуктов и юридических идентификаторов, которые не должны переводиться.

Что дальше#

API перевода
Подробное руководство по локализации во время выполнения через API
Тональность бренда
Настройте тон и формальность для каждой целевой локали
Глоссарии
Управляйте тем, какие термины переводятся, а какие остаются без изменений
GitHub App
Автоматический перевод шаблонов писем при каждом pull request

Эта страница была полезной?

Max PrilutskiyMax Prilutskiy·Обновлено 8 дней назад·4 минуты чтения