Convert code blocks into GFM style

1 files changed, 114 insertions, 114 deletions

diff --git a/guides/source/i18n.md b/guides/source/i18n.md
index c073a146a8..f4ff52e5e1 100644
--- a/guides/source/i18n.md
+++ b/guides/source/i18n.md
@@ -46,27 +46,27 @@ h4. The Public I18n API
 
 The most important methods of the I18n API are:
 
-<ruby>
+```ruby
 translate # Lookup text translations
 localize  # Localize Date and Time objects to local formats
-</ruby>
+```
 
 These have the aliases #t and #l so you can use them like this:
 
-<ruby>
+```ruby
 I18n.t 'store.title'
 I18n.l Time.now
-</ruby>
+```
 
 There are also attribute readers and writers for the following attributes:
 
-<ruby>
+```ruby
 load_path         # Announce your custom translation files
 locale            # Get and set the current locale
 default_locale    # Get and set the default locale
 exception_handler # Use a different exception_handler
 backend           # Use a different backend
-</ruby>
+```
 
 So, let's internationalize a simple Rails application from the ground up in the next chapters!
 
@@ -82,10 +82,10 @@ Rails adds all +.rb+ and +.yml+ files from the +config/locales+ directory to you
 
 The default +en.yml+ locale in this directory contains a sample pair of translation strings:
 
-<ruby>
+```ruby
 en:
   hello: "Hello world"
-</ruby>
+```
 
 This means, that in the +:en+ locale, the key _hello_ will map to the _Hello world_ string. Every string inside Rails is internationalized in this way, see for instance Active Record validation messages in the "+activerecord/lib/active_record/locale/en.yml+":https://github.com/rails/rails/blob/master/activerecord/lib/active_record/locale/en.yml file or time and date formats in the "+activesupport/lib/active_support/locale/en.yml+":https://github.com/rails/rails/blob/master/activesupport/lib/active_support/locale/en.yml file. You can use YAML or standard Ruby Hashes to store translations in the default (Simple) backend.
 
@@ -99,11 +99,11 @@ NOTE: The backend will lazy-load these translations when a translation is looked
 
 The default +application.rb+ files has instructions on how to add locales from another directory and how to set a different default locale. Just uncomment and edit the specific lines.
 
-<ruby>
+```ruby
 # The default locale is :en and all translations from config/locales/*.rb,yml are auto loaded.
 # config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]
 # config.i18n.default_locale = :de
-</ruby>
+```
 
 h4. Optional: Custom I18n Configuration Setup
 
@@ -111,7 +111,7 @@ For the sake of completeness, let's mention that if you do not want to use the +
 
 To tell the I18n library where it can find your custom translation files you can specify the load path anywhere in your application - just make sure it gets run before any translations are actually looked up. You might also want to change the default locale. The simplest thing possible is to put the following into an initializer:
 
-<ruby>
+```ruby
 # in config/initializers/locale.rb
 
 # tell the I18n library where to find your translations
@@ -119,7 +119,7 @@ I18n.load_path += Dir[Rails.root.join('lib', 'locale', '*.{rb,yml}')]
 
 # set default locale to something other than :en
 I18n.default_locale = :pt
-</ruby>
+```
 
 h4. Setting and Passing the Locale
 
@@ -131,13 +131,13 @@ WARNING: You may be tempted to store the chosen locale in a _session_ or a <em>c
 
 The _setting part_ is easy. You can set the locale in a +before_filter+ in the +ApplicationController+ like this:
 
-<ruby>
+```ruby
 before_filter :set_locale
 
 def set_locale
   I18n.locale = params[:locale] || I18n.default_locale
 end
-</ruby>
+```
 
 This requires you to pass the locale as a URL query parameter as in +http://example.com/books?locale=pt+. (This is, for example, Google's approach.) So +http://localhost:3000?locale=pt+ will load the Portuguese localization, whereas +http://localhost:3000?locale=de+ would load the German localization, and so on. You may skip the next section and head over to the *Internationalize your application* section, if you want to try things out by manually placing the locale in the URL and reloading the page.
 
@@ -154,7 +154,7 @@ One option you have is to set the locale from the domain name where your applica
 
 You can implement it like this in your +ApplicationController+:
 
-<ruby>
+```ruby
 before_filter :set_locale
 
 def set_locale
@@ -171,11 +171,11 @@ def extract_locale_from_tld
   parsed_locale = request.host.split('.').last
   I18n.available_locales.include?(parsed_locale.to_sym) ? parsed_locale  : nil
 end
-</ruby>
+```
 
 We can also set the locale from the _subdomain_ in a very similar way:
 
