This project is archived and is in readonly mode.

#2637 ✓wontfix
calavera

I18n, look up a translation with the default locale when it's missed with another specific locale

Reported by calavera | May 12th, 2009 @ 04:13 PM | in 2.x

I've added an I18n option to allow to look up a translation with the default locale when it's missed with another specific locale.

This is a useful option if you don't want your page will crash when misses a translation and you don't want to use the default option in each translation. It's inspired by the gettext behaviour.

For example, I have this code in an initializer:


  I18n.use_default_locale_on_missing_translation = true
  I18n.default_locale = :en

And two translation files, en.yml and es.yml:


  en:
    hello: 'hello'
    hello_world: 'hello world'
 
  es:
    hello_world: 'hola mundo'

When I execute this code:


  I18n.t :hello, :locale => :es

Rails returns hello instead of send an error

Comments and changes to this ticket

  • Pedro Pimentel (zukunftsalick)

    Pedro Pimentel (zukunftsalick) May 12th, 2009 @ 04:24 PM

    We were just looking for this kind of solution few days ago. For us is better to display english translation than displaying a missing key text.

    great

  • Luismi Cavallé

    Luismi Cavallé May 12th, 2009 @ 05:15 PM

    Globalize2 also has a very good solution for this problem: http://wiki.github.com/joshmh/gl...

  • Luismi Cavallé

    Luismi Cavallé May 12th, 2009 @ 05:15 PM

    Globalize2 also has a very good solution to this problem: http://wiki.github.com/joshmh/gl...

  • Raul Murciano

    Raul Murciano May 12th, 2009 @ 05:24 PM

    +1, nice patch! My users will also prefer an english text better than a "missing key" warning.

  • Cheah Chu Yeow

    Cheah Chu Yeow May 12th, 2009 @ 05:37 PM

    • Title changed from “[PATCH] I18n, look up a translation with the default locale when it's missed with another specific locale” to “I18n, look up a translation with the default locale when it's missed with another specific locale”
    1. All tests pass after applying your patch and the code in the patch looks good!

    This will be very awesome, I was just working on I18n not just yesterday and would have appreciated this a lot for production code.

  • Cheah Chu Yeow

    Cheah Chu Yeow May 12th, 2009 @ 05:39 PM

    Ugh I meant +1 in my last comment. I wonder how that got interpreted as a new ordered list item!

  • Manu Campos
  • Cheah Chu Yeow

    Cheah Chu Yeow May 12th, 2009 @ 06:12 PM

    • Tag changed from active_support, documentation, i18n, improvement, patch, test to active_support, documentation, i18n, improvement, patch, test, verified
  • José Valim

    José Valim May 13th, 2009 @ 08:03 PM

    We already had this discussion on the I18n group when we decided to not add this functionality. But since it was implemented as an option, +1 for me.

    The patch works here, but anyway I think it should be sent to the Rails I18n tracker:

    http://i18n.lighthouseapp.com/projects/14948-rails-i18n/tickets?q=all

    It would be nice to check if it works on Rails setup as well (it probably works by default):

    config.i18n.use_default_locale_on_missing_translation = true
    
  • calavera

    calavera May 13th, 2009 @ 09:16 PM

    Yep, I didn't know there were a separate project. I'm sending it to the I18n tracker as well.

    It already works on Rails setup by default, this is the code that initialize the I18n options:

    @@@ruby configuration.i18n.each do |setting, value|

        if setting == :load_path
          I18n.load_path += value
        else
          I18n.send("#{setting}=", value)
        end
    

    end

    
    
  • sam

    sam May 14th, 2009 @ 02:48 PM

    Nice Job Calavera!

    Incidentally, this is one of the main reasons I still use Gettext, it allows me to concentrate on the main language and add translations progressively.

    Cheers, sam

  • Claudio Poli

    Claudio Poli May 15th, 2009 @ 12:18 PM

    Would love to see it implemented, as an option is the way to go.

  • Emili Parreño

    Emili Parreño May 18th, 2009 @ 08:38 AM

    +1 nice! I like this patch, very usefull.

  • Sven Fuchs

    Sven Fuchs July 8th, 2009 @ 07:26 PM

    • State changed from “new” to “wontfix”
    • Assigned user set to “Sven Fuchs”

    Clearly, -1 on this patch.

    For one thing it changes the shipped I18n gem so any changes should obviously be applied over there.

    Also, fallbacks can be a hairy issue. If hardcoding anything you'd at least want to provide support for falling back from, e.g., de-DE to de, but then quickly get into various special cases (e.g. Scandinavian locales). So in the end you'll want to let the user customize fallback rules.

    Globalize2 ships support for this and you can use the fallback stuff separately from the rest of the library. If Globalize2's fallback support is not good enough I'd suggest either improving it or implementing your needs as a different plugin.

    All that said, of course I can see we'll want to provide this kind of support (as an optional module) in the I18n gem. But I'd want to proceed on our conservative route of cherry-picking proven things from plugins or other battle-tested solutions.

  • Francesc Esplugas

    Francesc Esplugas July 8th, 2009 @ 11:42 PM

    Sorry Sven but I don't agree on deciding that this wont be fixed.

    Having a fallback language it's something Gettext has been doing for ages and I18n should do the same by default, in fact there's a lot of people who expects this behavior.

    Meanwhile I've extended the object class to achieve the behavior I wanted to have.

    class Object
    
      def _(msg, *args)
        options = args.extract_options!
        options[:default] = msg
        I18n.t(msg, options)
      end
    
    end
    
  • Sven Fuchs

    Sven Fuchs July 8th, 2009 @ 11:54 PM

    Francesc, I'm sure a lot of people use fallbacks. That doesn't mean it must be included to Rails though right now though. Rails I18n was built to support no other locale than :en out of the box. The reason for this is that it can be incredibly hard to figure out "the right way" to do it - and Gettext is not always a good example.

    Please keep in mind that experimenting with advanced features in plugin-land, then comparing solutions, maybe cherrypicking a few things from the best breeds and then including them into the I18n lib in a defensive way is part of the plan :)

    Does Globalize2 fallback support solve your problem? If so we should better document (e.g. in the I18n guide) that it's there and how it can be used. If not, please provide feedback so it can be improved.

  • Francesc Esplugas

    Francesc Esplugas July 9th, 2009 @ 08:03 AM

    In my opinion falling back to the message user has provided if no translation available it's a good solution, this makes me think that although my application is in english I always have to translate it creating locale files. In my opinion:

    t("Hello World") should become "Hello World" if no translation available.

    Users don't have to see those "missing translation" & "en, Hello World" warnings.

    Gettext maybe it's not a good example, but makes sense to return the same message if no translation is available. (Other thing is how it's implemented)

    (I must say I understand it's hard to figure the right way to do it.)

  • Ryan Bigg

    Ryan Bigg October 9th, 2010 @ 09:44 PM

    • Tag cleared.
    • Importance changed from “” to “Low”

    Automatic cleanup of spam.

  • bingbing

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Attachments

Pages