What is Face Recognition?

Face Recognition uses feature extraction from facial points (like detecting where the eyes, nose, mouth etc are) within images or videos to recognize people. As you can image such a task isn’t trivial and requires a lot of know how. But the good news are that facial recognition just got a lot easier for developers to include in their applications. Face.com, a company that specializes in facial recognition, opened its platform APIs, allowing developers to integrate its facial recognition technology in third-party websites and applications.

Developers Get Facial Recognition API from Face.com

The face.com API uses REST-like interface. This means that all calls to the API are made over the Internet, using HTTP GET and POST requests to the face.com API server. Hence, any programming language that supports HTTP can be used to communicate with the service. Face.com has some common libraries to get you started.

How to use it with Ruby ?

Step 1: Get your API Key from http://developers.face.com/account. Don’t forget to add Facebook API and Secret Key as well as Twitter API Key And Secret Key. Keep them handy to use in your application.

Step 2: To use Face Recogonition API in Ruby we have to install the gem called ‘face‘.
sudo gem install face

Step 3: Now using api_key and api_secret, you can access get_client method of API.
>> client = Face.get_client(:api_key => ‘your_api_key’, :api_secret => ‘your_api_secret’)

Face Detection using Face gem in Ruby

Face gem provides three different ways to detect faces in an image.

1. Detect Faces with Urls
2. Detect Faces with Raw image data
3. Detect and Recognize faces with user auth

Lets understand with examples.

Detect Faces with Urls:

Suppose we want to detect face in the image located at this url. You will have to use faces_detect method as given below.

>>client.faces_detect(:urls => ['http://babybathreviews.com/wp-content/uploads/2011/01/How-to-choose-a-baby-bath.png'])

It will return photo detection output in the following way. Notice that you here you get face related information in a JSON format.

=> {"usage"=>{"remaining"=>4998, "used"=>2, "reset_time_text"=>"Fri, 04 Mar 2011 12:28:29 +0000", "reset_time"=>1299241709, "limit"=>5000}, "photos"=>[{"pid"=>"F@1ef2734600dc723985bcd35f477b07d2_2c40d987c43374fb6e8c2a7d095d3260", "url"=>"http://babybathreviews.com/wp-content/uploads/2011/01/How-to-choose-a-baby-bath.png", "tags"=>[{"pitch"=>5.14, "roll"=>7.08, "mouth_left"=>{"x"=>20.87, "y"=>75.51}, "tagger_id"=>nil, "label"=>"", "eye_left"=>{"x"=>21.62, "y"=>34.37}, "center"=>{"x"=>41.65, "y"=>56.8}, "mouth_center"=>{"x"=>29.86, "y"=>77.53}, "confirmed"=>false, "gid"=>nil, "threshold"=>nil, "attributes"=>{"glasses"=>{"confidence"=>95, "value"=>"false"}, "gender"=>{"confidence"=>15, "value"=>"male"}, "smiling"=>{"confidence"=>83, "value"=>"false"}, "face"=>{"confidence"=>75, "value"=>"true"}}, "yaw"=>-34.34, "tid"=>"TEMP_F@1ef2734600dc723985bcd35f477b07d2_2c40d987c43374fb6e8c2a7d095d3260_41.65_56.80_0_0", "eye_right"=>{"x"=>54.74, "y"=>38.45}, "uids"=>[], "mouth_right"=>{"x"=>42.46, "y"=>78.29}, "crop_jpeg"=>nil, "ear_left"=>nil, "height"=>86, "ear_right"=>nil, "nose"=>{"x"=>25.61, "y"=>56.81}, "manual"=>false, "recognizable"=>false, "chin"=>nil, "width"=>86.52}], "height"=>500, "width"=>497}], "status"=>"success"}

Detect Faces with Raw image data:

To detect faces from Raw image data, you will have to use following.

>> client.faces_detect(:file => File.new('image.jpg', 'rb'))

Detect and Recognize faces with user auth:

>> client.twitter_credentials = { :twitter_username => 'twitter_screen_name', :twitter_password => 'twitter_password' }
>> client.faces_recognize(:urls => ['http://test.com/1.jpg'], :uids => ['uiicor']) # will make request with twitter credentials

Hereby we are trying to recognize face with twitter credentials.

First we will have to initialize twitter credentials like this:

>> client.twitter_credentials = { :twitter_username => 'twitter_screen_name', :twitter_password => 'twitter_password' }

Step 2: To send the face recoginze request , write in the following way.

# will make request with twitter credentials
>> client.faces_recognize(:urls => ['http://www.allfunnyfaces.com/pictures/Baby_Faces.jpg'], :uid => ['uiicor'])

Note that uid is the id of the user on twitter.

Conclusion

The face gem provides facilty to detect faces from multi or single face images. Face gem is still under development. You can test it on face.com site. To get a feel for what is possible with the API you can browse some of the online examples, complete with source code, or play in the API sandbox. The face.com API has some decent documentation for those looking to dig deeper into the service, although the forums are fairly quiet at the moment.

No related posts.

In simple terms we can define scheduling as “the process of deciding how to commit resources between a variety of possible tasks“. The scheduling is basically a function which enables us to perform routine tasks at some predefined time or as part of a sequence. These tasks are normally executed in the background by so called “workers”.

Now the question is what’s the best way to run scheduled tasks in a Rails environment? Generally, Rails developers can use an application specific crontab to run application tasks. “Cron” is a time-based job scheduler in Unix-like operating systems (Linux, FreeBSD, Mac OS etc…). And these jobs or tasks are referred to as “Cron Jobs”. Downsides of Cron are:

