From de23a0077635f46c8c03a44a81e3efe95e28f2ab Mon Sep 17 00:00:00 2001 From: Pratik Naik Date: Wed, 21 Jan 2009 21:30:37 +0000 Subject: Regenerate guides --- railties/doc/guides/html/form_helpers.html | 74 ++++---- railties/doc/guides/html/i18n.html | 265 +++++++++++++++++++++++++++-- 2 files changed, 293 insertions(+), 46 deletions(-) (limited to 'railties') diff --git a/railties/doc/guides/html/form_helpers.html b/railties/doc/guides/html/form_helpers.html index 6169574d35..54155cddb6 100644 --- a/railties/doc/guides/html/form_helpers.html +++ b/railties/doc/guides/html/form_helpers.html @@ -90,6 +90,15 @@
  • Dealing with Ajax
    • + + +
  • + Customising Form Builders +
    • +
  • + Understanding Parameter Naming Conventions +
    • @@ -97,9 +101,18 @@
  • + Conclusion +
    • +
  • + Contributing to Rails I18n +
    • +
  • Resources
  • + Authors +
    • +
  • Footnotes
  • @@ -244,8 +257,17 @@ I18n.load_path # set default locale to something else then :en I18n.default_locale = :pt

    2.3. Setting and passing the locale

    -

    By default the I18n library will use :en (English) as a I18n.default_locale for looking up translations (if you do not specify a locale for a lookup).

    -

    If you want to translate your Rails application to a single language other than English you can set I18n.default_locale to your locale. If you want to change the locale on a per-request basis though you can set it in a before_filter on the ApplicationController like this:

    +

    If you want to translate your Rails application to a single language other than English (the default locale), you can set I18n.default_locale to your locale in environment.rb or an initializer as shown above, and it will persist through the requests.

    +

    However, you would probably like to provide support for more locales in your application. In such case, you need to set and pass the locale between requests.

    +
    + + + +
    +Warning +You may be tempted to store choosed locale in a session or a cookie. Do not do so. The locale should be transparent and a part of the URL. This way you don’t break people’s basic assumptions about the web itself: if you send a URL of some page to a friend, she should see the same page, same content. A fancy word for this would be that you’re being RESTful. There may be some exceptions to this rule, which are discussed below.
    +
    +

    The setting part is easy. You can set locale in a before_filter in the ApplicationController like this:

    before_filter :set_locale
 def set_locale
-  # if this is nil then I18n.default_locale will be used
+  # if params[:locale] is nil then I18n.default_locale will be used
   I18n.locale = params[:locale]
 end
    -

    This will already work for URLs where you pass the locale as a query parameter as in example.com?locale=pt (which is what Google also does).

    +

    This requires you to pass the locale as a URL query parameter as in http://example.com/books?locale=pt. (This is eg. Google’s approach). So http://localhost:3000?locale=pt will load the Portugese localization, whereas http://localhost:3000?locale=de would load the German localization, and so on.

    +

    Of course, you probably don’t want to manually include locale in every URL all over your application, or want the URLs look differently, eg. the usual http://example.com/pt/books versus http://example.com/en/books. Let’s discuss the different options you have.

    +
    + + + +
    +Important +Following examples rely on having locales loaded into your application available as an array of strings like ["en", "es", "gr"]. This is not inclued in current version of Rails 2.2 — forthcoming Rails version 2.3 will contain easy accesor available_locales. (See this commit and background at Rails I18n Wiki.)
    +
    +

    We have to include support for getting available locales manually in an initializer like this:

    +
    +
    +
    # config/initializers/available_locales.rb
+#
+# Get loaded locales conveniently
+# See http://rails-i18n.org/wiki/pages/i18n-available_locales
+module I18n
+  class << self
+    def available_locales; backend.available_locales; end
+  end
+  module Backend
+    class Simple
+      def available_locales; translations.keys.collect { |l| l.to_s }.sort; end
+    end
+  end
+end
+
+# You need to "force-initialize" loaded locales
+I18n.backend.send(:init_translations)
+
+AVAILABLE_LOCALES = I18n.backend.available_locales
+RAILS_DEFAULT_LOGGER.debug "* Loaded locales: #{AVAILABLE_LOCALES.inspect}"
    +

    You can then wrap the constant for easy access in ApplicationController:

    +
    +
    +
    class ApplicationController < ActionController::Base
+  def available_locales; AVAILABLE_LOCALES; end
+end
    +

    2.4. Setting locale from the domain name

    +

    One option you have is to set the locale from the domain name, where your application runs. For example, we want www.example.com to load English (or default) locale, and www.example.es to load Spanish locale. Thus the top-level domain name is used for locale setting. This has several advantages:

    +
      +
    • +

      +Locale is an obvious part of the URL +

      +
      • +
    • +

      +People intuitively grasp in which language the content will be displayed +

      +
      • +
    • +

      +It is very trivial to implement in Rails +

      +
      • +
    • +

      +Search engines seem to like that content in different languages lives at different, inter-linked domains +

      +
      • +
    +

    You can implement it like this in your ApplicationController:

    +
    +
    +
    before_filter :set_locale
+def set_locale
+  I18n.locale = extract_locale_from_uri
+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 application.com
+#   127.0.0.1 application.it
+#   127.0.0.1 application.pl
+# in your /etc/hosts file to try this out locally
+def extract_locale_from_tld
+  parsed_locale = request.host.split('.').last
+  (available_locales.include? parsed_locale) ? parsed_locale  : nil
+end
    +

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

    +
    +
    +
    # 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
