Rails Ruby on Rails → 2.x

Comments and changes to this ticket

• You flagged this item as spam.
  

  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

• You flagged this item as spam.
  

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

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

• You flagged this item as spam.
  

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

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

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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.

• You flagged this item as spam.
  

  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!

• You flagged this item as spam.
  

  Manu Campos May 12th, 2009 @ 06:07 PM

  • 1, Nice patch.

• You flagged this item as spam.
  

  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 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
  

• You flagged this item as spam.
  

  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

• You flagged this item as spam.
  

  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

• You flagged this item as spam.
  

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

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

• You flagged this item as spam.
  

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

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

• 

  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.

• You flagged this item as spam.
  

  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 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.

• You flagged this item as spam.
  

  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 October 9th, 2010 @ 09:44 PM

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

  Automatic cleanup of spam.

• You flagged this item as spam.
  

  bingbing March 26th, 2011 @ 02:10 AM

  louis vuitton watches