• Cron works well on a single server but what if you need to scale to multiple app servers? You’ll need to introduce some kind of lock to avoid concurrency problems. Also, you need to maintain these shared locks.
• The other problem with Cron is that they are difficult to debug.
• Cron is for scheduling things, not doing them.

This can almost always be better to place jobs in queue and place the worker system to perform or to execute those jobs. Luckily there is a very good gem named ‘resque‘ available in Ruby on Rails.

Introduction to Resque

Resque is a Redis-backed Ruby library for creating background jobs, placing those jobs on multiple queues and processing them later. The main benefit withResque is that it allows you to create jobs and place them on a queue, then, later, pull those jobs off the queue and process them.

For the backstory, philosophy, and history of Resque’s beginnings, please see the blog post. Besides that recently I came to know about other two plugins which are available in Ruby on Rails for job scheduling. One of them is resque-scheduler and the other is rufus-scheduler. Lets have a look at both both in detail.

Resque Scheduler – A light-weight job scheduling system

Resque Scheduler is an extension to Resque that provides both scheduled and delayed jobs. This service can replace cron and bring the ability to schedule task to execute at certain times. Resque Scheduler support job scheduling in two different ways: Recurring or Scheduled (a standard cron job) and Delayed.

Recurring or Scheduled job

A recurring/scheduled job is a task that is specified to be run at a certain time. For example you may want to update any indexes at midnight everyday; this is a scheduled job that runs based on a fixed schedule which is set at startup. The schedule is just a hash, but is most likely stored in a YAML.
Delayed job
A delayed job is a job that gets put on the queue with a specified time in the future to run at. For example you may want to schedule a followup email to go out a few days after a user has signed up.

How To use Resque-scheduler?

First of all Install Resque Scheduler. Create sample application or you can get the sample application from the github.

$ rails new rescue_jobs -d mysql
$ cd rescue_jobs/

Next step is to modify Gemfile to include

gem 'rails', '3.0.3'
gem 'mysql2'
gem 'resque'
gem 'resque-scheduler'

Run $ bundle install. Now its time to Configure Resque Scheduler. In our sample we use a Redis service, of course you can use your own Redis Server as well. Go to Redis To Go and sign up for the free plan. Once you have an instance, grab the URL given to you and modify the config/initializers/resque.rb as follows:

ENV["REDISTOGO_URL"] ||= "redis://username:password@host:1234/"
uri = URI.parse(ENV["REDISTOGO_URL"])

Resque.redis = Redis.new(:host => uri.host, :port => uri.port, :password => uri.password)
require 'resque_scheduler'

Create a job named eat in app/jobs/eat.rb

module Eat
  @queue = :food
  def self.perform(food)
    puts "Ate #{food}!"
  end
end

Inside config/initializers/resque.rb place the following code so that app/jobs/eat.rb is loaded.

Dir["#{Rails.root}/app/jobs/*.rb"].each { |file| require file }

Create controller file and add code

class EatController 
  "Put #{params[:food]} in fridge to eat later."
end

Add following line in routes.rb file

match 'eat/:food' => 'eat#food'

You also need to add file tasks/resque.rake

$LOAD_PATH.unshift File.dirname(__FILE__) + '/../lib'
require 'resque_scheduler/tasks'

Finally create the crontab for Resque Scheduler. Create file config/resque_schedule.yml and insert the following text:

breakfast:
  cron: 0 8 * * *
  class: Eat
  args: scrambled egg
  description: Breakfast
lunch:
  cron: 0 12 * * *
  class: Eat
  args: penut-butter and jelly sandwich
  description: Lunch
dinner:
  cron: 0 6 * * *
  class: Eat
  args: Steak
  description: Dinner
midnight_snack:
  cron: 0 0 * * *
  class: Eat
  args: Milk & Cookies
  description: Midnight Snack

To load the schedule when we initialize Resque add the following line to config/initializers/resque.rb

Resque.schedule = YAML.load_file("#{Rails.root}/config/resque_schedule.yml")

At the end Start the Scheduler Process

$ rake resque:scheduler

Rufus Scheduler – scheduler for Ruby (at, in, cron and every jobs)

Rufus-Scheduler is the latest version of a scheduler previously known as openwferu-scheduler. It is a Ruby gem for scheduling pieces of code (jobs). Rufus-Scheduler understands running a job AT a certain time, IN a certain time, EVERY x time or simply via a CRON statement. But we must note that rufus-scheduler is no replacement for cron since it runs inside of Ruby. The scheduler doesn’t do any server-side tasks to get jobs to run, but relies on its scheduler being run up and maintained persistently (or semi-persistently, as with Rails app processes that will tip the scheduler into action).

It doesn’t require any database table, queueing mechanism, or separate process to manage. Just a simple scheduler to call out to your existing ruby code. No need to register at anything. You have to include only one file in config/initializers and add the task you want to schedule. Whenever you start your server that tasks are done or performed at specific time. So ultimately it saves the time of queuing and you get the work done.

How To use Rufus-Scheduler?

First of all create a sample application.
rails new sample_app

Then add rufus_scheduler in Gemfile
gem ‘rufus-scheduler’

Install the gem with bundle
$ bundle install.

Add following lines in config/initializers/task_scheduler.rb

require ‘rubygems’
require ‘rufus/scheduler’

## to start scheduler
scheduler = Rufus::Scheduler.start_new

## It will print message every i minute
scheduler.every("1m") do
  puts("HELLO #{Time.now}")