-<ruby>
+```ruby
 # Get locale code from request subdomain (like http://it.application.local:3000)
 # You have to put something like:
 #   127.0.0.1 gr.application.local
@@ -184,13 +184,13 @@ def extract_locale_from_subdomain
   parsed_locale = request.subdomains.first
   I18n.available_locales.include?(parsed_locale.to_sym) ? parsed_locale : nil
 end
-</ruby>
+```
 
 If your application includes a locale switching menu, you would then have something like this in it:
 
-<ruby>
+```ruby
 link_to("Deutsch", "#{APP_CONFIG[:deutsch_website_url]}#{request.env['REQUEST_URI']}")
-</ruby>
+```
 
 assuming you would set +APP_CONFIG[:deutsch_website_url]+ to some value like +http://www.application.de+.
 
@@ -208,13 +208,13 @@ Rails contains infrastructure for "centralizing dynamic decisions about the URLs
 
 We can include something like this in our +ApplicationController+ then:
 
-<ruby>
+```ruby
 # 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
-</ruby>
+```
 
 Every helper method dependent on +url_for+ (e.g. helpers for named routes like +root_path+ or +root_url+, resource routes like +books_path+ or +books_url+, etc.) will now *automatically include the locale in the query string*, like this: +http://localhost:3001/?locale=ja+.
 
@@ -222,23 +222,23 @@ You may be satisfied with this. It does impact the readability of URLs, though,
 
 You probably want URLs to look like this: +www.example.com/en/books+ (which loads the English locale) and +www.example.com/nl/books+ (which loads the Dutch locale). This is achievable with the "over-riding +default_url_options+" strategy from above: you just have to set up your routes with "+scoping+":http://api.rubyonrails.org/classes/ActionDispatch/Routing/Mapper/Scoping.html option in this way:
 
-<ruby>
+```ruby
 # config/routes.rb
 scope "/:locale" do
   resources :books
 end
-</ruby>
+```
 
 Now, when you call the +books_path+ method you should get +"/en/books"+ (for the default locale). An URL like +http://localhost:3001/nl/books+ should load the Dutch locale, then, and following calls to +books_path+ should return +"/nl/books"+ (because the locale changed).
 
 If you don't want to force the use of a locale in your routes you can use an optional path scope (denoted by the parentheses) like so:
 
-<ruby>
+```ruby
 # config/routes.rb
 scope "(:locale)", :locale => /en|nl/ do
   resources :books
 end
-</ruby>
+```
 
 With this approach you will not get a +Routing Error+ when accessing your resources such as +http://localhost:3001/books+ without a locale. This is useful for when you want to use the default locale when one is not specified.
 
