Rails Localization Plugin Release Version 0.9

Just a quick note to tell that I released version 0.9 of the L10n-simplified plugin. It has been a year since last release, but I had nohurry since the last version already fit for Rails 2.0.

One of the nice changes for this release is that you can now set your localized language in the environment.rb file like this:

L10N_LANG = :da #or whatever language/locale you wish

Download the relase 0.9 from Rubyforge

Supported languages

* Czech
* Danish
* Dutch
* English (for running test cases and comparing to normal texts)
* Finnish
* French
* French (Canadian)
* German
* Italian
* Korean
* Norwegian
* Portugese
* Russian
* Serbian
* Spanish
* Spanish (argentinian)
* Swedish
* Swedish Chef, and
* Pirate talk (just for the fun of it)
* any other language you want. Just dump your translation in the /lib folder

Full changelog:

* — release 0.9 (2008-01-13) —
* Possible to set language in environment.rb: L10N_LANG = :de
* UTF-8 database charset configuration is default in Rails 1.2+ and 2.0, so not needed in plugin more.
* L10n-Simplified plugin also available as gem from this release
* Moved changelog from README to separate file changelog.txt
* Removed duplicate line from lang_de.rb
* Russian translation (thanks Denis Pankratov)
* Corrected German date/time format (thanks Christian W Zuckschwerdt)
* Added Portugese translation (thanks Carlos Afonso)
* Italian translation adjustments (thanks Michele Franzin)
* Fixed translation error in Swedish translation (thanks Ingemar Edsborn)
* Czech translation by Karel Minařík
* French lang file updated (thanks Bruno Michel)
* Added Serbian (thanks Slobodan Kovacevic)
* Lang_it file must be UTF-8 encoded (thanks Fabio Bonelli)
* Added rake task for creating a release “rake package”
* Fixed rake task for generating rdoc in UTF-8 format
* Added Norwegian (thanks Fredrik Bach)

More info:

Technorati Tags: , , , , , , , , , , , , , ,

