Моё знакомство с Rails изначально было напревленно в определенную и узкоспециализированную область, а именно — интернационализация. И вот, два проекта спустя, позвольте поделиться своим опытом.
Что же представляет из себя перевод сайта? Это разбиение контента на строки, которые помещаются в словари под определенными ключами, а затем извлекаются в соответствии с выбранной локалью. «Нет ничего проще!» — скажете Вы и будете абсолютно правы. Вот только знающие заговорщицки усмехнуться…
В этой статье я опишу несколько простых советов по организации словарей.
На самом деле, эта дилема не представляет особой сложности, но рассмотрим ее подробнее.
Приведу примеры:
Я выбрал для себя вариант .yml, так как он читабельнее, хоть и обладает меньшей функциональностью и чуствителен к отступам. Но, когда в словарях хранится только текст, да еще и в больших объемах, эти недостатки не столь существенны. Но нельзя забывать, что в расширении yaml есть свои зарезервированные слова, такие как YES, NO, ON и так далее (не чуствительны к регистру), и если вам необходимо поместить в словарь ключь yes или no, то здесь есть меленькая хитрость: используйте символ ":" перед именем ключа (en: :yes: «Yes», при это обращение к ключу будет прежним: I18n.t(:yes) или I18n.t('yes')).
Далее в этой статье используется именно второй вариант.
Что я подразумеваю под этим? Когда Вы извлекаете строчки и слова, наполняющие сайт, Вам надо задать им уникальное имя, ключ, по которому они буду доступны объекту I18n и его методу translate(). Все было бы легко, и никакой модели не понадобилось бы, будь на страничке только имена колонок: Имя, Фамилия, Дата рождения и т.д. Но любой уважающий себя сайт содержит как минимум 1000 строчек текста. И, согласитесь, придумывать уникальные имена становиться далеко не просто. В основе предлагаемой мною модели лежит файловая структура Вашего приложения.
Весь текст, который находится на страницах сайта, может выводиться из четырех структурных единиц: контроллер, представление, модель и хэлпер (еще есть вариант вывода из скриптов, но он здесь не рассмотрен). Соответственно, организуем следующие пространства имен в словаре:
Что уже дает нам возможность немного расслабиться и использовать идеентичные ключи в разным структурах.
Здесь все просто: controller.user, model.user, etc. Если это представление, можно использовать имя папки, в которой храниться файл: view.folder_name.
В качестве подпространства, я использую имя файла (если это представление) или имя метода\переменной, включая папку, где они находится: contoller.folder.user.update, model.user.update, view.user.index.
Наконец, мы подобрались к самому интересному моменту — фомрированию ключа. Я использую для это общие понятия: titile, submit, message, error. Не советую Вам вносить какую бы то ни было индивидуальность в ключи, дабы в будущем не вводить в заблуждение себя или других девелоперов. К примеру, у вас есть таблица с заголовками, Вы можете назвать их так: table_header_name, table_header_age. Но спустя некоторое время, текст, хранящийся под этими ключами может поменться, и под name может храниться пол, а под возрастом — профессия. Гораздо удобнее, организовывать нумерацию: table_header_1, table_header_2. Что позволяет менять слова в словаре, не беспокоясь о ключах.
Зачастую, имя ключа формируют тэги, к которым относится переводимый текст, как это видно на примере с таблицей. Таким же образом можно давать имена и ссылкам, лэйблам, хинтам.
Но что же делать, если это просто статический текст? Все просто: выдумайте сами себе тэг :) В моем случае — это message. У message могут быть свои заголовки и параграфы (абзацы).
Еще одна проблема, с которой я столкнулся, это вставки в текст, которые разбивают его на части. Простой и наглядный пример: «Здраствуйте, <cсылка>это</cсылка> моя страница!» Для себя я принял определенную парадигму: если сообщение (текст) делится, то у каждого его элемента будет парядковый номер, что в будущем позволит добавлять и редактировать элементы сообщения, без изменения нумерции предыдущих элементов. Помещаем в словарь это предложение:
Обратите внимание, пробелы в словари не помещаются, а значит в представлении эта строка после перевода будет выглядеть так:
Несомненным плюсом такой организации является последовательность и читабельность, т.е. переводчик поймет предложение целиком, и Вы значительно облегчите ему жизнь. Ссылка в своем ключе содержит слово name, т.к. иногда имеет и другие атрибуты свойства title(hint), confirm, и прочие. Например: message_1_link_1_hint: «Добро поджаловать!».
Не стесняйтесь выносить общие или частоиспользуемые слова в список «глобальных».
Я использую двойные ковычки, при помещении переводов, что имеет несомненный плюс: во многих языках символ ' активно используется. Если быть до конца откровенным, то стоит все знаки заменять их HTML кодами, но если совсем лениво, то можно ограничиться обязательной заменой " :)
Статья получилась объемной, при том что содержала в себе лишь общую информацию. В дальнейшем, я планирую написать статьи об остальных частях словаря: локализация даты-времени, форматов чисел и наборы для некоторых гемов.
Что же представляет из себя перевод сайта? Это разбиение контента на строки, которые помещаются в словари под определенными ключами, а затем извлекаются в соответствии с выбранной локалью. «Нет ничего проще!» — скажете Вы и будете абсолютно правы. Вот только знающие заговорщицки усмехнуться…
В этой статье я опишу несколько простых советов по организации словарей.
Выбор расширения словаря: yaml vs rb
На самом деле, эта дилема не представляет особой сложности, но рассмотрим ее подробнее.
Приведу примеры:
#en.rb
{ :en => { :name => "Name" } }
#en.yml
en: name: "Name"
Я выбрал для себя вариант .yml, так как он читабельнее, хоть и обладает меньшей функциональностью и чуствителен к отступам. Но, когда в словарях хранится только текст, да еще и в больших объемах, эти недостатки не столь существенны. Но нельзя забывать, что в расширении yaml есть свои зарезервированные слова, такие как YES, NO, ON и так далее (не чуствительны к регистру), и если вам необходимо поместить в словарь ключь yes или no, то здесь есть меленькая хитрость: используйте символ ":" перед именем ключа (en: :yes: «Yes», при это обращение к ключу будет прежним: I18n.t(:yes) или I18n.t('yes')).
Далее в этой статье используется именно второй вариант.
Модель организации ключей
Что я подразумеваю под этим? Когда Вы извлекаете строчки и слова, наполняющие сайт, Вам надо задать им уникальное имя, ключ, по которому они буду доступны объекту I18n и его методу translate(). Все было бы легко, и никакой модели не понадобилось бы, будь на страничке только имена колонок: Имя, Фамилия, Дата рождения и т.д. Но любой уважающий себя сайт содержит как минимум 1000 строчек текста. И, согласитесь, придумывать уникальные имена становиться далеко не просто. В основе предлагаемой мною модели лежит файловая структура Вашего приложения.
Основа
Весь текст, который находится на страницах сайта, может выводиться из четырех структурных единиц: контроллер, представление, модель и хэлпер (еще есть вариант вывода из скриптов, но он здесь не рассмотрен). Соответственно, организуем следующие пространства имен в словаре:
en:
controller:
...
model:
...
view:
...
helper:
...
Что уже дает нам возможность немного расслабиться и использовать идеентичные ключи в разным структурах.
Имя структурной единицы
Здесь все просто: controller.user, model.user, etc. Если это представление, можно использовать имя папки, в которой храниться файл: view.folder_name.
Имя файла или имя метода
В качестве подпространства, я использую имя файла (если это представление) или имя метода\переменной, включая папку, где они находится: contoller.folder.user.update, model.user.update, view.user.index.
Формирование ключа
Наконец, мы подобрались к самому интересному моменту — фомрированию ключа. Я использую для это общие понятия: titile, submit, message, error. Не советую Вам вносить какую бы то ни было индивидуальность в ключи, дабы в будущем не вводить в заблуждение себя или других девелоперов. К примеру, у вас есть таблица с заголовками, Вы можете назвать их так: table_header_name, table_header_age. Но спустя некоторое время, текст, хранящийся под этими ключами может поменться, и под name может храниться пол, а под возрастом — профессия. Гораздо удобнее, организовывать нумерацию: table_header_1, table_header_2. Что позволяет менять слова в словаре, не беспокоясь о ключах.
Зачастую, имя ключа формируют тэги, к которым относится переводимый текст, как это видно на примере с таблицей. Таким же образом можно давать имена и ссылкам, лэйблам, хинтам.
Но что же делать, если это просто статический текст? Все просто: выдумайте сами себе тэг :) В моем случае — это message. У message могут быть свои заголовки и параграфы (абзацы).
Еще одна проблема, с которой я столкнулся, это вставки в текст, которые разбивают его на части. Простой и наглядный пример: «Здраствуйте, <cсылка>это</cсылка> моя страница!» Для себя я принял определенную парадигму: если сообщение (текст) делится, то у каждого его элемента будет парядковый номер, что в будущем позволит добавлять и редактировать элементы сообщения, без изменения нумерции предыдущих элементов. Помещаем в словарь это предложение:
en:
view:
view_folder:
index:
message_1_part_1: "Здраствуйте,"
message_1_link_1_name: "это"
message_1_part_2: "моя страница!"
Обратите внимание, пробелы в словари не помещаются, а значит в представлении эта строка после перевода будет выглядеть так:
<%=t 'view.view_folder.index.message_1_part_1' %> <cсылка><%=t 'view.view_folder.index.message_1_link_1_name' %></cсылка> <%=t 'view.view_folder.index.message_1_part_2' %>
Несомненным плюсом такой организации является последовательность и читабельность, т.е. переводчик поймет предложение целиком, и Вы значительно облегчите ему жизнь. Ссылка в своем ключе содержит слово name, т.к. иногда имеет и другие атрибуты свойства title(hint), confirm, и прочие. Например: message_1_link_1_hint: «Добро поджаловать!».
Прочее
Не стесняйтесь выносить общие или частоиспользуемые слова в список «глобальных».
Я использую двойные ковычки, при помещении переводов, что имеет несомненный плюс: во многих языках символ ' активно используется. Если быть до конца откровенным, то стоит все знаки заменять их HTML кодами, но если совсем лениво, то можно ограничиться обязательной заменой " :)
Статья получилась объемной, при том что содержала в себе лишь общую информацию. В дальнейшем, я планирую написать статьи об остальных частях словаря: локализация даты-времени, форматов чисел и наборы для некоторых гемов.