Коллеги, подскажите: как лучше действовать в плане интернализации данных в Раилс? 
Есть задача сделать многоязычный сайт,  и не только в плане интерфейса, но и в плане данных.

Лично я вижу три основных подхода:
добавлять в каждую модель поля типа text_en, text_fr ... и т.п., т.е. на каждое переводимое поле заводить их столько, сколько есть языков.
Это очень коряво: разрастается количество полей,  жестко зашит состав языков.

Вариант 2. Для каждой сущности заводится таблица типа entity_text [text:string, name:string, lang_id:integer] или что-то подобное.

Вариант 3. Все переводы хранить в одном большом словаре, а в таблице сущности иметь ссылки на туда.

Поиск плагинов и гемов не увенчался успехом. Больше всего  ссылок на acts_as_translatable, но репозиторий походу мертв, и вообще старая штука. Всякие другие - вообще непонятно что.

А как вы решаете такую задачу,чтоб велосипед не изобретать?
Спасибо

http://guides.rubyonrails.org/i18n.html
http://github.com/joshmh/globalize2

Лично мне Globalize не нравится, он довольно не слабо притормаживает обработку запросов. Поэтому для простых случаев я предпочитаю acts_as_multilingual, демо-приложение, а пример реального использования этого плагина в действии можно посмотреть на npobit.com

Это сообщение отредактировал(а) source777 - 29.3.2010, 12:41

Спасибо, изучу оба варианта

Для локализации нашего приложения мы использовали 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 итп.