A common task in most of Rails applications is to use internationalization. You have to work with yaml and text files to manage your web application translations. Sometimes, you need your system users to help you translating it to several languages. So, you need a user friendly and easy tool to translate your web application.
In BadrIT we solved this problem and developed Translation Center, A multi-lingual, GUI rich, community based, translation Center for Rails apps. It builds a translation center community with translators and admins from your system users.
If you are already using Heroku on your Mac or Linux with some email like firstname.lastname@example.org and you want change the currently active username on your Mac to other like email@example.com, you should do the following:Read More
While trying to install the RedCloth Gem on my windows machine, I got the following error message:
"Installing RedCloth (4.2.2) D:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/defaults/operating_system.rb:9: The 'RedCloth' native gem requires installed build tools."
After some trials and Googling, I've found the following solution and it worked:
gem install RedCloth --platform=mswin32
UPDATE: 7th Feb, 2012
To use bundler, write the following in the Gemfile:
While supporting a long-term ROR web application, I got into a weird problem while setting up the environment to start up the app on my platform (Ruby 1.8.7, Rails 2.1.1, PostgreSQL 9 and Ubuntu 10.10). Symptoms of the problem show up when trying the following scenario:
In a development environment, start up the server, open a browser and enter the usual ' localhost:3000 ' url to start the app showing home page; till now, no problems, but, when making any action (clicking a link or even trying to refresh the home page) causes the browser to generate a '500 Internal Server Error'. A problem in the session you might think, so did we.
Following the log files showed that the failure occurs when trying to unmarshal some binary data retrieved from the database; the data been saved in the database are different when retrieved! More digging down took us to the column in database where the binary data were saved. The column type was bytea, which is basically a variable length binary string. The problem turned out to be that, for this specific data type (bytea), the output representation of PostgreSQL 9 is different from previous versions. PostgreSQL 9 introduced a new 'hex' format for output, this format is different from the old 'escape' format that older versions of PostgreSQL used to provide. That was the problem, we save data in the database, expect it to be in 'escape' format when retrieved, but we get it in 'hex' format.
The solution is rather simple, tell PostgreSQL to return data in the old, familiar 'escape' format. This can be achieved using the following code
ALTER DATABASE database_name SET bytea_output TO 'escape';
This, being executed in PostgreSQL command line, guarantees that you get the data in the format you expect.Read More