Как вы структурируете файлы i18n yaml в Rails?

Ответ 1

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

Большинство переводов приложений находятся в представлениях, поэтому мое самое большое пространство имен верхнего уровня обычно views.

Я создаю вспомогательные пространства имен для имени контроллера и имени действия или частичного использования ex:

• views.users.index.title
• views.articles._sidebar.header

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

Вы упоминаете навигацию и кнопки, если они должны быть общими, тогда они принадлежат к пространству имен views.application так же, как и их сопоставления вида:

• views.application._main_nav.links.about_us - ссылка в нашей части навигации основного приложения.
• views.application.buttons.save
• views.application.buttons.create - У меня есть куча этих кнопок, готовых к использованию при необходимости

Flash-сообщения генерируются с помощью контроллера, поэтому их пространство имен верхнего уровня... controllers!:)

Мы применяем ту же логику, что и к представлениям:

• controllers.users.create.flash.success|alert|notice

Опять же, если вы хотите предоставить общие флэш-сообщения типа "Операция успешная", вы должны написать что-то вроде этого:

• controllers.application.create.flash.notice

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

Теперь осталось только разобраться, переводит ли рельсы в собственное пространство имен, чтобы очистить наш верхний уровень:)

Ответ 2

Я знаю, что ответ уже принят, но этот вопрос дал мне некоторую пищу для размышлений, и я подумал, что поделюсь другой структурой для файлов Rails i18n yml для вашего рассмотрения/критики.

Учитывая, что я хотел бы

• сохранить структуру приложения по умолчанию, чтобы я мог использовать сокращенные "ленивые" запросы, например t('.some_translation') в моих представлениях,
• избегайте как можно большего количества повторений строк, в частности со словами, которые не являются одними и теми же, но также имеют одинаковые контексты/значения,
• нужно только один раз изменить ключ, чтобы он отражался везде, на который он ссылался,

для файла config/locales/en.yml, который выглядит примерно так:

activerecord:
  attributes:
    user:
      email: Email
      name: Name
      password: Password
      password_confirmation: Confirmation
  models:
    user: User
users:
  fields:
    email: Email
    name: Name
    password: Password
    confirmation: Confirmation
sessions:
  new:
    email: Email
    password: Password

Я вижу, что есть значительное повторение, и что контекст таких слов, как "Электронная почта" и "Пароль", недвусмыслен и имеет то же значение в их соответствующих представлениях. Было бы немного досадно, что нужно пойти и изменить их все, если я решит изменить "Email" на "e-mail", поэтому я бы хотел реорганизовать строки для ссылки на какой-то словарь. Итак, как насчет добавления хеш-словаря в верхнюю часть файла с помощью некоторых привязанных &:

dictionary:
  email: &email Email
  name: &name Name
  password: &password Password
  confirmation: &confirmation Confirmation

activerecord:
  attributes:
    user:
      email: *email
      name: *name
      password: *password
      password_confirmation: *confirmation
  models:
    user: User
users:
  fields:  
    email: *email
    name: *name
    password: *password
    confirmation: *confirmation
sessions:
  new:
    email: *email
    password: *password

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

Этот способ структурирования файлов i18n yaml, похоже, хорошо работал с некоторыми локальными тестовыми приложениями, в которых я его пробовал. Я надеюсь, что замечательный Localeapp обеспечит поддержку такого типа привязки/ссылки в будущем. Но, в любом случае, все эти словарные разговоры не могут быть оригинальной идеей, так же есть ли другие проблемы с привязкой привязки в YAML или, может быть, просто с общей концепцией "словаря" вообще? Или просто лучше просто полностью удалить бэкэнд по умолчанию и заменить его на Redis или что-то еще?

Ответ 3

На ваш вопрос ответить непросто, и в этой теме мало материала. Я нашел лучшие ресурсы:

• Rails Styleguide, раздел Интернационализация
• В I18n wiki есть много ресурсов, но я не нашел там тех, кто отвечает на ваши вопросы.

Итак, я попробую прямо здесь:

• Навигация

  Я думаю, вы имеете в виду здесь элементы навигации, такие как панировочные сухари, вкладки,... Вы должны определить для них представления и придерживаться правила для перемещения всех элементов вида в отдельных файлах в каталоге views (см. Стиль для правила).

• Текст кнопки (сохранить изменения, создать учетную запись и т.д.)

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

• Сообщения об ошибках со вспышки контроллера

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

• Как добавить многословные клавиши. Я использую пробел или символ подчеркивания? Для exmaple, t ( ". Update button" )) или t ( ". Update_button" )

  Я бы предпочел использовать .update_button, а не .update button, потому что он делает более явным, что это один ключ.

Ответ 4

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

en:
  controllers:
    users:
      show:
        welcome_flash: "Welcome back!"
  mailers:
    users_mailer:
      welcome_email:
        subject: "Good of you to join us"
  views:
    users:
      show:
        notice: "Oh no!

Но использование опрятных пространств имен нарушает ленивую функцию поиска в Rails. Если вы используете ленивый поиск, Rails автоматически введет пространство имен для вас, и оно не будет содержать созданные вами пространства имен верхнего уровня (views, controllers и т.д.).

Например, область t('.welcome_flash') разрешается до en.users.show. Что воняет, потому что пользователи четко не определены. Что это? Контроллер? Вид? Что-то еще?

Чтобы решить эту проблему я создал gem I18nLazyLookup. Это позволяет вам использовать ленивый поиск со своими собственными пространствами имен.

Вместо использования t вы можете использовать t_scoped('welcome_flash'), и это автоматически изменит область действия на en.controllers.users.show. Он также работает для просмотров и почтовых рассылок, и вы можете настроить пространство имен так, как вам нравится.

Ответ 5

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

Я бы рекомендовал использовать localeapp, который генерирует один файл yaml.
Но позволяет вам легко видеть и управлять своими переводами в веб-интерфейсе.
И для создания дополнительного доступа к переводчикам.

Ответ 6

Спустя несколько лет после битвы, но вот (несколько полностью) ответ.

Для начала мне не нравится стандартный стиль t('.xxx') с пространством имен по умолчанию, основанным на структуре файла. Мне также не очень нравится классификация переводов в зависимости от структуры DOM. Хотя это хороший подход для очень структурированных переводов, он часто повторяется и не очень интуитивно понятен.

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

поэтому мой файл перевода структурирован таким образом

fr:
  theme1:
    theme11:
      translationxxx: blabla
  theme2:
    translationyyy: blabla

В зависимости от потребностей "темы" могут быть моделью, более абстрактным контекстом и т.д., что является наиболее интуитивным для переводчиков.

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

• Я нажимаю/поменяю рамки трансляции в стеке в своих представлениях, вызывая t_scope([new_scope] и pop_t
• Я переопределяю помощника t для использования последней области стека

Код для методов обзора перевода доступен в который отвечает