Комментарии 29
не совсем верно… гем может не обновиться с версии 1.2 до 1.3.1… нужно еще поставить гем rubygems-update, запустить update_rubygems и только потом уже обновить рельсы.
вот здесь про это написано подробнее
Прикольно, надо обновлятся =) i18n есть большой вери гуд!
Вот поддержка Ruby 1.9 — это интересно. Ибо в 1.8 он весьма нетороплив, а с 1.9 — производительность на объектах как у Питона становится, ноздря в ноздрю: balancer.ru/tech/forum/2008/08/t63003--Proizvoditel~nost~-yazykov.Ob~ektnyj-Fib.html
Ну Release Notes уже давно висят у них там
Я больше всего рад миграциям в транзакциях — уж очень болезненая тема была.
Хотя радоваться я радуюсь — а на сервере мускл, который не поддерживает это чудо.
Я больше всего рад миграциям в транзакциях — уж очень болезненая тема была.
Хотя радоваться я радуюсь — а на сервере мускл, который не поддерживает это чудо.
>Хотя радоваться я радуюсь — а на сервере мускл, который не поддерживает это чудо.
dev.mysql.com/doc/refman/5.0/en/sql-syntax-transactions.html?
dev.mysql.com/doc/refman/5.0/en/sql-syntax-transactions.html?
Вот рубеоиды и рельсоведы, ответьте мне пожалуйста на один принципиальный вопрос:
Я немного знаком с фреймворком и языком, но не в курсе, как это работает внутри. Рельсы это фреймворк одного прогона (при каждом запросе необходимые классы создаются заново) или все-таки все работает как контейнер сервлетов? Проще говоря, возможно ли держать в памяти долгоживующие объекты, не в сессии и не в базе и обращаться к этим объектам в течении долгого времени из нескольких контроллеров? Я — человек, избалованный явой. Если нет, то и ладно, а если да — то это было бы очень круто
Я немного знаком с фреймворком и языком, но не в курсе, как это работает внутри. Рельсы это фреймворк одного прогона (при каждом запросе необходимые классы создаются заново) или все-таки все работает как контейнер сервлетов? Проще говоря, возможно ли держать в памяти долгоживующие объекты, не в сессии и не в базе и обращаться к этим объектам в течении долгого времени из нескольких контроллеров? Я — человек, избалованный явой. Если нет, то и ладно, а если да — то это было бы очень круто
gem installupdate rails
не-не-не, разные вещи. Ваша команда проапдейтит существующую копию рельс, а инсталл поставит отдельно, что довольно удобно.
Например, сегодня обновился, все свиду хорошо, а вот плагин prawnto не работает. Пришлось пока попридержать коней, легко переключившись. А после апдейта пришлось бы все сносить. =)
Например, сегодня обновился, все свиду хорошо, а вот плагин prawnto не работает. Пришлось пока попридержать коней, легко переключившись. А после апдейта пришлось бы все сносить. =)
По поводу i18n в Rails. Если у меня сайт должен поддерживать и русский и француский, то мне надо ставить 2 гема (russian и french)? Backend выбирается автоматом, или надо вручную ставить или один или другой? А если строка в русском переводе не найдена, но мы знаем что пользователь знает француский, то как произойдёт смена backend?
Нет, не нужно — russian устанавливает кастомный бекенд для пары вещей которых нет в I18n по умолчанию, французский можно использовать как есть. Для фолбека по языкам нужно обрабатывать исключения I18n, так как единственно правильного рецепта нет.
А как мы можем использовать специфичные для русского языка фичи, если потом придёт франкоговорящий пользователь. Конечно можно тогда вставить проверку, какой язык сейчас используется. Но тогда для добавления нового языка, надо не править простой файл, а менять код, что плохо.
Посмотрите ридми, правда :-)
В Russian используется свой бекенд, который полностью совместим со стандартным — французский будет работать полностью, а другие языки опционально получают правила плюрализации прямо в таблице переводов и два вида названий месяцев.
Можно глянуть на github.com/svenfuchs/rails-i18n, там репозиторий всех языков, работающих с I18n из коробки.
В Russian используется свой бекенд, который полностью совместим со стандартным — французский будет работать полностью, а другие языки опционально получают правила плюрализации прямо в таблице переводов и два вида названий месяцев.
Можно глянуть на github.com/svenfuchs/rails-i18n, там репозиторий всех языков, работающих с I18n из коробки.
Понятно, что Russian сохраняет обратную совместимость. Но получается, что для много языкового сайта, преимущества от Russian только в небольшом патче к логике стандартных функций. Я сторонник, что такой функционал должен быть внесён в основной код. Как, например, в моей библиотеке: патч для русификации класса Locale.
Я все-таки процитирую README, раз так лень его читать :-)
Цель проекта—построить полноценную среду для русской локализации Ruby и Rails проектов, при этом используя минимально возможное количество хаков, сохраняя при этом поддержку локализации приложения на другие языки, а также *форсировать включение в основную ветку I18n и Rails всех функций локализации, необходимых для работы с русским языком*. (см выделение)
Rails будет работать с I18n gem независимо от того что придумает кто-то еще, цель проекта была в объединении всех решений для локализации. Получилось, на мой взгляд, замечательно.
Цель проекта—построить полноценную среду для русской локализации Ruby и Rails проектов, при этом используя минимально возможное количество хаков, сохраняя при этом поддержку локализации приложения на другие языки, а также *форсировать включение в основную ветку I18n и Rails всех функций локализации, необходимых для работы с русским языком*. (см выделение)
Rails будет работать с I18n gem независимо от того что придумает кто-то еще, цель проекта была в объединении всех решений для локализации. Получилось, на мой взгляд, замечательно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rails 2.2