end

## Prints the message every day at noon
scheduler.cron("0,2 * * * *") do
  puts("HI #{Time.now}")
end

scheduler.in '20m' do
  puts "order butter"
end

scheduler.at 'Thu Mar 26 07:31:43 +0900 2009' do
  puts 'order pizza'
end

scheduler.cron '0 22 * * 1-5' do
  # every day of the week at 22:00 (10pm)
  puts 'activate security system'
end

scheduler.every '5m' do
  puts 'check status report'
end

You can also test above code on console.

Conclusion

Rescue Scheduler offers a simple and easy way to add scheduling abilities to any queueing system and is well worth the move from cron. But if you do’t want queuing and want only some scheduled jobs than rufus-scheduler is the best option.

Related posts:

1. Resque Jobs automatically require Rails environment and Lib Classes
2. Adding ‘whenever’ gem to Rails environment caused warning
3. Rake task for quitting Resque workers

We all know that there isn’t a fixed roadmap/release date for Ruby on Rails 3.1, but there are definitely rumors about the new features and improvements. Yehuda Katz, a member of the Ruby on Rails core team, said “With 3.1 we’ll go back to basics and look at things that are less invasive internally, but could have a big impact on developers. If you want to check latest updates then click here and check milestones for Rails 3.1. It’s really a good news that just 26 tickets are remaining out of 68 total tickets.

Lets talk about new features which will be integrated with RoR 3.1.

Object Scopes in Rails 3.1

The change that is made to object scope is :

- options = scope_options.is_a?(Proc) ? scope_options.call(*args) : scope_options
+ options = scope_options.respond_to?(:call) ? scope_options.call(*args) : scope_options

The above code describes that with Rails 3.1 it is possible to pass objects to scope methods that responds to the method ‘call’. Let’s understand what it means. Currently, with Rails 3 or Rails 3.0.x, scope works in the following way. For example, if we want to get all the products with name “Nokia” and with category “Mobile”, we used to create its scope method as given below.

class Product < ActiveRecord::Base
  scope :nokia, lambda {
    where(:name => 'Nokia')
  }
  scope :category, lambda { |value|
    where(:category => value)
  }
  scope :combined, lambda { |value|
    nokia.category(value)
  }
end

Now to get required data, we use it like

$ @nokia = Product.nokia.all # to get all the products with name Nokia
$ Product.category("Mobile").all # to get all the products with category Mobile
$ Product.nokia.category("Mobile").all #Combined : to get all the products with name = Nokia and category = Mobile.

But what if we have multiple classes that share the same logic for a named scope?? Suppose we want to get all the users with name = “John” and category = “Manager”. Think for a moment. In such cases it is obvious that we should be able to reuse same filter/scope code. Luckily, RoR 3.1 will provide exactly that kind of reusability. It will be possible to create classes that acts as scopes/filters.

In Rails 3.1, scope will be reused in other modules like this:

class Filter < Struct.new(:klass)
  def call(*args); end
end

module NameFilter
  def call(*args)
    klass.where(:name => args.shift)
    super(*args)
  end
end

module CategoryFilter
  def call(category, *args)
    klass.where(:category => args.shift)
    super(*args)
  end
end

class Product < ActiveRecord::Base
  scope :combined, Filter.new(self).extend(CategoryFilter).extend(NameFilter)
end

class User < ActiveRecord::Base
  scope :combined, Filter.new(self).extend(CategoryFilter).extend(NameFilter)
end

Product.combined('Nokia','Mobile').all
User.combined('John','Manager').all

Its simply great !! Changing a simple is_a? to a respond_to? can unlock quite a power.

Automatic Flushing

The Rails 3.1 will have new feature named “Auto Flushing” which helps to boost the performance of Ruby on Rails application. Normally whenever we are downloading any page, there is a two step process: first, all the code gets compiled to generate html view and second, all necessary files like css, javascripts, images are being loaded one by one.

As you’ve probably seen, DHH announced that they try to add flushing in Rails 3.1 to improve the client-side performance of a typical Rails applications. The most obvious solution, and one that already exists in plugin form, is to allow a layout to have a new flush method, which would immediately flush the contents of the layout to the browser. By putting the flush method below the JavaScript and CSS includes, the browser could begin downloading and evaluating those static assets while the server continues building the page. For more information regarding this feature, you can check here .

Rails 3.1 > Integration of Spriting

One thing DHH mentioned in his keynote was that Rails 3.1 should improve the way Rails handles JavaScript, Style Sheets, icons and images. Rails 3.1 will support a technique called Sprite Generation which is basically a method for combining many graphics into a single image. That single image will be then displayed using CSS.

<% sprite_css(“icons”) %> this code does two things. First is to combine all the images within a single folder and second is to generating its CSS. The advantage of using such technique is to reduce dozens of HTTP requests into one cache-friendly image file.

Keep js/css close to the code in view folder

Guess what !! With Rails on Rails 3.1, we will be able to write the code for stylesheets and javascripts in the app/ * folder like this :

#Preprocess:
app/views/js/item.js.erb
app/views/css/style.css.erb
#This code will be compiled to the files like this:
#Compiles:
public/application.js
public/style.css

The advantage of using the above feature is that after compilation of these files, your Ruby on Rails application will run on single CSS and javascript file which is neatly compressed without any kind of extra efforts.

What is going to be deprecated in Rails 3.1??

