# General Translation Knowledge Base: Чек-лист тестирования локализации для многоязычных приложений URL: https://generaltranslation.com/ru/kb/multilingual-app-launch-checklist.mdx Docs index: https://generaltranslation.com/llms.txt Description: Проверьте девять аспектов в каждой поддерживаемой локали на сборке для рабочей среды: пользовательские сценарии целиком, включая состояния ошибок и письма; переключение языка; формы множественного числа; валюту и часовые пояса; увеличение длины текста; вёрстку для языков right-to-left; доступность; доставку переводов; индексируемые языковые URL. Задайте для каждой проверки явный критерий успешного прохождения. Category: Интернационализация Last updated: 2026-10-16 Authors: Jackie Chen Published: 2026-10-16 Переведённая главная страница может выглядеть готовой, а оформление заказа, ошибки валидации или сброс пароля при этом по-прежнему отображаются на языке-источнике. Начните со сценариев, которые пользователь должен пройти до конца, и тестируйте их в сборке для рабочей среды. Перед запуском многоязычного веб-приложения проверьте эти девять аспектов в каждой поддерживаемой локали: 1. **Сценарии переведены целиком**, включая состояния загрузки, пустые состояния и ошибки, письма и уведомления. 2. **Язык выбирается единообразно** при первом посещении, после переключения и при повторных визитах. 3. **Переменные и формы множественного числа корректны** для каждой категории множественного числа, используемой в ваших языках. 4. **Валюта и часовой пояс заданы явно** и независимо от языка UI. 5. **Вёрстка не ломается при увеличении длины текста** на узких экранах и при масштабировании в браузере. 6. **Для языков right-to-left** заданы правильное направление письма и вёрстка, а текст со смешанным направлением отображается корректно. 7. **Вспомогательные технологии получают правильный язык**, подписи и доступные имена. 8. **Сборка для рабочей среды содержит все переводы**, а новые тексты переводятся до релиза. 9. **У публичных страниц есть индексируемые языковые URL** с переведёнными метаданными и `hreflang`. Проверяйте контент в каждой поддерживаемой локали, а вёрстку и взаимодействие — на типичных устройствах и в популярных браузерах. Проверка 9 нужна только для публичных страниц, которые должны индексироваться. ## Video The video is narrated in English, with English captions. [What should I check before launching a multilingual app?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-multilingual-app-launch-checklist.mp4) (33 с) Before launching a multilingual app, test nine things in every supported locale: complete user journeys including errors, language detection and switching, variables and plurals, currency and time zones, text expansion, right-to-left layout, accessibility, production translation delivery, and crawlable language URLs. With General Translation, run gt validate, then `npx gt translate` before the build so new copy ships translated. ## Проверка отображения контента и переключения языка ### 1. Переводите весь пользовательский сценарий, включая состояния ошибок Выберите критически важный сценарий, например создание аккаунта или оформление покупки. Пройдите через все его состояния: загрузку, пустой экран, успешное завершение и ошибку. Проверьте кнопки, диалоговые окна, валидацию форм, подсказки, метки для специальных возможностей, а также все письма и уведомления, которые отправляются в рамках сценария. Используйте [проверки на жёстко заданные строки](/kb/find-hardcoded-strings), чтобы выявить литералы на исходном языке ещё до ручной проверки. **Критерий прохождения:** в каждой области взаимодействия с пользователем используется проверенный контент на целевом языке, кроме намеренных исключений вроде названия продукта. Нигде не отображаются необработанные ключи, маркеры отсутствующих сообщений или необъяснимые резервные варианты на исходном языке. В General Translation рецензенты исправляют формулировки в [Редакторе переводов на панели управления](/docs/platform/dashboard/guides/reviewing-translations). Ещё до генерации новых переводов сделайте [термины Glossary и пользовательские промпты](/docs/platform/dashboard/guides/defining-context-for-translations) общими для проектов приложения и писем. Изменения контекста влияют только на новые переводы; существующие формулировки проверяйте отдельно и не рассчитывайте, что они тоже изменились. ### 2. Проверьте первое посещение, переключение языка и повторные визиты Проверьте поведение в чистом браузере, при явном выборе языка, после перезагрузки страницы, при переходе по глубокой ссылке и при неподдерживаемом языке браузера. Если приложение сохраняет языковые предпочтения в аккаунте, проверьте также вход в систему и выход из неё. Зафиксируйте, какая настройка имеет приоритет, если URL, сохранённое предпочтение и язык браузера не совпадают. О сопоставлении предпочтений рассказывается в [руководстве по определению языка](/kb/detect-user-language), а о явном выборе языка и доступной навигации — в [руководстве по переключателю языка](/kb/language-switcher). **Критерий прохождения:** приложение последовательно следует этим правилам, а пользователь может отменить нежелательный выбор языка. Для приложений с отрисовкой на сервере проверяйте как исходный ответ сервера, так и страницу после гидратации. Идентификаторы локалей соответствуют BCP 47: `es-MX` и `es-AR` могут быть отдельными целевыми локалями для мексиканского и аргентинского испанского. Протестируйте каждую региональную локаль, которую вы выпускаете. Переключатель на основе cookie-файлов и маршруты с префиксом локали решают разные задачи; проверьте, как URL на самом деле ведут себя в приложении. ### 3. Проверьте переменные и категории множественного числа Проверьте разные количества, включая 0, 1, 2 и большие значения, затем добавьте тестовые случаи для категорий множественного числа ваших целевых языков. Используйте имена со знаками препинания, длинные названия аккаунтов и предложения, в которых переменные после перевода могут оказаться в другом порядке. Не собирайте предложение из отдельно переведённых фрагментов. В React-библиотеках GT компонент [``](/docs/react/reference/components/plural) выбирает формы множественного числа в зависимости от локали, [``](/docs/react/reference/components/branch) хранит условные варианты внутри единицы перевода, а [``](/docs/react/reference/components/var) подставляет динамические значения локально. Проверяйте каждый вариант, а не только предложение по умолчанию. Пользовательские значения внутри [``](/docs/react/reference/components/var) можно не отправлять в API перевода. **Условие прохождения:** значения не искажены, предложение читается правильно, и для каждой обязательной формы множественного числа есть пригодный текст. В [правилах множественного числа](https://cldr.unicode.org/index/cldr-spec/plural-rules) от Unicode объясняется, почему одной английской пары «единственное/множественное число» для проверки недостаточно. Для сообщений из каталога также проверьте ветви в ваших [ICU-сообщениях](/kb/icu-message-format). (Паттерн на основе компонентов описан в статье [Как обрабатывать формы множественного числа в 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) позволяют задавать эти параметры по отдельности. Смена языка UI не должна менять сумму к оплате или момент наступления события. Компоненты GT [``](/docs/react/reference/components/currency) и [``](/docs/react/reference/components/datetime) используют locale-aware форматирование с явно заданными параметрами валюты и часового пояса; проверяйте эти настройки так же, как и приведённые выше вызовы `Intl`. ### 5. Проверьте увеличение длины текста на экранах разных размеров Откройте переведённые экраны в узких окнах просмотра и с увеличенным масштабом браузера. Проверьте навигацию, кнопки, таблицы, диалоговые окна и сообщения валидации. Используйте длинные переведённые строки и длинные значения, вводимые пользователем: короткий заголовок нагружает вёрстку совсем не так, как полный адрес. **Критерий прохождения:** основной текст остаётся читаемым, а элементами управления можно пользоваться. Ни одно действие не прячется за обрезанным текстом или перекрывающимися элементами. Применяйте усечение осознанно, а не как способ скрыть любое переполнение. [Псевдолокализация](/kb/pseudo-localization) помогает выявить проблемы с вёрсткой и неразмеченными строками ещё до того, как будут готовы переводы. Она дополняет тестирование на реальных языках, но не позволяет оценить качество перевода. Один из вариантов реализации описан в [руководстве Lingui](https://lingui.dev/guides/pseudolocalization). ### 6. Тестируйте контент с направлением right-to-left как требование к вёрстке Если вы поддерживаете арабский, иврит или другой язык с направлением right-to-left, проверьте направление документа, порядок навигации, формы и контент со смешанным направлением, например адреса электронной почты и номера заказов. Используйте логические CSS-свойства там, где вёрстка должна следовать направлению текста, а иконки, указывающие направление, проверяйте по отдельности. Отступы, иконки и значения со смешанным направлением разобраны в [руководстве по CSS для RTL](/kb/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. Проверьте ресурсы рабочей среды и обновления переводов Соберите приложение из чистой копии репозитория по процессу релиза, затем запустите эту сборку с каждой поддерживаемой локалью. Убедитесь, что ресурсы переводов на месте и успешно загружаются. Измените исходное сообщение в тестовой ветке и проверьте, что конвейер перевода обнаруживает это изменение до следующего релиза. **Условие прохождения:** приложение отдаёт нужные переводы и не зависит от файлов, оставшихся после разработки. Отсутствие ресурсов или сбой генерации приводят к заметной ошибке или явно согласованному резервному варианту, а не к незаметному частичному релизу. Храните учётные данные инструментов перевода в среде сборки, а не в браузерных бандлах. Для GT перед сборкой запустите [`gt validate`](/docs/cli/reference/commands/validate), а затем [`gt translate`](/docs/cli/reference/commands/translate). Сборку можно настроить так, чтобы она прерывалась при сбое перевода. [`gt generate`](/docs/cli/reference/commands/generate) только записывает исходные шаблоны. Если рецензенты правят локальные результаты, используйте [`gt save-local`](/docs/cli/reference/commands/save-local), чтобы эти правки сохранялись при последующих запусках. Протестируйте настроенный способ обновления: [Locadex](/docs/platform/locadex/guides/configuring-automations) должен создать или обновить свой пул-реквест с переводами, когда срабатывает настроенный триггер — push, пул-реквест или ручной запуск. Убедитесь, что отслеживается нужная ветка. При использовании [переводов, включённых в сборку](/docs/react/guides/storing-translations), развёрнутое приложение может отображать поставленные с ним файлы независимо от сервиса GT. При доставке через CDN проверьте, как опубликованные правки применяются с учётом ваших настроек версии и кеширования, включая возможную задержку, прежде чем они дойдут до пользователей. ### 9. Проверьте, что общедоступные языковые версии обнаруживаются поисковиками Для страниц, которые должны попадать в поиск, убедитесь, что у каждой языковой версии есть URL, доступный для сканирования, переведённые заголовки и описания, нужный канонический URL и корректные языковые альтернативные версии. Проверьте взаимные [ссылки hreflang](/kb/what-is-hreflang), включая ссылку на текущую страницу. Если альтернативные версии объявлены в карте сайта, убедитесь, что она отражает те же связи между страницами. **Критерий прохождения:** каждый общедоступный языковой URL загружает ожидаемый контент, индексируется, если это предусмотрено, и указывает на реально существующие альтернативные версии. Поддерживаемые способы аннотации описаны в [руководстве Google по локализованным страницам](https://developers.google.com/search/docs/specialty/international/localized-versions). Для реализации на Next.js воспользуйтесь [руководством по многоязычному SEO](/kb/multilingual-nextjs-seo). Отдельные языковые URL можно получить с помощью префиксов пути, языковых поддоменов или доменов стран; сравнение этих вариантов приведено в [руководстве по структуре URL](/kb/multilingual-url-structure). Заголовок `Accept-Language` или cookie-файл позволяют выбрать язык посетителя, но сами по себе не создают доступный для сканирования URL для каждой версии. (См. [языковые перенаправления и SEO](/kb/locale-routing-seo)). В [руководстве Google по многоязычным сайтам](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) рекомендуется использовать отдельные URL. Панели управления, доступной только после аутентификации, индексируемые языковые URL могут и не понадобиться; выбирайте политику маршрутизации с учётом аудитории продукта. Бесплатный инструмент [Report Card](https://generaltranslation.com/report-card) от GT поможет провести первичную проверку локализации общедоступного сайта, однако он не может проверить сценарии, требующие аутентификации, или намеренно воспроизвести сбойные состояния вашего приложения. ## Ведите журнал релиза Фиксируйте сборку, локаль, пользовательский сценарий, браузер или устройство, ожидаемый и фактический результат, а также проверяющего. Для каждой ошибки назначайте ответственного. Отсутствующий перевод на странице оформления заказа или нечитаемая кнопка основного действия — это не то же самое, что мелкие замечания к формулировкам, поэтому относитесь к ним по-разному. Любой допустимый резервный вариант нужно явно задокументировать. Заполненный журнал может выглядеть так: | Сборка | Локаль | Проверка | Устройство | Ожидаемый результат | Фактический результат | Итог | | ---------------- | ------ | ---------------------------------------- | --------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------ | | 4.12.0 (a1b2c3d) | `de` | 1. Карта отклонена при оформлении заказа | Chrome, десктоп | Сообщение об ошибке на немецком с возможностью повторить попытку | Сообщение об ошибке на немецком, подпись кнопки обрезается при ширине 320px | Не пройдено: блокирует релиз, ответственный назначен | | 4.12.0 (a1b2c3d) | `pl` | 3. Корзина с 2, 5 и 22 товарами | Safari, iPhone | Польские формы few и many | Для 5 товаров показана форма `few` | Не пройдено: исправить ключи форм множественного числа | | 4.12.0 (a1b2c3d) | `ar` | 6. Настройки аккаунта | Chrome, Android | Зеркальная вёрстка, стрелка «назад» направлена вправо | Как ожидалось | Пройдено | ## Related questions - [Как найти захардкоженные строки, которые не переведены?](https://generaltranslation.com/ru/kb/find-hardcoded-strings.mdx): Запустите в CI линтер, который находит строковые литералы, видимые пользователю, — например, правило no-literal-string из eslint-plugin-i18next для JSX, проверку HardcodedText в Android Lint или линтер HardCodedString из erb_lint для Rails. Затем пройдитесь по приложению в псевдолокали, чтобы найти текст, который статические проверки отследить не могут. - [Переключатель языка: лучшие практики UX, SEO и доступности](https://generaltranslation.com/ru/kb/language-switcher.mdx): Называйте каждый язык на нём самом, например Deutsch или 日本語, и не используйте флаги — они обозначают страны. Каждый вариант должен вести на ту же страницу на выбранном языке через индексируемую ссылку. Запоминайте выбор в cookie-файле и никогда не перенаправляйте автоматически с локализованного URL. - [Что такое псевдолокализация?](https://generaltranslation.com/ru/kb/pseudo-localization.mdx): Псевдолокализация — это тест, при котором исходный текст заменяется изменённой версией с диакритикой, удлинённой примерно на 40% и заключённой в скобки. Так жёстко закодированные строки, усечение, проблемы со шрифтами и склеенные из фрагментов предложения выявляются ещё до появления перевода. В Android для этого предусмотрены псевдолокали en-XA и ar-XB. - [Как поддержать RTL-языки (right-to-left) в CSS?](https://generaltranslation.com/ru/kb/right-to-left-css.mdx): Укажите dir="rtl" и lang на элементе html — сам по себе lang не меняет направление письма, — а затем замените физические CSS-свойства вроде margin-left логическими, например margin-inline-start. Flex-строки, grid-столбцы и выравнивание текста по умолчанию зеркалятся автоматически, а translateX(), left и right — нет. - [Как настроить SEO для многоязычного приложения Next.js?](https://generaltranslation.com/ru/kb/multilingual-nextjs-seo.mdx): Выделите каждому языку собственный URL с префиксом, например /en/about и /es/about, а затем укажите для каждого опубликованного языка html lang, канонический URL, ссылающийся на саму страницу, альтернативные версии hreflang с x-default, переведённые заголовок и описание, а также запись в карте сайта. Неопубликованные версии пометьте noindex. gt-next от General Translation направляет каждый язык на собственный URL и переводит заголовки с помощью getGT. ## Previous and next questions - Previous question: [Писать собственную i18n или использовать General Translation?](https://generaltranslation.com/ru/kb/general-translation-vs-in-house-i18n.mdx) - Next question: [Достаточно ли точен ИИ-перевод для приложения в рабочей среде?](https://generaltranslation.com/ru/kb/is-ai-translation-accurate.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ru/kb/sitemap.md) for every article.