# General Translation Knowledge Base: Что проверить перед запуском многоязычного приложения?
URL: https://generaltranslation.com/ru/kb/multilingual-app-launch-checklist.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Перед запуском многоязычного приложения проверьте девять аспектов в каждой поддерживаемой локали: пользовательские сценарии целиком, включая ошибки; определение и переключение языка; переменные и формы множественного числа; валюту и часовые пояса; увеличение длины текста; вёрстку для языков с письмом справа налево; доступность; доставку переводов в рабочей среде; индексируемые языковые URL для SEO. Для каждой проверки нужен явный критерий успешного прохождения.
Category: Интернационализация
Last updated: 2026-10-16
Authors: Jackie Chen
Published: 2026-10-16

Переведённая главная страница может выглядеть готовой, а оформление заказа, ошибки валидации или сброс пароля при этом по-прежнему отображаются на языке-источнике. Начните со сценариев, которые пользователь должен пройти до конца, и тестируйте их в сборке для рабочей среды.

Перед запуском многоязычного веб-приложения проверьте эти девять аспектов в каждой поддерживаемой локали:

1. **Сценарии переведены целиком**, включая состояния загрузки, пустые состояния и ошибки, письма и уведомления.
2. **Язык выбирается единообразно** при первом посещении, после переключения и при повторных визитах.
3. **Переменные и формы множественного числа корректны** для каждой категории множественного числа, используемой в ваших языках.
4. **Валюта и часовой пояс заданы явно** и независимо от языка UI.
5. **Вёрстка не ломается при увеличении длины текста** на узких экранах и при масштабировании в браузере.
6. **Для языков с написанием справа налево** заданы правильное направление письма и вёрстка, а текст со смешанным направлением отображается корректно.
7. **Вспомогательные технологии получают правильный язык**, подписи и доступные имена.
8. **Сборка для рабочей среды содержит все переводы**, а новые тексты переводятся до релиза.
9. **У публичных страниц есть индексируемые языковые URL** с переведёнными метаданными и `hreflang`.

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

## Проверка отображения контента и переключения языка

### 1. Переводите весь пользовательский сценарий, включая состояния ошибок

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

**Критерий прохождения:** в каждой области взаимодействия с пользователем используется проверенный контент на целевом языке, кроме намеренных исключений вроде названия продукта. Нигде не отображаются необработанные ключи, маркеры отсутствующих сообщений или необъяснимые резервные варианты на исходном языке.

**С General Translation:** убедитесь, что в релиз попадает именно результат [`gt translate`](/docs/cli/reference/commands/translate). ([`gt generate`](/docs/cli/reference/commands/generate) только записывает исходные шаблоны, в которые ещё нужно добавить переведённый текст.) Рецензенты исправляют формулировки в [Редакторе переводов на панели управления](/docs/platform/dashboard/guides/reviewing-translations); если же ваша команда редактирует сгенерированные файлы прямо в репозитории, выполните [`gt save-local`](/docs/cli/reference/commands/save-local), чтобы последующие запуски не затирали эти правки. Чтобы термины продукта оставались единообразными в приложении, документации и уведомлениях, ещё до генерации переводов назначьте общие термины Glossary и пользовательские промпты с помощью [контекстных групп](/docs/platform/dashboard/guides/defining-context-for-translations). Изменения контекста влияют только на новые переводы и не переписывают существующие.

### 2. Проверьте первое посещение, переключение языка и повторные визиты

Проверьте поведение в чистом браузере, при явном выборе языка, после перезагрузки страницы, при переходе по глубокой ссылке и при неподдерживаемом языке браузера. Если приложение сохраняет языковые предпочтения в аккаунте, проверьте также вход в систему и выход из неё. Зафиксируйте, какая настройка имеет приоритет, если URL, сохранённое предпочтение и язык браузера не совпадают.

**Критерий прохождения:** приложение последовательно следует этим правилам, а пользователь может отменить нежелательный выбор языка. Для приложений с отрисовкой на сервере проверяйте как исходный ответ сервера, так и страницу после гидратации.