Passing options hash containing :conditions, :include, :joins, :limit, : offset, : order, :select, :readonly, :group, :having, :from, :lock etc inshort, finder methods which are provided by any ActiveRecord class will now be deprecated in Rails 3.1.

We used to write finder methods in this way

class User
  scope :name, :conditions => { :name => 'David' }
  scope :age, lambda {|age| {:conditions => ["age > ?", age] }}
end

In RoR 3.1 it will be :

class User
  scope :name, where(:name => 'David')
  scope :age, lambda {|age| where("age > ?", age) }
end

For more information you can check here.

From the above news about Rails 3.1 features, we can feel that Rails 3.1 will be another great release. Any guesses when we will see 3.1?

No related posts.

DEPRECATION WARNING: RAILS_ROOT is deprecated. Please use ::Rails.root.to_s. (called from <top (required)> at /Users/heli/hemju/programming/workspace/rubymine/linguist/config/application.rb:12)

So what to do when you want to get rid of them? Find them, (optional) create a patch, and report them to the plugin maintainer. One easy way to find deprecated elements is to override them and let them throw an exception or set them to nil. So in the above case, I would add RAILS_ROOT = nil to an initializer. At the next startup there will probably be an exception thrown and you know exactly where to find the deprecated method. Now start patching.

Related posts:

1. Rails 3 Quicktip: Autoload lib directory including all subdirectories, avoid lazy loading
2. Quicktip: Generating Entity-Relationship Diagrams for Ruby on Rails
3. Rails 3 Quicktip: Auto reload lib folders in development mode

Here is how we can force Rails 3 to reload these files in Development Mode:

First we need to know which files we want to reload. For this purpose we create an initializer that goes through the lib directory and stores the path of all Ruby files:

RELOAD_LIBS = Dir[Rails.root + 'lib/**/*.rb'] if Rails.env.development?

Now we only need to reload these files on every request. The best place for doing so is the ApplicationController. So we create this before_filter:

before_filter :_reload_libs, :if => :_reload_libs?

def _reload_libs
  RELOAD_LIBS.each do |lib|
    require_dependency lib
  end
end

def _reload_libs?
  defined? RELOAD_LIBS
end

The before filter runs only when the constant is defined (in our case in Development Mode) and reloads the file with the changes. No more restarting!

There are a couple of ways to reload the files, but I find this the least hackish way to do it. The downsides of this approach is that we have a before_filter in our ApplicationController that has nothing to do with the application logic and of course reloading all the files on every request slows things down. Nevertheless, not having to restart the server is really really helpful when developing in the lib directory.

See the quicktip in hemju Notes: http://notes.hemju.com/notes/rails-reload-lib-directory

—————

Update 25.4.2011

I updated the ‘reload_lib’ GIST using the suggestions from James’ comment.

Related posts:

1. Rails 3 Quicktip: Autoload lib directory including all subdirectories, avoid lazy loading
2. Quicktip: Generating Entity-Relationship Diagrams for Ruby on Rails
3. Quicktip: Finding deprecated constants/methods easily

Using Different backend with I18n

The I18n ruby gem comes with backend support for resource files (more specifically .yml files). Additionally, it also provides simple approach to exchange the backend implementation using different gem/plugin depending on your requirements. Let’s examine an example where all translations are stored within database.

Using Database backend for Ruby I18n API

You can easily use your database for storing all the translations with the help of i18n_backend_database (https://github.com/dylanz/i18n_backend_database) plugin. This plugin will store all your translations in the database instead of YAML files and provides a caching mechanism, so that the database doesn’t get hit for every translation. When you tag items using i18n.t() within the code base, all of untranslated items will be noted as well as added into the database. You can translate untranslated textual content through an administrator panel provided by plugin.

Update 2011-02-01

Please note that this plugin is not yet ready for Rails 3 (see comments). Here are the steps to use this plugin for Rails 2.x:

#install plugin in vendor/plugin folder
script/plugin install git://github.com/dylanz/i18n_backend_database.git
# add migration
script/generate i18n_backend_database
# migrate
rake db:migrate
# populate default locales
rake i18n:populate:load_default_locales
# populate the locales and translations tables from all Rails Locale YAML files.
rake i18n:populate:from_rails
# populate the translation tables from translation calls within the application.
rake i18n:populate:from_application
# create non-default locale translation records from default locale translations.
rake i18n:populate:synchronize_translations
# run all populate tasks.
rake i18n:populate:all
# translate all untranslated string values using Google Language Translation API.
rake i18n:translate:google

Add this lines in config/initializers/i18n.rb

I18n.backend = I18n::Backend::Database.new # registers the backend
I18n.backend.cache_store = :memory_store   # optional: specify an alternate cache store
I18n.backend.localize_text_tag = '##'      # optional: specify an alternate localize text tag, the default is ^^

In config/routes.rb register admin panel routes

map.from_plugin 'i18n_backend_database'

Now, rails application can translate all the code from the database. All non-user generated text provided by the application needs to be wrapped in a call to I18n.t().

I18n.t("Hello there!")

Interpolation is handled by passing in key/value pairs as a value to an interpolation tag    ( {{ }} ).

$ I18n.t("Hello there {{name}}!", :name => "Dylan")

$ I18n.t("Click {{here}} or {{there}}", :here => "link_to(I18n.t('midnite'), croix_path)", :there => "link_to(I18n.t('staten_island'), wu_path)")

Translating Routes with translate_routes Gem

The Ruby gem translate_routes helps you to translate URLs to any number of different languages, even for an already working application. This gem works with Rails 3.x. and also with other Rails versions like 2.1.x, 2.2.x and 2.3.x. The Ruby gem translate_routes is working good with all type of routing definitions, which includes RESTful as well as named routes. You don’t have to change your existing routing code, helpers, and so on; links work as expected – even in your tests.

Add translate_routes to your Gemfile:

gem 'translate_routes'

And let bundle do the rest: bundle install

1) Let’s say you have this in your routes.rb file:

