Рефакторинг файлов Ruby on Rails i18n YAML с использованием словарей
Этотвопрос StackOverflow дал мне пищу для размышлений о том, что является хорошей структурой для файлов Rails i18n, поэтому я решил поделиться другой структурой для рефакторинга файлов 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
Я вижу значительное повторение и контекст таких слов, как «Электронная почта» и «Пароль» недвусмысленны и имеют одинаковое значение в соответствующих представлениях. Было бы немного неприятно идти и менять их все, если я решу изменить «Электронная почта» на «Электронная почта», поэтому я хотел бы реорганизовать строки, чтобы ссылаться на какой-то словарь.Итак, как насчет добавления словарного хэша в начало файла с некоторыми якорями &вроде этого:
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
Вы все еще можете продолжать использовать статические строки (например, "User" выше), но всякий раз более одного экземпляра одного и того же слова/фразы в ваших представлениях, вы можете реорганизовать его в словарь. Если словарный перевод ключа на базовом языке не имеет смысла для целевого языка, просто замените указанное значение на целевом языке на статическую строку или добавьте его в качестве дополнительной записи в словарь целевого языка. Я уверен, что словарь каждого языка может быть реорганизован в другой файл, если он станет слишком большим и громоздким (при условии, что он затем повторно импортируется в верхнюю часть файла перевода, чтобы ссылки работали).
Этот способ структурирования файлов i18n yaml, по-видимому, хорошо работает с некоторыми локальными тестовыми приложениями, в которых я его пробовал. Я надеюсь, что замечательное приложение Localeappобеспечит поддержку такого рода привязки/ссылки в будущем. Но в любом случае, все эти разговоры о словарях не могут быть оригинальной идеей, так что есть ли другие проблемы с якорными ссылками в YAML или, может быть, просто со всей концепцией «словарь» в целом? Или просто лучше просто полностью вырвать бэкэнд по умолчанию и заменить его Redisили чем-то еще, если у вас есть потребности, выходящие за рамки соглашений Rails по умолчанию i18n?
Изменить:
Я хотел попытаться рассмотреть пример рабочего процесса tigrish, упомянутый в комментарии ниже здесь, а не как еще один комментарий под его ответом.Пожалуйста, извините меня, если мне кажется, что я не понимаю сути дела или я просто наивен:
Пункт 1: у вас есть общий атрибут «имя» для моделей ActiveRecord, и все они просто указывают к общему словарю для имени:
dictionary:
name: &name Name
activerecord:
attributes:
name: *name
user:
name: *name
product:
name: *name
Пункт 2: Необходимо изменить только имя для пользовательской модели. Остальные имена остаются прежними.
Вариант 1: оставьте имена полей модели такими же на бэкэнде и просто измените перевод внешнего интерфейса, на который они указывают.
dictionary:
name: &name Name
full_name: &full_name Full Name
activerecord:
attributes:
name: *name
user:
name: *full_name
product:
name: *name
Вариант 2: Также измените имя поля модели пользователя. Это потребует изменения любых ссылок на этот ключ в коде и миграции change_table/ rename_column.
dictionary:
name: &name Name
full_name: &full_name Full Name
activerecord:
attributes:
name: *name
user:
full_name: *full_name
product:
name: *name
Вариант 3: Если вы хотите быть очень тщательным, реорганизуйте информацию, содержащуюся в «имени», в отдельные поля базы данных/Activemodel, для которых потребуются новые записи словаря и миграция. Вы можете сами решить, как должно отображаться «полное имя»:
dictionary:
name: &name Name
name_prefix: &name_prefix Prefix
first_name: &first_name First
middle_name: &middle_name Middle
last_name: &last_name Last
name_suffix: &name_suffix Suffix
activerecord:
attributes:
name: *name
user:
name_prefix: *name_prefix
first_name: *first_name
middle_name: *middle_name
last_name: *last_name
name_suffix: *name_suffix
product:
name: *name
Пункт 3: Любой человек по какой-либо причине нуждается в изменении перевода, в данном случае по маркетингу. Я буду следовать примеру пункта 2 варианта 1
. Вариант 1 : имена полей модели такие же, просто измените перевод внешнего интерфейса.
dictionary:
name: &name Name
full_name: &full_name Full Name
funky_name: &funky_name Ur Phunky Phresh Naym
activerecord:
attributes:
name: *name
user:
name: *full_name
product:
name: *name
sessions: # Sign up page keys
new:
name: *funky_name
Вариант 2: «Причудливое имя» по какой-то причине также необходимо сохранить в базе данных. Назовем его username, если никто не возражает (или funky_name, если по какой-то причине настаивает маркетинг).
dictionary:
name: &name Name
full_name: &full_name Full Name
funky_name: &funky_name Ur Phunky Phresh Naym
activerecord:
attributes:
name: *name
user:
name: *full_name
username: *funky_name
product:
name: *name
sessions: # Sign up page keys
new:
name: *name
funky_name: *funky_name
Верно, так что я признаю, что плохо представляю, что я делаю, однако я готов быть публично расстрелянным, чтобы понять, почему такой способ работы с i18n в Haml является плохой идеей в Rails. приложение.Трудно читать? Кошмар обслуживания? Действительно ли это считается «взломом формата файла», если я использую (как я думаю) функцию языка?
Еще раз спасибо tigrish за то, что заставил меня все это вытащить.