Загрузка и выгрузка файлов локализации (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:
      - file: ./path/to/locales/<тег>.en.yml
        params:
          locale_id: "abcd1234cdef1234abcd1234cdef1234"
  pull:
    targets:
      # учетные записи
      - file: ./path/to/locales/accounts.<имя_языковой стандарт>.yml
        params:
          tags: учетные записи
      # электронные письма
      - file: ./path/to/locales/emails.<имя_языковой стандарт>.yml
        params:
          tags: электронные письма

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

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

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

Дополнительное различие требуется, если:

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

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

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

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

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

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

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