The next step is to set up an application-wide filter that
will set the user??™s locale so that Globalize knows which translation to look for.
app/controllers/application.rb
class ApplicationController < ActionController::Base
helper :all
before_filter :set_locale
protected
def set_locale
# params overrides session, but en-US is only used if both
# params and session are absent
session[:locale] = LOCALES[params[:locale]] ||
session[:locale] ||
'en-US'
Locale.set session[:locale]
end
end
The set_locale filter will notice anytime a page is requested with a locale in the
query string (for example, http://localhost:3000/people?locale=es). It will set the locale
so the views are translated into the correct language, and then it will store the chosen
locale in the session so that the locale will be used again, even if the next request
has no locale parameter. The locale defaults to en-US if none can be found in the session
or params. An application that required user registration would most likely store
the user??™s locale preference in the user account, but the session will suffice for our
needs.
One very nice thing that Globalize does for us is to collect a list of text that needs to
be translated. As soon as the String#t method is called, if the appropriate translation
is not in place, it is stored away to be translated. We can use Ruby to strip out a
list of needed translations and send them to a translator.
Pages:
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409