TranslateRoutesApp::Application.routes.draw do
  match 'contact' => 'contact#index'
end

You can see the available routes with the ‘rake routes’ task:

contact  /contact(.:format) {:controller=>”contact”, :action=>”index”}

2) Now write your translations in a standard YAML file (e.g: in /config/i18n-routes.yml), including all the locales and their translations pairs:

en:
  # you can leave empty locales, for example the default one
es:
  contact: contacto

3) Append this line in your routes.rb file to activate the translations specifying the path of the translations file:

ActionDispatch::Routing::Translator.translate_from_file('config','i18n-routes.yml')

4) Execute rake routes to see the new routes:

contact_es  /es/contacto(.:format) {:controller=>”contact”, :action=>”index”}
contact_en  /contact(.:format)     {:controller=>”contact”, :action=>”index”}

5) Include this filter in your ApplicationController:

before_filter :set_locale_from_url

Now your application recognizes the different routes and sets the I18n.locale value in your controllers. But what about the routes generation? As you can see in the previous rake routes output, the contact_es_es_path and contact_en_us_path routing helpers have been generated and are available in your controllers and views. Additionally, a contact_path helper has been generated, which generates the routes according to the current request’s locale.

This means that if you use named routes, you don’t need to modify your application links because the routing helpers are automatically adapted to the current locale.

6) What about tests?

Of course, functional and integration testing involves some requests. The plugin includes some code to add a default locale parameter so they can remain untouched. Append it to your test_helper and it will be applied.

You can find additional information in the translate_routes’ wiki.

Globalize2 – Alternatives for Ruby I18n Gem

The Ruby gem Globalize2 was very popular in Rails community because it provides full-fledged internationalization solutions for Ruby on Rails application. You can use most of the features/tools independently and also you can combine them with other libraries or plugins.

The Feature/Tools for this gem are listed below.

• Model translations – This functionality transparently translates ActiveRecord data
• Locale LoadPath – This gem load translation data from standard locations enforcing conventions that suite your needs
• Locale Fallbacks – This feature make sure your translation lookups fall back transparently through a path of alternative locales that make sense for any given locale in your application
• Translation value objects – You can access useful meta data information on the translations returned from your backend and/or translated models

Conclusion

The I18n API comes with plenty of features and yet hides the complexity behind a simple to use API. With this gem, a Ruby on Rails application has a great built-in support for multiple languages. As the diversity of users is growing and more and more users speak different languages, a good localization and internationalizationsupport is necessary for every serious Web Framework. If your application has a more specific need, have a look at the various plugins and extensions available. Rails has also a great documentation, and of course there is an Internationalization section, I18n Wiki.

Related posts:

1. Internationalization (I18n) API in Ruby on Rails 3 (Part II)
2. Internationalization (I18n) API in Ruby on Rails 3 (Part I)
3. Ruby on Rails 2.2

1. Definition of Internationalization & Localization
2. How i18n mechanism works in Rails
3. Setup/Configuration about the i18n mechanism
4. Using the I18n with interpolation
5. Using the I18n with pluralization

You can read the full article on Internationalization (I18n) API in Rails 3 (Part I), if you have not yet read it.

Now, let’s start with some other features of I18n in Ruby on Rails.

Localization of Times/Dates
As I18n API provides date/time localization feature, we can easily add localized version of timestamp in Ruby on Rails application. To use this feature, first of all we need to add our localized translation for time format. Let’s change our de.yml file to add a German version.

# config/locales/de.yml
de:
  time:
    formats:
      description: "Aktuelle Uhrzeit %H Stunden und %M Minuten"

Now, we can use I18n.l or Rails #l helper to localize the Time object in our desired time format.

#script/console
>> I18n.locale = :de
=> :de
>> I18n.l Time.now, :format => :description
=> "Aktuelle Uhrzeit 20 Stunden und 07 Minuten"

You can add many more formats for date/time to make it work using the format that you want. You can also get a ready made version of different types of local files from rails-i18n github repository. Once you place those file(s) in config/locales/ folder, they are ready to use for localization.

Using views for translation
In Rails 2.3 a new feature named “localized views (templates)” was introduced. For example, your application has an ItemsController class with an index view. Your default index template page for ItemsController is rendered by app/views/items/index.html.erb. If you want a localized version of index page, you will just have to write your text in index.de.html.erb file and then will have to save in the same folder. By setting the locale to :de, you can force Ruby on Rails application to render the German version of that template. When the locale is set to the default locale, the generic index.html.erb view will be used.

Generally, this feature is used for large amount of static content pages, where putting this large text content in YAML or in Ruby dictionaries feels cumbersome.

Translating ActiveRecord errors
You can translate Active Record validation error messages easily. Active Record uses different namespaces which can be used to translate easily models, attributes, and/or validations.

For example, an Item model with a validates_presence_of validation for the name attribute like this:

class Item < ActiveRecord::Base
  validates_presence_of :name
end

In this case :blank is the key for the error message. So, Active Record will check this key in the namespaces:

activerecord.errors.models.[model_name].attributes.[attribute_name]
activerecord.errors.models.[model_name]
activerecord.errors.messages
errors.attributes.[attribute_name]
errors.messages