+# in your /etc/hosts file to try this out locally
+def extract_locale_from_subdomain
+  parsed_locale = request.subdomains.first
+  (available_locales.include? parsed_locale) ? parsed_locale  : nil
+end
    +

    2.5. Setting locale from the URL params

    +
    - +
    Tip For other URL designs, see How to encode the current locale in the URL.For setting locale from URL see How to encode the current locale in the URL in the Rails i18n Wiki.

    Now you’ve initialized I18n support for your application and told it which locale should be used. With that in place you’re now ready for the really interesting stuff.

    @@ -340,7 +477,7 @@ pirate: hello_flash: Ahoy Flash

    There you go. Because you haven’t changed the default_locale I18n will use English. Your application now shows:

    -rails i18n demo translated to english +rails i18n demo translated to english

    And when you change the URL to pass the pirate locale you get:

    @@ -815,9 +952,52 @@ http://www.gnu.org/software/src-highlite --> 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:"

    -

    5.2. Other translations and localizations

    -

    Rails uses fixed strings and other localizations, such as format strings and other format information in a couple of helpers.

    -

    TODO list helpers and available keys

    +

    5.2. Overview of other built-in methods that provide I18n support

    +

    Rails uses fixed strings and other localizations, such as format strings and other format information in a couple of helpers. Here’s a brief overview.

    +

    5.2.1. ActionView helper methods

    +
      +
    • +

      +distance_of_time_in_words translates and pluralizes its result and interpolates the number of seconds, minutes, hours and so on. See datetime.distance_in_words translations. +

      +
      • +
    • +

      +datetime_select and select_month use translated month names for populating the resulting select tag. See date.month_names for translations. datetime_select also looks up the order option from date.order (unless you pass the option explicitely). All date select helpers translate the prompt using the translations in the datetime.prompts scope if applicable. +

      +
      • +
    • +

      +The number_to_currency, number_with_precision, number_to_percentage, number_with_delimiter and humber_to_human_size helpers use the number format settings located in the number scope. +

      +
      • +
    +

    5.2.2. ActiveRecord methods

    +
      +
    • +

      +human_name and human_attribute_name use translations for model names and attribute names if available in the activerecord.models scope. They also support translations for inherited class names (e.g. for use with STI) as explained above in "Error message scopes". +

      +
      • +
    • +

      +ActiveRecord::Errors#generate_message (which is used by ActiveRecord validations but may also be used manually) uses human_name and human_attribute_name (see above). It also translates the error message and supports translations for inherited class names as explained above in "Error message scopes". +

      +
      • +
    • +

      +ActiveRecord::Errors#full_messages prepends the attribute name to the error message using a separator that will be looked up from activerecord.errors.format.separator (and defaults to ' '). +

      +
      • +
    +

    5.2.3. ActiveSupport methods

    +
      +
    • +

      +Array#to_sentence uses format settings as given in the support.array scope. +

      +
      • +

    6. Customize your I18n setup

    @@ -868,16 +1048,75 @@ http://www.lorenzobettini.it http://www.gnu.org/software/src-highlite --> 
    I18n.t :foo, :raise => true # always re-raises exceptions from the backend
    -

    7. Resources

    +

    7. Conclusion

    +
    +

    At this point you hopefully have a good overview about how I18n support in Ruby on Rails works and are ready to start translating your project.

    +

    If you find anything missing or wrong in this guide please file a ticket on our issue tracker. If you want to discuss certain portions or have questions please sign up to our mailinglist.

    +
    +

    8. Contributing to Rails I18n

    +
    +

    I18n support in Ruby on Rails was introduced in the release 2.2 and is still evolving. The project follows the good Ruby on Rails development tradition of evolving solutions in plugins and real applications first and then cherry-picking the best bread of most widely useful features second for inclusion to the core.

    +

    Thus we encourage everybody to experiment with new ideas and features in plugins or other libraries and make them available to the community. (Don’t forget to announce your work on our mailinglist!)

    +

    If you find your own locale (language) missing from our example translations data repository for Ruby on Rails

    +
    +

    9. Resources

    +
    +
    +

    10. Authors

    +
    +
      +
    • +

      +Sven Fuchs[http://www.workingwithrails.com/person/9963-sven-fuchs] (initial author) +

      +
      • +
    • +

      +Karel Minarik[http://www.workingwithrails.com/person/7476-karel-mina-k] +

      +
      • +
    +

    If you found this guide useful please consider recommending its authors on workingwithrails.

    -

    8. Footnotes

    +

    11. Footnotes

    [1] Or, to quote Wikipedia: "Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text."

    [2] Other backends might allow or require to use other formats, e.g. a GetText backend might allow to read GetText files.

    [3] One of these reasons is that we don’t want to any unnecessary load for applications that do not need any I18n capabilities, so we need to keep the I18n library as simple as possible for English. Another reason is that it is virtually impossible to implement a one-fits-all solution for all problems related to I18n for all existing languages. So a solution that allows us to exchange the entire implementation easily is appropriate anyway. This also makes it much easier to experiment with custom features and extensions.

    -

    9. Changelog

    +

    12. Changelog

    Lighthouse ticket

    -- cgit v1.2.3