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&gt;\.

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