After following keys in the above mentioned order the result will be:

activerecord.errors.models.item.attributes.name.blank
activerecord.errors.models.item.blank
activerecord.errors.messages.blank
errors.attributes.name.blank
errors.messagges.blank

If, your models are using inheritance then the messages are looked up in the inheritance chain.

For example, you might have an Book model inheriting from Item:

class Book < Item
  validates_presence_of :title
end

Then Active Record will look for messages in this order:

activerecord.errors.models.book.attributes.title.blank
activerecord.errors.models.book.blank
activerecord.errors.models.item.attributes.title.blank
activerecord.errors.models.item.blank
activerecord.errors.messages.blank
errors.attributes.title.blank
errors.messagges.blank

You can also add translations for Active Record error_messages_for helper like this.

de:
  activerecord:
    errors:
      template:
        header:
          one:   "1 fehler verboten diese %{model} nicht gespeichert"
          other: "%{count} fehler verboten diese %{model} nicht gespeichert"
        body:    "Es gab probleme mit den folgenden feldern:"

Organization of resource files
If you are using default i18n library settings, you may find that all files are stored in plain-text format on the disc. Placing all translations text of your Ruby on Rails application in one file per locale could be tedious to organize. You can easily store these files in a hierarchy structure which is easy to understand for you. For example, your config/locales directory could be organized like this:

|-defaults
|---de.rb
|---en.rb
|-models
|---item
|-----de.rb
|-----en.rb
|-views
|---defaults
|-----de.rb
|-----en.rb
|---items
|-----de.rb
|-----en.rb
|---navigation
|-----de.rb
|-----en.rb

By following the above way to organize resource files, you can easily differentiate model and their attribute names from text inside views, and all of this from the “defaults”. In Ruby on Rails, locale files in nested dictionaries structure are not being loaded automatically. So, to make it work we have to do this settings in config/application.rb

# config/application.rb
  config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}')]

Setting the Locale from the Domain Name
In the previous article you read about how to set the locale in Ruby on Rails using application.rb settings. There are also other ways to do so. You can set the locale from the domain name where your Ruby on Rails application runs. Like www.example.com will load the content in English locale, www.example.de will load the content in German locale. This way you can use top-level domain names to set the locale for Ruby on Rails application.

The benefits of using this method are:

1. The locale setting is an obvious part of the URL.
2. Visitors obviously know in which language the content of the website will be displayed.
3. It is very easy to implement in Ruby on Rails.
4. Search engines love the content in different languages served at different domains.

You can use it in your ApplicationController:

before_filter :set_locale
 
def set_locale
  I18n.locale = extract_locale_from_tld
end

def extract_locale_from_tld
  parsed_locale = request.host.split('.').last
  I18n.available_locales.include?(parsed_locale.to_sym) ? parsed_locale  : nil
end
 
# Get locale from top-level domain or return nil if such locale is not available
# You have to put something like:
#   127.0.0.1 example.com
#   127.0.0.1 example.it
#   127.0.0.1 example.pl
# in your /etc/hosts file to try this out locally

We can also set the locale from the subdomain in a very similar way:

# Get locale code from request subdomain (like http://it.example.local:3000)
# You have to put something like:
#   127.0.0.1 gr.example.local
# in your /etc/hosts file to try this out locally

def extract_locale_from_subdomain
  parsed_locale = request.subdomains.first
  I18n.available_locales.include?(parsed_locale.to_sym) ? parsed_locale  : nil
end

You can also use switching menu option in your application like this:

link_to("Deutsch", "#{APP_CONFIG[:deutsch_website_url]}#{request.env['REQUEST_URI']}")

assuming you would set APP_CONFIG[:deutsch_website_url] to some value like http://www.example.de.

As previously mentioned this method has benefits, but what if you do not want to or able to provide different localizations (“language versions”) on different domains. The solution to this will be to add locale code in the URL params (or request path).

Setting the Locale from the URL Params
We can also set the locale by including it in URL params like www.example.com/items?locale=de or www.example.com/de/items.

You can use it in your ApplicationController:

before_filter :set_locale
 
def set_locale
  I18n.locale = params[:locale]
end

You can get same benefits with this method as with setting the locale from the domain name, but the only little problem is it takes bit more code to implement. Here is the code to implement it by including it in our ApplicationController:

# app/controllers/application_controller.rb
def default_url_options(options={})
  logger.debug "default_url_options is passed options: #{options.inspect}\n"
  { :locale => I18n.locale }
end

This way we can easily set/override “defaults” for url_for and helper methods dependent on it. So, every url_for dependent helper method will now add the locale in the query string like, http://example.com/?locale=de.

Now, if you want URLs to look like this http://example.com/de/items (which loads the German locale), we need to set up routes with path_prefix option this way:

# config/routes.rb
scope "/:locale" do
  resources :items
end

So, when you call items_path for :de locales, an URL like http://example.com/de/items will be generated with the German locale. But, if you do not want to force the use of a locale in your routes you can set an optional path scope like:

# config/routes.rb
scope "(:locale)", :locale => /en|de/ do
  resources :items
end

This way when you access http://example.com/items without a locale, you will not get a routing error, which is very useful for setting default locale when one is not mentioned.

Setting the Locale from the Client Supplied Information
Sometimes, you have to set the locale from the information that client had supplied (not from the URL.) i.e. user’s preferred language or by choosing the locale in your application interface and saving it to their profile.

