#23 ✓resolved
mail (at arcasys)


Reported by mail (at arcasys) | April 1st, 2009 @ 10:41 AM

interpolate_with_deprecated_syntax currently replaces %d and %s with {{count}} and {{value}} respectively and issues a warning. This behaviuor doesn't solve the problem the sysntax change was intended for. Instead, interpolate must ignore %d and %s, i.e. let them pass unchanged. There can still be a compile warning.

Maybe I missed how I can force interpolate to use interpolate_without_deprecated_syntax? In that case I'd appreciate a hint.


Comments and changes to this ticket

  • Sven Fuchs

    Sven Fuchs July 5th, 2009 @ 10:55 PM

    Hi Hans,

    can you explain further why you think "behaviuor doesn't solve the problem the sysntax change was intended for"? Because I think it does :) People were previously using %s and %d as interpolation variables so they'll expect the variables count and value to be interpolated to these, no?

    I also don't really get your last question. Do you mean how you could bypass interpolate_without_deprecated_syntax?

  • mail (at arcasys)

    mail (at arcasys) July 7th, 2009 @ 08:40 AM

    Hi Sven,

    Before I answer your question I should clarify if I'm understanding 'deprecated' in the
    right way:
    In my understanding there can be several reasons to deprecate a syntax element:
    either there's a better or more understandable element
    or the old element was not sufficient for all use cases
    or the old element gets in the way of something.
    In the first two cases the old element could still be used and you're right to
    offer compatibility for the deprecated element.

    However, in the third case the old element made problems and must not be
    supported anymore. I'm not actually aware if there must be some time between
    deprecating an element and declaring it as unsupported.
    In my opinion 'deprecated' means; don't use this element any more because
    it has been replaced by something more adequate or because it doesn't work as
    expected or it is causing problems (hence the warning!)

    To answer your question:
    Still using %d (or %s, I havn't seen a case here but I'm sure there is one) gets in the
    way of formatting and localizing times and dates, e.g. in

       @start_date = params[:p_date] ? params[:p_date] : Date::today.strftime(t('date.formats.default'))
    date.formats.default delivers the string
    @@@ %Y-%m-%d @@@ leading to the following error when translate is applied:
    interpolation argument count missing in "%Y-%m-{{count}}"
    I think %d and %s were deprecated to have a clear distinction between variables used
    in localization strings and format elements like %d and %s.
    Unfortunately trying to keep backward compatibility leads to the errors.

    My last question simply referred to a way to bypass the %d/%s substitution which
    I commented out to solve my problem.


  • Sven Fuchs

    Sven Fuchs July 7th, 2009 @ 09:55 AM

    • State changed from “new” to “open”

    Hi Hans, thanks for the detailled explanation. I agree with your definition of "deprecation" and I think it perfectly applies to this case. I don't really see a real conflict between the "old and new way" so I'd say the second case applies: the old element was not sufficient for proper I18n.

    So, from what I understand this is just a bug. This line:


    probably should be:

      return string unless string.is_a?(String) && !values.empty?

    Right? So, it should assume you want the backend to interpolate values to the string only when you have passed values to the backend. (We've done some similar fix in the backend IIRC.) In your example you would not pass any values so the neither the interpolation nor the deprectation would kick in.

    Btw is there a reason why you do not use #localize for this?

  • mail (at arcasys)

    mail (at arcasys) July 7th, 2009 @ 10:24 PM

    Hi Sven, thanks for the fast reply.

    "so I'd say the second case applies" If you like. I thought about a jusification of my assessment but
    this might be much more sophisticated than important. So you're right.

    "Right?" Right. It took me a while to understand your approach but it appears to work fine.

    "Btw is there a reason why you do not use #localize for this?" I'd like to say because I hadn't found the bug then :-)
    But no, I've just missed some of the old style occurances.
    And #localize had the same problem because it finally uses the same function.
    Finally there's a case where you can't substitute translate with localize:

    unless you tell me better.


  • Sven Fuchs

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

    • State changed from “open” to “resolved”

    Alright, I've added a patch and ticket to Rails' lighthouse:


    Maybe you wanna +1 on that

    Closing this ticket, please reopen if the problem remains

  • mail (at arcasys)

    mail (at arcasys) July 20th, 2009 @ 01:03 PM

    Unfortunately I noticed there's still a problem:
    When used in a view the follwing happens:

    l(a_date, :format => 'date.formats.default')
    returns the string date.format.default instead of the formatted string

    Using translate instead of localize like

    also fails because 'values' is not empty in this case - the hash contains
    a string 'raised' out of some reason - so your fix doesn't work anymore


Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

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

Repository for collecting Locale data for Ruby on Rails I18n as well as other interesting, Rails related I18n stuff