application.html for website in 2 languages?

Hello,

I’m a newbie on the rails environment. I’ve just created an
application.html.erb to have the same layout on all pages but the site
will be available in 2 different languages, then with 2 different
layouts.

Then I would like to have an application.html.erb with the layout in
French and an application.html.erb with the layout in English.

Thanks you for your help,

What you are looking at is a localization problem. We just grappled
with this problem as well and finally settled on: http://www.globalize-rails.org/globalize/
this is by far the most versatile. If you are using Rails 2.0.x I
believe it required some modification(1 line somewhere). If you decide
to use it and you run into some compatibility problems drop me a line.

Harm

Hello,

I'm a newbie on the rails environment. I've just created an
application.html.erb to have the same layout on all pages but the site
will be available in 2 different languages, then with 2 different
layouts.

Then I would like to have an application.html.erb with the layout in
French and an application.html.erb with the layout in English.

See <http://www.yotabanana.com/hiki/ruby-gettext-howto-rails.html#Localized+templates+for+Views%2FActionMailer>.

HTH,
Isak

Hello,

Thanks you for your quick replies but I don't want really to translate
some controllers or models but I would like to have a specific layout
for my content in French and another layout for my content in English
f.e.

For the content in a specific language, can I only add a field
"language" in my controllers and in the views, can I decide to take only
the data with the language "EN" ?

Depending on your needs, there are a few solutions out there:
http://agilewebdevelopment.com/plugins/category/8

These are the ones I've used so far:
Localization plugin: http://agilewebdevelopment.com/plugins/localization
Very good for simple translations with a language file similar to what you found in older php applications (basically a key with the translation). This is in case you don't need model translations, number formatting etc. It has a number of disadvantages, such as needing to restart the server if you want translations to be reloaded.

Gibberish: http://agilewebdevelopment.com/plugins/gibberish
Another lightweight translation plugin, but uses yaml files. You don't need to restart your webserver for the language files to reload. Has a number of extra plugins out there that extend its functionality (http://agilewebdevelopment.com/plugins/search?search=gibberish). That said, it's syntax was too verbose for me.

Globalize: http://agilewebdevelopment.com/plugins/globalize
It's the heavyweight amongst the translation plugins, has just about everything you'll ever need and it's heavy on resources too (no matter what caching is put in place in the plugin already, it drains performance quite a bit). It uses your database for translations. The best way to see what I mean is by doing a small profiling of your applications before using globalize, by installing it and translating a few views, then do the same profiling. While it is quite normal you see a bit of a performance hit, that of globalize is quite huge at each level (database and rendering). But, as I said, if you really need everything that can be internationalized, this plugin will probably be your best choice.

There's also simple_localization, where simple in its name must be about its complexity, not its featureset: http://simple-localization.arkanis.de/
I'm certainly tempted to try it out, it looks clean, has a nice featureset, Rails 2 compatible and not too bloated.

Best regards

Peter De Berdt

You could change the layouts by creating a helper function that
returns the name(s) of a language-specific css file and then using
that method in the head section of your layout:

<head>
   ...
  <%= stylesheet_link_tag language_based_css_for(@language) %>
   ...
</head>

Taking this approach gives you a lot of flexibility. You can set
@langauge based on some field associated with the user (if using
registered users) or from the preferred language requested by the
browser. Likewise, the helper method (language_based_css_for) could
get some help from the db or could be hard coded or...

I ran into the same problem and found most of the available solutions
add a lot of cruft to your installation. It is pretty easy to roll
your own solution. I just set a cookie somewhere and read that into a
global in a before filter. Then you define a simple method in your
applications.rb like

class ::Symbol
   def t(*args); ($lang==:uk ? ENGLISH_TEXT[self] : FRENCH_TEXT[self])
%args; end
end

and inside your views you can then do something like:
<%= :greeting.t('John') %>

and you keep a file in your lib directory with
ENGLISH_TEXT = { :greeting => 'Hello %s' }
FRENCH_TEXT = { : greeting => 'Bonjour %s' }

(I know that there are people that have a religious objection against
globals, but it should be fairly straight forward to do the same thing
with class variables if you're so inclined)

San,

Localization is a quite complex problem. For that I recommend
Globalize.

If you just want to choose a layout based on the language your user
chooses, there is a simple hack that works well. Put ssomething like
this in your controller (customize it for your needs):

  # Set layout only for show action
  layout :set_layout

  private

  def set_layout
    if [ 'show' ].include? action_name
      'no_sidebar'
    else
      'application'
    end
  end

Cheers, Sazima

I'll try the globalize plugin to translate the flash notice,etc. For
the views, I 've to create a specific view for the language if I
understand?

For the layout, is it possible to have a specific layout for a language
and another layout for the other language? I'ld like to use the system
"application.html.erb", so I don't need to repeat the code on each
page...

Thanks you for all replies concerning globalize, etc.

You are better off not putting any content in your views on a multi-
lingual site. Keeping several views and layouts for different
languages is a maintenance nightmare (I've been there). Much better to
replace all literal content with symbols (or something similar) and
translate those while rendering, like the example I gave above. You
also should use the same system for translating flash messages, model
errors and views if you want to keep your sanity.
cheers,
-j