Using Accept-Language HTTP header
Client may set Accept-Language HTTP header in their browser or other client (like curl) and request the url. By supplying the information of the locale. We can implement this scenario with this code in ApplicationController.

def set_locale
  logger.debug "* Accept-Language: #{request.env['HTTP_ACCEPT_LANGUAGE']}"
  I18n.locale = extract_locale_from_accept_language_header
  logger.debug "* Locale set to '#{I18n.locale}'"
end

private

def extract_locale_from_accept_language_header
  request.env['HTTP_ACCEPT_LANGUAGE'].scan(/^[a-z]{2}/).first
end

You can also use a plugin such as Iain Hecker’s http_accept_language or even Rack middleware such as Ryan Tomayko’s locale to implement this method in production mode.

Using User Profile
In your Ruby on Rails application it is also possible that users want to set the locale for their interface by setting it from database. In user’s profile, user will have to choose the locale from a dropdown list and it will get saved in the database along with other profile data. In this case, you need to override the locale value something like this.

def set_locale
  if current_user?
    I18n.locale = current_user.locale
  else
    I18n.locale = :en
  end
end 

That’s it for Part II. In Part III we will check

• Using different backends for I18n API
• Translating Routes

Related posts:

1. Internationalization (I18n) API in Ruby on Rails 3 (Part III)
2. Internationalization (I18n) API in Ruby on Rails 3 (Part I)

• Do it Yourself
• Pay Someone for doing Translation
• Ask your Users

No matter what, making the software ‘Internationalization ready’ is the developer’s job. No static strings, dates in the code and so forth; every text must be put in resource files and the code decides which text to use. Luckily Ruby on Rails provides a simple ruby gem called “I18n” (internationalization) that does exactly that.

Definition of Internationalization & Localization :

First of all let’s check the definition of Internationalization & Localization. According to Wikipedia,

i18n – “Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes.” This means, the “Internationalization” functionality translates all string and other locale specific information ( like date and currency formats) from your application in desire language to end user.

l10n – “Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text.” This means, the “Localization” functionality gives translations in local-specific language and other localized formats for local specific information.

How i18n mechanism works in Rails :

All the languages are different from each other in many ways (For example pluralization rules). It is very difficult for any tools/software to provide a general solution for language translation. To solve this problem I18n API provides two features in Ruby on Rails.

1. Give support for English and other similar languages out of the box
2. Provide a user-friendly and adjustable functions for supporting other languages

This means in Ruby on Rails every static string has been internationalized and you can “over-ride” these defaults with “localization” of the application.

There are two parts of Ruby I18n gem which are:

1. The public I18n API – provides a Ruby module with public methods to characterize the work of the library
2. A default backend – which executes these public methods

The Public I18n API comes with two most important methods which are:

1. translate # This public method do translations of the text
2. localize # This public method localize Date and Time objects to local formats as per settings

These method have aliases #t and #l respectively, so you can use them like this:

I18n.t 'store.title'

I18n.l Time.now

Setup/Configuration about the i18n mechanism

You can easily setup ruby I18n gem with few simple steps and use in your application for I18n support. Ruby on Rails application set up reasonable defaults in all .rb and .yml files in config folder. If you want to change the settings, you can easily change them according to your need.

To check the defaults for I18n module you have to check config/locales directory, which is default path for translation.

You will get one file named en.yml which default locale and contains these translation strings:

en:
  hello: "Hello world"

English is default locale in I18n library. So, if your application is not set in different locale, :en will translate all the static text changes.

So, when you check this on console the output shows like following :

>> I18n.locale
=> :en
>> I18n.default_locale
=> :en

Some other available locales which are supported by rails 3 are:

ar, bg, bn-IN, bs, ca, cy, cz, da, de, de-AT, de-CH, dsb, el, en-GB, en-US, eo, es, es-AR, es-CO, es-MX, es-PE, et, eu, fa, fi, fr, fr-CA, fr-CH, fur, gl-ES, gsw-CH, he, hi-IN, hr, hsb, hu, id, is, it, ja, ko, lo, lt, lv, mk, mn, nb, nl, nn, pl, pt-BR, pt-PT, rm, ro, ru, sk, sl, sr, sr-Latn, sv-SE, sw, th, tr, uk, vi, zh-CN, zh-TW

The easiest method to set your own locales to override the default locale is to change config/application.rb file in Rails 3. (You can apply same settings to config/environment.rb in Rails 2). Add this line to get German language as default locale:

config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]
config.i18n.default_locale = :de

The first line of code tells the location of translation file to the I18n library. The second line of code will set the default locale to :de other than :en.

Using the I18n module

Put these lines in config/locale/de.yml.

de:
  hello: "Hallo Welt"

Let’s check now whether this settings translate “hello” into “German” locale or not.

>> I18n.locale
=> :en
>> I18n.locale = 'de'
=> :de
>> I18n.t "hello"
=> "Hallo Welt"

Using the I18n with interpolation

Most of the time you want to use various variables with your translations. That’s why I18n API also provide interpolation feature.

>> I18n.backend.store_translations :en, :hello => 'Hello %{name}!'
>> I18n.translate :hello, :name => 'Newton'
=> 'Hello Newton!'

Using the I18n with pluralization
In English there are only one singular and one plural form for a given string, e.g. “1 friend” and “2 friends”. The best thing is I18n API also provides a flexible pluralization feature in Rails applications.

We must note that an interpolation variable named :count plays key role in translation and pluralization.

I18n.backend.store_translations :en, :friend => {
:one => '1 friend',
:other => '%{count} friends'
}
I18n.translate :friend, :count => 2
# => '2 friends'

