Using Localization Files (Strings)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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