Использование файлов локализации (строки)

Чтобы загрузить файлы в Strings, выполните следующие шаги:

С любой страницы проекта выберите Загрузки в меню Еще, чтобы получить доступ к архиву загрузок.

Архив загрузок содержит все исторические загрузки во всех возможных статусах. Нажмите на выпадающее меню Все статусы, чтобы отфильтровать загрузки по статусу (Успех, Неудача и/или В процессе). Чтобы найти конкретную загрузку, используйте поле поиска вверху, чтобы искать по имени.

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

Опции скачивания представлены при скачивании файла в окне Скачать с вкладками для Общие, Расширенные и Кодировка.

Выбор различных форматов файла предоставляет различные опции. Для получения дополнительной информации обратитесь к соответствующей статье о конкретном формате файла.

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

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

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

Хранение отдельных файлов

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

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

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

Пример конфигурации CLI

Если работать с CLI или подключать проект к хранилищу (например, GitHub, GitLab или Bitbucket), настройте файл конфигурации для управления загрузками и скачиваниями.

В примере проект имеет несколько семантически названных файлов перевода для исходного языкового стандарта. Например: accounts.en.yml, emails.en.yml и т.д. Эти семантические имена управляются через теги.

Настройте .phrase.yml, чтобы отразить организацию файлов в проекте локализации и связать их с тегами в проекте Strings, включая заполнитель тега в пути к файлу:

фраза:
  access_token: "3d7e6598d955bfcab104c45c40af1b9459df5692ac4c28a17793"
  project_id: "23485c9c5dfb15d85b32d9c5f3d2hl54"
  file_format: yml
  push:
    sources:
      - файл: ./path/to/locales/<tag>.en.yml
        параметры:
          locale_id: "abcd1234cdef1234abcd1234cdef1234"
  pull:
    targets:
      # аккаунты
      - файл: ./path/to/locales/accounts.<locale_name>.yml
        параметры:
          теги: аккаунты
      # электронные почты
      - файл: ./path/to/locales/emails.<locale_name>.yml
        параметры:
          теги: электронные почты

Параметр теги также может использоваться в разделе push вместо использования заполнителя <tag>.

Конфигурация создает ключи с тегами на основе файла, из которого они пришли, при выполнении push или инициировании синхронизации из хранилища. При выполнении pull или инициировании экспорта в хранилище ключи группируются в файлы на основе их тегов.

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

Требуется дальнейшее различие, если:

Локализация статического продукта

Если продукт полностью разработан и редко обновляется, отдельная версия продукта может существовать в рамках проекта.

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

Если продукт постоянно обновляется новым контентом (ключами), применение этих обновлений к нескольким проектам и поддержание их синхронизированными является сложной задачей. Используйте специализированные языки в рамках проекта для их поддержки.

Коды языков, соответствующие стандарту ISO (например, en-US), не обязательно должны быть уникальными, поэтому можно создавать несколько версий одного и того же языка в рамках проекта. Различайте регионы, клиентов или аудитории, используя уникальное название языка.

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

Настройте параллельные процессы локализации с задачами и рабочими процессами проверки в рамках одного проекта. Эта гибкость также распространяется на загрузку и скачивание языковых файлов или автоматизированные процессы через API.