The algorithm for pluralization is:

entry[count == 1 ? 0 : 1]

I.e. here 1 denotes singular and 0 denotes plural. So as specified using conditional operator, if count == 1, it will consider it as singular form otherwise its plural.

That’s it for Part I. In Part II we will check other features of I18n like

• Localization of Times/Dates
• Using views for translation
• Translating ActiveModel errors
• Organization of resource files
• Setting the locale (from domain, parameter or client) and of course storing it in the database when the user is logged in

For more details you can check http://ruby-i18n.org/ .

Related posts:

1. Internationalization (I18n) API in Ruby on Rails 3 (Part III)
2. Internationalization (I18n) API in Ruby on Rails 3 (Part II)
3. Ruby on Rails 2.2

Wait! here comes the solution and, that is, none other than Sunspot. Sunspot is basically a Ruby Library that is built on top of the RSolr library – A simple, extensible Ruby client for Apache Solr.

Recently, I had great experience of using Sunspot for full text search in one of my rails application. In Ruby on Rails, it is really easy to integrate full text search functionality, using Sunspot::Rails. I just followed set of steps, and it’s done. So, I thought sharing it with you.

For seamless integration of Sunspot search in your Rails application, you first need to install Sunspot::Rails.

Installation in Rails 2

$ sudo gem install sunspot_rails

#config/environment.rb
config.gem 'sunspot_rails', :lib => 'sunspot/rails'

Next step is to run the generator to create config/sunspot.yml file. For that, run following command

$ script/generate sunspot

To get the Sunspot rake tasks, you’ll need to require the tasks from your app’s Rakefile:

require 'sunspot/rails/tasks'

Installation in Rails 3

Add following line to your Gemfile to specify sunspot_rails gem

gem ‘sunspot_rails’, ’1.2.1′

Now, it’s time to update your bundle using the command below

$ bundle install

To run Sunspot generator, use

$ rails g sunspot_rails:install

The above steps will install Sunspot and RSolr as dependencies.

To Configure Solr that is a standalone HTTP Server use following command

$ rake sunspot:solr:start

The above command creates solr/ directory in Rails root consisting of Solr’ configurations and data files for Solr index. To change the configuration, you can check solr/conf file.

Full text search is basically a combination of two tasks:

1. Indexing
2. Searching/ Querying

Lets go through each of them one by one :

Defining an Index:

Suppose, I have a Book model with title, description, published and updated_at fields. Book model belongs to Author

class Book < ActiveRecord::Base
  belongs_to :auther
  searchable do
    text :title, :default_boost => 2
    text :description 
    time :updated_at       # for sorting by recent
    integer :auther_id, :multi => true do
      authers.map {|auther| auther.auther_id}
    end
    boolean :published, :using => :published?
  end

  def published?
    state == :published
  end

end

Note here that, text fields are used for full-text search, while, other fields are just used for filtering / restricting / sorting. The :default_boost parameter means that, words matching the :title field should be considered twice as relevant as, words matching the :description field.

For reindexing Book model’s records, You can use like Book.reindex!. For full reindex, you have to use rake sunspot:reindex

Searching / Querying

class BooksController < ApplicationController
  def search_results
    search = Book.search do
      keywords 'Rails Programming'
      with(:author_id).any_of [1, 2, 4, 8]
      paginate :page => page_number, :per_page => 30
      order_by :updated_at, :asc
    end
    @results = search.results
  end
end

Here are benefits of using Sunspot:

• It supports text,string,time,boolean and float fields.
• It easily integrates geolocation indexing.
• It uses flexible DSL for querying.
• It playes nice with WillPaginate Plugin.

No related posts.

However, sometimes documentation is really helpful. For example as an entity relationship diagram (ERD) of your domain model. With such a diagram you easily comprehend the relationships between the models. Creating an ERD manually is cumbersome and manual generated content tends to get outdated. Hence, we are looking for an auto generation tool for ERD.

RubyMine (IDE)

RubyMine is a Ruby/Rails IDE from JetBrains and it comes with an integrated ERD viewer. As an example I checked out Gemcutter (the Rails app behind RubyGems) and imported it as a project into RubyMine. Next open View/Show Model Dependency Diagram and you will see the ERD. You can export the image with the 4th button from the right (the one with the arrow).

Here is the result:

Rails-ERD

Because not everyone is using RubyMine (or even an IDE!), here another way to generate the diagram using the Rails-ERD gem. Follow the installations instructions for your operating system (sorry Windows, just Unix). I recommend using Homebrew which is just awesome. Then add the gem to the application’s Gemfile (gem “rails-erd”) and run bundle install from your application’s root. After that there is a new Rake task available called “erd”. When you run the task, it will generate an ERD as pdf (for more output options). Using Rails-ERD in our example Gemcutter project, produces this pdf.

Final Thoughts

When you compare the diagram from RubyMine with the diagram from Rails-ERD, you will see that they are different. This is because RubyMine generates the diagram based on the classes in the Model folder, while Rails-ERD seems to inspect the actual database models. Further, Rails-ERD shows only the relationships without the type (1:n, m:n), while RubyMine shows it. Nevertheless, both provide a quick and useful view of the database schema and it is generated automatically, hence always up to date.

Related posts:

1. Rails 3 Quicktip: Autoload lib directory including all subdirectories, avoid lazy loading
2. Quicktip: Finding deprecated constants/methods easily
3. Rails 3 Quicktip: Auto reload lib folders in development mode