Идентификаторы локалей соответствуют BCP 47: `es-MX` и `es-AR` могут быть отдельными целевыми локалями для мексиканского и аргентинского испанского. Протестируйте каждую региональную локаль, которую вы выпускаете. Переключатель на основе cookie-файлов и маршруты с префиксом локали решают разные задачи; проверьте, как URL на самом деле ведут себя в приложении.

**С General Translation:** укажите поддерживаемые языки, включая региональные варианты, в [конфигурации локалей](/docs/react/guides/managing-locales).

### 3. Проверьте переменные и категории множественного числа

Проверьте разные количества, включая 0, 1, 2 и большие значения, затем добавьте тестовые случаи для категорий множественного числа ваших целевых языков. Используйте имена со знаками препинания, длинные названия аккаунтов и предложения, в которых переменные после перевода могут оказаться в другом порядке. Не собирайте предложение из отдельно переведённых фрагментов.

**Условие прохождения:** значения не искажены, предложение читается правильно, и для каждой обязательной формы множественного числа есть пригодный текст. В [правилах множественного числа](https://cldr.unicode.org/index/cldr-spec/plural-rules) от Unicode объясняется, почему одной английской пары «единственное/множественное число» для проверки недостаточно.

**С General Translation:** [`<Plural>`](/docs/react/reference/components/plural) следует правилам множественного числа локали: в английском две количественные категории, а в арабском — шесть. Используйте [`<Branch>`](/docs/react/reference/components/branch), когда формулировка зависит от явного значения, например грамматического рода человека, и [`<Var>`](/docs/react/reference/components/var) — для динамического текста, например имени. Значения внутри этой обёртки для переменных не отправляются в API перевода. Паттерн реализации описан в [статье об обработке форм множественного числа в React](/kb/how-to-handle-plurals-in-react).

## Проверьте форматирование, вёрстку и доступность

### 4. Разделяйте язык, валюту и часовой пояс

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

Например, этот код форматирует уже имеющуюся сумму в USD по немецким правилам:

```js
new Intl.NumberFormat('de-DE', {
  style: 'currency',
  currency: 'USD',
}).format(1234.5);
```

Он форматирует переданную сумму, не конвертируя валюту. При форматировании отображаемые цифры могут округляться, поэтому убедитесь, что точность соответствует требованиям вашего продукта. Точно так же, чтобы показать момент времени для выбранного местоположения, явно указывайте часовой пояс:

```js
new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone: 'Europe/Paris',
}).format(new Date('2026-01-15T12:00:00Z'));
```

**Условие прохождения:** разделители, валюта, календарная дата и отображаемое время соответствуют тому, что подразумевает продукт. Включите в проверку переход на летнее время, если он есть в поддерживаемых часовых поясах. API для [чисел](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat) и [дат](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) позволяют задавать эти параметры по отдельности.

**С General Translation:** [`<Currency>`](/docs/react/reference/components/currency), [`<DateTime>`](/docs/react/reference/components/datetime) и [`<Num>`](/docs/react/reference/components/num) форматируют значения с учётом активной локали. Задавайте валюту и часовой пояс исходя из бизнес-логики: смена языка UI не должна менять сумму к оплате или момент наступления события.

### 5. Проверьте увеличение длины текста на экранах разных размеров

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

**Критерий прохождения:** основной текст остаётся читаемым, а элементами управления можно пользоваться. Ни одно действие не прячется за обрезанным текстом или перекрывающимися элементами. Применяйте усечение осознанно, а не как способ скрыть любое переполнение.

[Псевдолокализация](https://lingui.dev/guides/pseudolocalization) помогает выявить проблемы с макетом и неразмеченными строками ещё до того, как будут готовы переводы. Она дополняет тестирование на реальных языках, но не позволяет оценить качество перевода.

### 6. Тестируйте контент с направлением right-to-left как требование к вёрстке

Если вы поддерживаете арабский, иврит или другой язык с направлением right-to-left, проверьте направление документа, порядок навигации, формы и контент со смешанным направлением, например адреса электронной почты и номера заказов. Используйте логические CSS-свойства там, где вёрстка должна следовать направлению текста, а иконки, указывающие направление, проверяйте по отдельности.

**Критерий прохождения:** вёрстка соответствует нужному направлению чтения, а встроенные значения с направлением left-to-right остаются читаемыми. Указание кода языка не задаёт направление текста — следуйте [рекомендациям W3C по направлению текста в HTML](https://www.w3.org/International/questions/qa-html-dir).

### 7. Проверьте, на каком языке контент получают вспомогательные технологии

Проверьте атрибут `lang` страницы, разметку смены языка внутри контента (если она есть), видимые подписи, доступные имена и альтернативный текст. Пройдите основной пользовательский сценарий с клавиатуры и с экранным диктором. Переведённая подсказка не заменит постоянную подпись поля формы.

**Критерий прохождения:** в документе указан правильный язык, у элементов управления есть осмысленные локализованные имена, а переведённый макет остаётся работоспособным. Подробнее об [объявлении языка](https://www.w3.org/International/questions/qa-html-language-declarations) рассказывает W3C, а о связывании подписей с полями — его [руководство по подписям форм](https://www.w3.org/WAI/tutorials/forms/labels/).

## Проверьте релиз, который получат пользователи

### 8. Проверьте ресурсы рабочей среды и обновления переводов

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

**Условие прохождения:** приложение отдаёт нужные переводы и не зависит от файлов, оставшихся после разработки. Отсутствие ресурсов или сбой генерации приводят к заметной ошибке или явно согласованному резервному варианту, а не к незаметному частичному релизу.

**С General Translation:** запустите [`gt validate`](/docs/cli/reference/commands/validate), чтобы выявить поддерживаемые ошибки встроенного перевода ещё до вызова API, а затем добавьте [шаг инкрементального перевода перед сборкой](/docs/cli/guides/generating-translations). Он повторно использует прежние переводы и переводит только изменённый контент, поэтому новый текст может выйти уже переведённым в том же релизе, где он появился. [Отслеживание веток](/docs/cli/guides/branching) разделяет параллельные ветки разработки. [Автоматизации Locadex](/docs/platform/locadex/guides/configuring-automations) могут обновлять переводы через пул-реквесты. В рамках этой проверки релиза протестируйте настроенный триггер, изменив исходный текст.

При [рабочем процессе с локальным хранением](/docs/react/guides/storing-translations) приложение отдаёт переводы из бандла, не обращаясь к General Translation во время выполнения; обновления поставляются с новой сборкой. При доставке через CDN опубликованные правки могут попасть в приложение без повторного развёртывания — в зависимости от настроек версии переводов и кеширования. Протестируйте этот способ обновления. Храните приватные учётные данные инструментов перевода в среде сборки, а не в браузерных бандлах.

### 9. Проверьте, что общедоступные языковые версии обнаруживаются поисковиками

Для страниц, которые должны попадать в поиск, убедитесь, что у каждой языковой версии есть URL, доступный для сканирования, переведённые заголовки и описания, нужный канонический URL и корректные языковые альтернативные версии. Проверьте взаимные ссылки `hreflang`, включая ссылку на текущую страницу. Если альтернативные версии объявлены в карте сайта, убедитесь, что она отражает те же связи между страницами.

**Критерий прохождения:** каждый общедоступный языковой URL загружает ожидаемый контент, индексируется, если это предусмотрено, и указывает на реально существующие альтернативные версии. Поддерживаемые способы аннотации описаны в [руководстве Google по локализованным страницам](https://developers.google.com/search/docs/specialty/international/localized-versions). Для реализации на Next.js воспользуйтесь [руководством по многоязычному SEO](/kb/multilingual-nextjs-seo).

Отдельные языковые URL можно получить с помощью префиксов пути, языковых поддоменов или доменов стран. Заголовок `Accept-Language` или cookie-файл позволяют выбрать язык посетителя, но сами по себе не создают доступный для сканирования URL для каждой версии. В [руководстве Google по многоязычным сайтам](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) рекомендуется использовать отдельные URL. Панели управления, доступной только после аутентификации, индексируемые языковые URL могут и не понадобиться; выбирайте политику маршрутизации с учётом аудитории продукта.

## Ведите журнал релиза

Фиксируйте сборку, локаль, пользовательский сценарий, браузер или устройство, ожидаемый и фактический результат, а также проверяющего. Для каждой ошибки назначайте ответственного. Отсутствующий перевод на странице оформления заказа или нечитаемая кнопка основного действия — это не то же самое, что мелкие замечания к формулировкам, поэтому относитесь к ним по-разному. Любой допустимый резервный вариант нужно явно задокументировать.

Для быстрой первичной проверки публичного сайта воспользуйтесь бесплатным инструментом [Report Card](https://generaltranslation.com/report-card) от General Translation — он оценивает качество локализации. Однако ему недоступны сценарии, требующие аутентификации, и состояния ошибок, поэтому дополняйте его описанными выше проверками сценариев.

## Часто задаваемые вопросы

### Как тестировать многоязычное приложение?

Проходите полные пользовательские сценарии в каждой поддерживаемой локали на сборке для рабочей среды, включая состояния ошибок, электронные письма и уведомления. Проверяйте формы множественного числа, переменные, валюты, часовые пояса, вёрстку, текст с направлением right-to-left и доступность. Для каждой проверки фиксируйте критерий её успешного прохождения.

### Какую ошибку локализации чаще всего упускают?

Непереведённые сценарии сбоев. Сообщения об ошибках, валидация форм, пустые состояния и транзакционные письма часто остаются на языке-источнике, даже когда основные экраны уже переведены. Обязательно проверьте их отдельно в рамках проверки 1.

### Что такое псевдолокализация?

Псевдолокализация заменяет исходный текст более длинным текстом-подсказкой с диакритическими знаками, чтобы ещё до появления настоящих переводов выявить выход текста за границы макета и неразмеченные строки. Тестирования на реальных языках она не заменяет. См. [руководство Lingui по псевдолокализации](https://lingui.dev/guides/pseudolocalization).

### Нужны ли многоязычным страницам отдельные URL для SEO?

Да, если страницы должны индексироваться. Google рекомендует использовать [отдельный URL для каждой языковой версии](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) и связывать версии с помощью `hreflang`. Одного лишь cookie-файла или заголовка `Accept-Language` недостаточно: так не создаются версии, доступные для сканирования. Подробнее о Next.js см. [SEO для многоязычных сайтов на Next.js](/kb/multilingual-nextjs-seo).

## Related questions

- [Какая библиотека интернационализации лучше всего подходит для приложения React?](https://generaltranslation.com/ru/kb/best-react-i18n-library.mdx): Четыре основные библиотеки интернационализации для React — это gt-react от General Translation, react-i18next, Lingui и React Intl. Все четыре выполняют рендеринг и форматирование переводов, но только gt-react ещё и генерирует их — на основе текста, написанного прямо в JSX. Выбирайте react-i18next, если хотите сохранить каталоги и плагины i18next, Lingui — если нужно извлечение текста в скомпилированные каталоги, а React Intl — если вам нужны FormatJS и ICU MessageFormat.
- [Можно ли реализовать i18n без файлов перевода?](https://generaltranslation.com/ru/kb/i18n-without-translation-files.mdx): Да. С gt-react или gt-next контент остаётся встроенным прямо в ваши компоненты внутри компонента `<T>`, а переводы генерируются во время сборки, поэтому не нужно писать ключи и JSON-файлы для каждой локали и следить за их синхронизацией.
- [Как работать с формами множественного числа в React?](https://generaltranslation.com/ru/kb/how-to-handle-plurals-in-react.mdx): Не зашивайте логику выбора формы множественного числа в код с помощью проверок вроде n === 1. Для приложений только на английском хватит небольшой вспомогательной функции, но многоязычным приложениям нужны locale-aware правила множественного числа. С ними для любого языка справляется i18n-компонент, например `<Plural>` из gt-react или gt-next.
- [Как настроить SEO для многоязычного приложения Next.js?](https://generaltranslation.com/ru/kb/multilingual-nextjs-seo.mdx): Выделите каждому языку собственный URL, задайте атрибут lang у тега html, укажите для каждой страницы канонический URL, ведущий на неё саму, добавьте альтернативные версии hreflang для всех языков, переведите заголовки и описания и перечислите все языковые версии в карте сайта.

## Previous and next questions

- Previous question: [Почему стоит выбрать General Translation вместо TMS (Smartling, Lokalise, Phrase, Crowdin или Transifex)?](https://generaltranslation.com/ru/kb/general-translation-vs-tms.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ru/kb/sitemap.md) for every article.