| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Ruby On Rails > Интернализация моделей |
| Автор: maep 29.3.2010, 04:47 |
| Коллеги, подскажите: как лучше действовать в плане интернализации данных в Раилс? Есть задача сделать многоязычный сайт, и не только в плане интерфейса, но и в плане данных. Лично я вижу три основных подхода: добавлять в каждую модель поля типа text_en, text_fr ... и т.п., т.е. на каждое переводимое поле заводить их столько, сколько есть языков. Это очень коряво: разрастается количество полей, жестко зашит состав языков. Вариант 2. Для каждой сущности заводится таблица типа entity_text [text:string, name:string, lang_id:integer] или что-то подобное. Вариант 3. Все переводы хранить в одном большом словаре, а в таблице сущности иметь ссылки на туда. Поиск плагинов и гемов не увенчался успехом. Больше всего ссылок на acts_as_translatable, но репозиторий походу мертв, и вообще старая штука. Всякие другие - вообще непонятно что. А как вы решаете такую задачу,чтоб велосипед не изобретать? Спасибо |
| Автор: shine 29.3.2010, 07:31 |
| http://guides.rubyonrails.org/i18n.html http://github.com/joshmh/globalize2 |
| Автор: source777 29.3.2010, 12:39 |
| Лично мне Globalize не нравится, он довольно не слабо притормаживает обработку запросов. Поэтому для простых случаев я предпочитаю http://github.com/romul/acts_as_multilingual, http://github.com/romul/acts_as_multilingual_example, а пример реального использования этого плагина в действии можно посмотреть на npobit.com |
| Автор: maep 30.3.2010, 05:30 |
| Спасибо, изучу оба варианта |
| Автор: рельсовик 3.4.2010, 10:38 |
| Для локализации нашего приложения мы использовали gettext. Принцип работы: все строки обводятся особым методом (для компактности он называется _, т.е. вместо "hello" будет _("hello"). Это делается везде где нужен перевод - model/view/controller/lib/итп. Затем запускается особый скрипт который генерирует таблицу переводов (ближе всего в варианту №3 пожалуй, но для каждого языка свой файл-словарь, который сопоставляет текст в оригинале с текстом в переводе). Затем эти словари рассылаются переводчикам, которые заполняют нужные поля, и шлют файлы обратно разработчикам. Преимущества gettexta: 1. не нужно убирать текст в оригинале или менять его на замудренные переменные, где не всегда ясно, чем же будет сама строка. В программе будет "основной" язык (для нас это английский), и все строки видны в программе прямым текстом, как и до локализации. Если, допустим, в оригинале строка стала _("the quick brown fox jumped over the lazy dog"), то программер может прикинуть, скажем, примерную длину этой строки в других языках, ее смысл, расположение на странице, итп. А если использовать переменную типа @brown_fox_string, то ответы на эти вопросы не столь очевидны. 2. Файлы-словари легко рассылаются переводчикам, и получаются обратно. Сами переводчики не должны знать ни сущность программы, ни программирование вообще. 3. Нет необходимости синхронизировать все и сразу. Если строка еще не переведена, то она будетп просто отображатся языком оригинала, даже в другом локале. Можно получить перевод на немецкий, и внедрить его, не дожидаясь переводов на французкий, русский, итп. А получив нужный перевод, достаточно лишь заменить файл-словарь, и не нужно ничего менять в программе. Из недостатков gettextа - отсутствие встроенной локализации для картинок и прочего не-текста. Это пришлось дописывать ручками. =) Ну и наше приложение, милости просим посмотреть как внедрен gettext: http://www.billingboss.com/?locale=ru . Для другого языка достаточно сменить locale=fr итп. |