13 Responses to “Rails Localization Plugin Release Version 0.9”

  1. Hans Says:

    I am using localization_simplified and tries to combine it with the plugin Localization. They work very well together and result in both localization of application strings in the views and localization of inbuilt strings.
    However in order for the user to select language after login I would like to be able to set the language in localization_simplified from the controller. Is that possible ? Any thoughts on how that could be done ?

  2. Jesper Rønn-Jensen Says:

    @Hans: No way to change files dynamically as of present.

    The lang file is required into the code. If you were to change that, you should change the load structure.

    First, each lang-file should load it’s own namespace. Then you should be able to select language on a per-request basis.

    You are welcome to give it a try. If you find a way to do it, I’m open to putting it into the next version — as long as it won’t slow down the plugin exteremely

  3. lolo Says:

    In Rails 2.1.0 RC1, I’m getting “uninitialized constant Rails::Plugin::L10N_LANG (NameError)”. Setting the constant in environment.rb (or initializers/something.rb) doesn’t help. This helps:

    L10N_LANG = :languagecode

    ( = instead of ||= ) in init.rb

  4. Hasan Rahman Says:

    Great plugin! Just what I needed, keep it up.

  5. Hans Says:

    Iolo is correct. Init file should be changed to L10N_LANG = :languagecode in order to work

    It is a great plugin, but I have some problem with using it as in the error messages the variable or attribute names are not translated.
    I tried to do that by using my own version of full_messages incorporating localization translation method, but failed as I not know when and where you change from the original messsage to the translated
    Any idea how to separate out the name of the attributes

  6. Jesper Rønn-Jensen Says:

    @lolo and @Hans. I would gladly fix init.rb right away, but before I do, help me out with this:

    I really prefer if the plugin could be overwritten later with a recent version. And plugins work best if we can keep them pristine with no project specific changes. Therefore I wanted to be able to place the settings like L10N_LANG in more appropriate places.

    Any suggestions on how I could honor that principle and still make the code work ‘out of the box’?

  7. Hans Says:

    maybe you can solve it as in the localization plugin. They has an attribute in there localisation module named lang and you can set that attribute Localization.lang=:se in your controller. Maybe it could be possible to set LocalizationSimplified.l10n_lang in an controller.
    How about my problem concerning translating the attribute names

  8. Jesper Rønn-Jensen Says:

    Hans, feel free to submit a patch for your suggestion — currently i’m almost off on vacation (later this week). I’ll gladly commit any patches I recieve Thursday at the latest.

    Concerning translation of attribute names, that feature is not implemented in LocalizationSimplified.In a previous project, I used Danish model + attribute names and added the proper pluralization rules in inflections.

    That worked fine, so that’s an option if you can live with translated model/attributes.

  9. Hans Says:

    I don’t dare to use localized attribute names in the models as rails and ruby are based on English conventions. I therefore prefer another solution that performs the translation as the last step before displaying the word. However, this solution is more like a fix and there should be better solutions. Anyhow, here is my path, that works for me. More pathes may follow regarding the other parts of your plugin as date etc.

    def error_messages_for(*params)
    options = params.last.is_a?(Hash) ? params.pop.symbolize_keys : {}
    objects = params.collect {|object_name| instance_variable_get(“@#{object_name}”) }.compact
    count = objects.inject(0) {|sum, object| sum + object.errors.count }
    unless count.zero?
    html = {}
    [:id, :class].each do |key|
    if options.include?(key)
    value = options[key]
    html[key] = value unless value.blank?
    html[key] = ‘errorExplanation’
    messages = ActiveRecord:: Errors.default_error_messages
    header_message = format( messages[:error_header],
    pluralize(count, messages[:error_translation]),
    (options[:object_name] ||
    params.first).to_s.gsub(“_”, ” “))
    error_messages = objects.map {|object| object.errors.full_messages.map {|msg| content_tag(:li, msg) } }

    # Patch do translate variablenames with localisation plugin
    # Own error messages (:message => Example) had to be translated in the validation specification (:message => _(Example))
    # error_messages_string=error_messages.join(‘%’)
    error_messages.each_index do |ix|
    error_messages[ix].each_index do |jx|
    objects.each do |object|
    object.attributes.each_key do |attribute|
    translated_variable=_(variable) #Translation method in Localization plugin
    error_messages[ix][jx]= error_messages[ix][jx].gsub(‘confirmation’,_(‘confirmation’)) #Fix to handle password confirmation, that not is an attribute ?
    # end patch

    content_tag(options[:header_tag] || :h2, header_message) <<
    content_tag(:p, messages[:error_subheader]) <<
    content_tag(:ul, error_messages),


  10. Jesper Rønn-Jensen Says:

    Hans. thanks a lot for the patch — i’m very sorry i did not manage to commit your patch before my vacation.

    I will give you commit access to the repository and want you to commit this patch in (as i’m on my way on vacation). Unfortunately i do not know your Rubyforge user account name. Please send me.

    This way you will also have access to commit in future patches. (this is actually the idea of Rubinius’ Evan Phoenix and i am very inspired by opening up the code to everybody interesting to contributing :)

  11. Hans Says:

    Hi !
    Do I just add my patch as a file or are there more formal ways to add the patch?
    My Rubyforge user account is marmolin.

    I will now try to make it possible to change language dynamically, I do not really know how as I hope to find a solution that can work as an option, without changing your original plugin too much. I am just looking at rubys possibilities for dynamic compilation.
    Do you have any suggestions ?

  12. Jesper Rønn-Jensen Says:


    i have now added you on RubyForge as administrator (along with casperfabricius).

    You don\t have to add a patch… just apply it in the relevant file(s). Also, make sure to add the commit comment + date + author in the changelog file as well when you commit

    Thanks a lot for putting effort into it :)

  13. Mosfet Says:

    Webrick server can now launch, but an error occurs in an edit rendering:

    ArgumentError in Opes#edit

    Showing app/views/opes/edit.html.erb where line #13 raised:

    wrong number of arguments (4 for 3)
    Extracted source (around line #13):

    10: Date de relevé
    13: Date de l’opération
    14: Montant
    15: Libellé
    RAILS_ROOT: /Users/admin/Documents/Rails/MyMoney

    Application Trace | Framework Trace | Full Trace
    /Users/admin/Documents/Rails/MyMoney/vendor/rails/actionpack/lib/action_view/helpers/date_helper.rb:964:in `date_select’
    /Users/admin/Documents/Rails/MyMoney/vendor/rails/actionpack/lib/action_view/helpers/date_helper.rb:964:in `date_select’
    /Users/admin/Documents/Rails/MyMoney/app/views/opes/edit.html.erb:13:in `_run_erb_app47views47opes47edit46html46erb’
    /Users/admin/Documents/Rails/MyMoney/app/views/opes/edit.html.erb:12:in `_run_erb_app47views47opes47edit46html46erb’

    Any idea?