@@ -246,10 +246,10 @@ Of course, you need to take special care of the root URL (usually "homepage" or
 
 You would probably need to map URLs like these:
 
-<ruby>
+```ruby
 # config/routes.rb
 match '/:locale' => 'dashboard#index'
-</ruby>
+```
 
 Do take special care about the *order of your routes*, so this route declaration does not "eat" other ones. (You may want to add it directly before the +root :to+ declaration.)
 
@@ -266,7 +266,7 @@ One source of client supplied information would be an +Accept-Language+ HTTP hea
 
 A trivial implementation of using an +Accept-Language+ header would be:
 
-<ruby>
+```ruby
 def set_locale
   logger.debug "* Accept-Language: #{request.env['HTTP_ACCEPT_LANGUAGE']}"
   I18n.locale = extract_locale_from_accept_language_header
@@ -276,7 +276,7 @@ private
 def extract_locale_from_accept_language_header
   request.env['HTTP_ACCEPT_LANGUAGE'].scan(/^[a-z]{2}/).first
 end
-</ruby>
+```
 
 Of course, in a production environment you would need much more robust code, and could use a plugin such as Iain Hecker's "http_accept_language":https://github.com/iain/http_accept_language/tree/master or even Rack middleware such as Ryan Tomayko's "locale":https://github.com/rack/rack-contrib/blob/master/lib/rack/contrib/locale.rb.
 
@@ -296,7 +296,7 @@ Let's _internationalize_ our application, i.e. abstract every locale-specific pa
 
 You most probably have something like this in one of your applications:
 
-<ruby>
+```ruby
 # config/routes.rb
 Yourapp::Application.routes.draw do
   root :to => "home#index"
@@ -312,7 +312,7 @@ end
 # app/views/home/index.html.erb
 <h1>Hello World</h1>
 <p><%= flash[:notice] %></p>
-</ruby>
+```
 
 !images/i18n/demo_untranslated.png(rails i18n demo untranslated)!
 
@@ -320,7 +320,7 @@ h4. Adding Translations
 
 Obviously there are *two strings that are localized to English*. In order to internationalize this code, *replace these strings* with calls to Rails' +#t+ helper with a key that makes sense for the translation:
 
-<ruby>
+```ruby
 # app/controllers/home_controller.rb
 class HomeController < ApplicationController
   def index
@@ -331,7 +331,7 @@ end
 # app/views/home/index.html.erb
 <h1><%=t :hello_world %></h1>
 <p><%= flash[:notice] %></p>
-</ruby>
+```
 
 When you now render this view, it will show an error message which tells you that the translations for the keys +:hello_world+ and +:hello_flash+ are missing.
 
@@ -341,7 +341,7 @@ NOTE: Rails adds a +t+ (+translate+) helper method to your views so that you do
 
 So let's add the missing translations into the dictionary files (i.e. do the "localization" part):
 
-<ruby>
+```ruby
 # config/locales/en.yml
 en:
   hello_world: Hello world!
@@ -351,7 +351,7 @@ en:
 pirate:
   hello_world: Ahoy World
   hello_flash: Ahoy Flash
-</ruby>
+```
 
 There you go. Because you haven't changed the default_locale, I18n will use English. Your application now shows:
 
@@ -369,35 +369,35 @@ h4. Passing variables to translations
 
 You can use variables in the translation messages and pass their values from the view.
 
-<ruby>
+```ruby
 # app/views/home/index.html.erb
 <%=t 'greet_username', :user => "Bill", :message => "Goodbye" %>
 
 # config/locales/en.yml
 en:
   greet_username: "%{message}, %{user}!"
-</ruby>
+```
 
 h4. Adding Date/Time Formats
 
 OK! Now let's add a timestamp to the view, so we can demo the *date/time localization* feature as well. To localize the time format you pass the Time object to +I18n.l+ or (preferably) use Rails' +#l+ helper. You can pick a format by passing the +:format+ option -- by default the +:default+ format is used.
 
-<ruby>
+```ruby
 # app/views/home/index.html.erb
 <h1><%=t :hello_world %></h1>
 <p><%= flash[:notice] %></p
 <p><%= l Time.now, :format => :short %></p>
-</ruby>
+```
 
 And in our pirate translations file let's add a time format (it's already there in Rails' defaults for English):
 
-<ruby>
+```ruby
 # config/locales/pirate.yml
 pirate:
   time:
     formats:
       short: "arrrround %H'ish"
-</ruby>
+```
 
 So that would give you:
 
@@ -421,7 +421,7 @@ When you are using the default SimpleStore shipped with the i18n library, dictio
 
 For example, your +config/locales+ directory could look like this:
 
-<pre>
+```
 |-defaults
 |---es.rb
 |---en.rb
@@ -442,17 +442,17 @@ For example, your +config/locales+ directory could look like this:
 |---navigation
 |-----es.rb
 |-----en.rb
-</pre>
+```
 
 This way, you can separate model and model attribute names from text inside views, and all of this from the "defaults" (e.g. date and time formats). Other stores for the i18n library could provide different means of such separation.
 
 NOTE: The default locale loading mechanism in Rails does not load locale files in nested dictionaries, like we have here. So, for this to work, we must explicitly tell Rails to look further:
 
-<ruby>
+```ruby
   # config/application.rb
   config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}')]
 
-</ruby>
+```
 
 Do check the "Rails i18n Wiki":http://rails-i18n.org/wiki for list of tools available for managing translations.
 
@@ -474,84 +474,84 @@ h5. Basic Lookup, Scopes and Nested Keys
 
 Translations are looked up by keys which can be both Symbols or Strings, so these calls are equivalent:
 
-<ruby>
+```ruby
 I18n.t :message
 I18n.t 'message'
-</ruby>
+```
 
 The +translate+ method also takes a +:scope+ option which can contain one or more additional keys that will be used to specify a “namespace” or scope for a translation key:
 
-<ruby>
+```ruby
 I18n.t :record_invalid, :scope => [:activerecord, :errors, :messages]
-</ruby>
+```
 
 This looks up the +:record_invalid+ message in the Active Record error messages.
 
 Additionally, both the key and scopes can be specified as dot-separated keys as in:
 
-<ruby>
+```ruby
 I18n.translate "activerecord.errors.messages.record_invalid"
-</ruby>
+```
 
 Thus the following calls are equivalent:
 
-<ruby>
+```ruby
 I18n.t 'activerecord.errors.messages.record_invalid'
 I18n.t 'errors.messages.record_invalid', :scope => :active_record
 I18n.t :record_invalid, :scope => 'activerecord.errors.messages'
 I18n.t :record_invalid, :scope => [:activerecord, :errors, :messages]
-</ruby>
+```
 
 h5. Defaults
 
 When a +:default+ option is given, its value will be returned if the translation is missing:
 
-<ruby>
+```ruby
 I18n.t :missing, :default => 'Not here'
 # => 'Not here'
-</ruby>
+```
 
 If the +:default+ value is a Symbol, it will be used as a key and translated. One can provide multiple values as default. The first one that results in a value will be returned.
 
 E.g., the following first tries to translate the key +:missing+ and then the key +:also_missing.+ As both do not yield a result, the string "Not here" will be returned:
 
-<ruby>
+```ruby
 I18n.t :missing, :default => [:also_missing, 'Not here']
 # => 'Not here'
-</ruby>
+```
 
 h5. Bulk and Namespace Lookup
 
 To look up multiple translations at once, an array of keys can be passed:
 
-<ruby>
+```ruby
 I18n.t [:odd, :even], :scope => 'errors.messages'
 # => ["must be odd", "must be even"]
-</ruby>
+```
 
 Also, a key can translate to a (potentially nested) hash of grouped translations. E.g., one can receive _all_ Active Record error messages as a Hash with:
 
-<ruby>
+```ruby
 I18n.t 'activerecord.errors.messages'
 # => { :inclusion => "is not included in the list", :exclusion => ... }
-</ruby>
+```
 
 h5. "Lazy" Lookup
 
 Rails implements a convenient way to look up the locale inside _views_. When you have the following dictionary:
 
-<yaml>
+```yaml
 es:
   books:
     index:
       title: "Título"
-</yaml>
+```
 
 you can look up the +books.index.title+ value *inside* +app/views/books/index.html.erb+ template like this (note the dot):
 
-<ruby>
+```ruby
 <%= t '.title' %>
-</ruby>
+```
 
 h4. Interpolation
 
@@ -559,11 +559,11 @@ In many cases you want to abstract your translations so that *variables can be i
 
 All options besides +:default+ and +:scope+ that are passed to +#translate+ will be interpolated to the translation:
 
-<ruby>
+```ruby
 I18n.backend.store_translations :en, :thanks => 'Thanks %{name}!'
 I18n.translate :thanks, :name => 'Jeremy'
 # => 'Thanks Jeremy!'
-</ruby>
+```
 
 If a translation uses +:default+ or +:scope+ as an interpolation variable, an +I18n::ReservedInterpolationKey+ exception is raised. If a translation expects an interpolation variable, but this has not been passed to +#translate+, an +I18n::MissingInterpolationArgument+ exception is raised.
 
@@ -573,7 +573,7 @@ In English there are only one singular and one plural form for a given string, e
 
 The +:count+ interpolation variable has a special role in that it both is interpolated to the translation and used to pick a pluralization from the translations according to the pluralization rules defined by CLDR:
 
-<ruby>
+```ruby
 I18n.backend.store_translations :en, :inbox => {
   :one => 'one message',
   :other => '%{count} messages'
@@ -583,13 +583,13 @@ I18n.translate :inbox, :count => 2
 
 I18n.translate :inbox, :count => 1
 # => 'one message'
-</ruby>
+```
 
 The algorithm for pluralizations in +:en+ is as simple as:
 
-<ruby>
+```ruby
 entry[count == 1 ? 0 : 1]
-</ruby>
+```
 
 I.e. the translation denoted as +:one+ is regarded as singular, the other is used as plural (including the count being zero).
 
@@ -601,30 +601,30 @@ The locale can be either set pseudo-globally to +I18n.locale+ (which uses +Threa
 
 If no locale is passed, +I18n.locale+ is used:
 
-<ruby>
+```ruby
 I18n.locale = :de
 I18n.t :foo
 I18n.l Time.now
-</ruby>
+```
 
 Explicitly passing a locale:
 
-<ruby>
+```ruby
 I18n.t :foo, :locale => :de
 I18n.l Time.now, :locale => :de
-</ruby>
+```
 
 The +I18n.locale+ defaults to +I18n.default_locale+ which defaults to :+en+. The default locale can be set like this:
 
-<ruby>
+```ruby
 I18n.default_locale = :de
-</ruby>
+```
 
 h4. Using Safe HTML Translations
 
 Keys with a '_html' suffix and keys named 'html' are marked as HTML safe. Use them in views without escaping.
 
-<ruby>
+```ruby
 # config/locales/en.yml
 en:
   welcome: <b>welcome!</b>
@@ -637,7 +637,7 @@ en:
 <div><%= raw t('welcome') %></div>
 <div><%= t('hello_html') %></div>
 <div><%= t('title.html') %></div>
-</ruby>
+```
 
 !images/i18n/demo_html_safe.png(i18n demo html safe)!
 
@@ -647,7 +647,7 @@ The Simple backend shipped with Active Support allows you to store translations
 
 For example a Ruby Hash providing translations can look like this:
 
-<ruby>
+```ruby
 {
   :pt => {
     :foo => {
@@ -655,37 +655,37 @@ For example a Ruby Hash providing translations can look like this:
     }
   }
 }
-</ruby>
+```
 
 The equivalent YAML file would look like this:
 
-<ruby>
+```ruby
 pt:
   foo:
     bar: baz
-</ruby>
+```
 
 As you see, in both cases the top level key is the locale. +:foo+ is a namespace key and +:bar+ is the key for the translation "baz".
 
 Here is a "real" example from the Active Support +en.yml+ translations YAML file:
 
-<ruby>
+```ruby
 en:
   date:
     formats:
       default: "%Y-%m-%d"
       short: "%b %d"
       long: "%B %d, %Y"
-</ruby>
+```
 
 So, all of the following equivalent lookups will return the +:short+ date format +"%B %d"+:
 
-<ruby>
+```ruby
 I18n.t 'date.formats.short'
 I18n.t 'formats.short', :scope => :date
 I18n.t :short, :scope => 'date.formats'
 I18n.t :short, :scope => [:date, :formats]
-</ruby>
+```
 
 Generally we recommend using YAML as a format for storing translations. There are cases, though, where you want to store Ruby lambdas as part of your locale data, e.g. for special date formats.
 
@@ -695,7 +695,7 @@ You can use the methods +Model.model_name.human+ and +Model.human_attribute_name
 
 For example when you add the following translations:
 
-<ruby>
+```ruby
 en:
   activerecord:
     models:
@@ -704,7 +704,7 @@ en:
       user:
         login: "Handle"
       # will translate User attribute "login" as "Handle"
-</ruby>
+```
 
 Then +User.model_name.human+ will return "Dude" and +User.human_attribute_name("login")+ will return "Handle".
 
@@ -716,45 +716,45 @@ This gives you quite powerful means to flexibly adjust your messages to your app
 
 Consider a User model with a validation for the name attribute like this:
 
-<ruby>
+```ruby
 class User < ActiveRecord::Base
   validates :name, :presence => true
 end
-</ruby>
+```
 
 The key for the error message in this case is +:blank+. Active Record will look up this key in the namespaces:
 
-<ruby>
+```ruby
 activerecord.errors.models.[model_name].attributes.[attribute_name]
 activerecord.errors.models.[model_name]
 activerecord.errors.messages
 errors.attributes.[attribute_name]
 errors.messages
-</ruby>
+```
 
 Thus, in our example it will try the following keys in this order and return the first result:
 
-<ruby>
+```ruby
 activerecord.errors.models.user.attributes.name.blank
 activerecord.errors.models.user.blank
 activerecord.errors.messages.blank
 errors.attributes.name.blank
 errors.messages.blank
-</ruby>
+```
 
 When your models are additionally using inheritance then the messages are looked up in the inheritance chain.
 
 For example, you might have an Admin model inheriting from User:
 
-<ruby>
+```ruby
 class Admin < User
   validates :name, :presence => true
 end
-</ruby>
+```
 
 Then Active Record will look for messages in this order:
 
-<ruby>
+```ruby
 activerecord.errors.models.admin.attributes.name.blank
 activerecord.errors.models.admin.blank
 activerecord.errors.models.user.attributes.name.blank
@@ -762,7 +762,7 @@ activerecord.errors.models.user.blank
 activerecord.errors.messages.blank
 errors.attributes.name.blank
 errors.messages.blank
-</ruby>
+```
 
 This way you can provide special translations for various error messages at different points in your models inheritance chain and in the attributes, models, or default scopes.
 
@@ -803,7 +803,7 @@ If you are using the Active Record +error_messages_for+ helper, you will want to
 
 Rails ships with the following translations:
 
-<yaml>
+```yaml
 en:
   activerecord:
     errors:
@@ -812,7 +812,7 @@ en:
           one:   "1 error prohibited this %{model} from being saved"
           other: "%{count} errors prohibited this %{model} from being saved"
         body:    "There were problems with the following fields:"
-</yaml>
+```
 
 h4. Overview of Other Built-In Methods that Provide I18n Support
 
@@ -846,28 +846,28 @@ For several reasons the Simple backend shipped with Active Support only does the
 
 That does not mean you're stuck with these limitations, though. The Ruby I18n gem makes it very easy to exchange the Simple backend implementation with something else that fits better for your needs. E.g. you could exchange it with Globalize's Static backend:
 
-<ruby>
+```ruby
 I18n.backend = Globalize::Backend::Static.new
-</ruby>
+```
 
 You can also use the Chain backend to chain multiple backends together. This is useful when you want to use standard translations with a Simple backend but store custom application translations in a database or other backends. For example, you could use the Active Record backend and fall back to the (default) Simple backend:
 
-<ruby>
+```ruby
 I18n.backend = I18n::Backend::Chain.new(I18n::Backend::ActiveRecord.new, I18n.backend)
-</ruby>
+```
 
 h4. Using Different Exception Handlers
 
 The I18n API defines the following exceptions that will be raised by backends when the corresponding unexpected conditions occur:
 
-<ruby>
+```ruby
 MissingTranslationData       # no translation was found for the requested key
 InvalidLocale                # the locale set to I18n.locale is invalid (e.g. nil)
 InvalidPluralizationData     # a count option was passed but the translation data is not suitable for pluralization
 MissingInterpolationArgument # the translation expects an interpolation argument that has not been passed
 ReservedInterpolationKey     # the translation contains a reserved interpolation variable name (i.e. one of: scope, default)
 UnknownFileType              # the backend does not know how to handle a file type that was added to I18n.load_path
-</ruby>
+```
 
 The I18n API will catch all of these exceptions when they are thrown in the backend and pass them to the default_exception_handler method. This method will re-raise all exceptions except for +MissingTranslationData+ exceptions. When a +MissingTranslationData+ exception has been caught, it will return the exception’s error message string containing the missing key/scope.
 
@@ -875,7 +875,7 @@ The reason for this is that during development you'd usually want your views to
 
 In other contexts you might want to change this behaviour, though. E.g. the default exception handling does not allow to catch missing translations during automated tests easily. For this purpose a different exception handler can be specified. The specified exception handler must be a method on the I18n module or a class with +#call+ method:
 
-<ruby>
+```ruby
 module I18n
   class JustRaiseExceptionHandler < ExceptionHandler
     def call(exception, locale, key, options)
@@ -889,27 +889,27 @@ module I18n
 end
 
 I18n.exception_handler = I18n::JustRaiseExceptionHandler.new
-</ruby>
+```
 
 This would re-raise only the +MissingTranslationData+ exception, passing all other input to the default exception handler.
 
 However, if you are using +I18n::Backend::Pluralization+ this handler will also raise +I18n::MissingTranslationData: translation missing: en.i18n.plural.rule+ exception that should normally be ignored to fall back to the default pluralization rule for English locale. To avoid this you may use additional check for translation key:
 
-<ruby>
+```ruby
 if exception.is_a?(MissingTranslation) && key.to_s != 'i18n.plural.rule'
   raise exception.to_exception
 else
   super
 end
-</ruby>
+```
 
 Another example where the default behaviour is less desirable is the Rails TranslationHelper which provides the method +#t+ (as well as +#translate+). When a +MissingTranslationData+ exception occurs in this context, the helper wraps the message into a span with the CSS class +translation_missing+.
 
 To do so, the helper forces +I18n#translate+ to raise exceptions no matter what exception handler is defined by setting the +:raise+ option:
 
-<ruby>
+```ruby
 I18n.t :foo, :raise => true # always re-raises exceptions from the backend
-</ruby>
+```
 
 h3. Conclusion