Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


When nested object is namespaced, i18n key is invalid ("namespaced" too) #900

stevo opened this Issue · 10 comments

3 participants



Shop::Project has_many Shop::Products

instead of looking for


it will look for


Probably changing

model_name, nested_model_name = normalize_model_name(self.model_name.underscore)


model_name, nested_model_name = normalize_model_name(self.model_name.demodulize.underscore)

should solve the problem


Would love to see a pull request for this!


This one is going to be tricky! I've had a play around in the code, but I think we first need a decent plan of attack.

We'll need to decide if it's best to remove the namespace as suggested above, or include it in a better way. Using the example above, we currently look for Alternatives might include ignoring the namespace (labels.project.product) as @stevo suggested, or using it as part of the key (e.g.

Assuming we have a solid view on what the right key is, we might need to support the existing behaviour ( as well (am I right that this currently "works", but isn't ideal?) and deprecate it over time. If the current way simply doesn't work, that'd be nice :)

I've bumped this out of 2.3.0 as a work-around exists and was documented in #964, and because I don't think there's a solid plan here yet.


@justinfrench justinfrench added this to the 3.0 final milestone

Proposed plan forward for the above example:

  1. search first
  2. fallback to labels.project.product
  3. warn or deprecate

Given @stevo reported that reported that this is an invalid key, it doesn't feel like there's any deprecation to be done. It's just a fix which could be applied to 2.3-stable, 3.0-stable and master.

Any thoughts before I try to implement?


SimpleForm seems to have landed on labels.project.shop_product to avoid multiple lookups, so I see no reason not to take the same approach at this point.

@justinfrench justinfrench modified the milestone: 3.1, 3.0 final

Rails is using slashes in i18 keys.
Nesting them by dots proved difficult and had to be changed in 3.2. (like

I would be for using the absolute names everywhere. It is obvious and explicit.

@justinfrench justinfrench modified the milestone: 3.2, 3.1

@mikz it isn't clear to me how to get this resolved. If Rails supports slashes, feels like we should do the same. If we choose to do the same, do we need to do any work?


Considering the original issue, I think Rails would try:
We would review if Formtastic is using ActiveModel::Naming#i18n_key everywhere and if not, use it.
That should keep it consistent with upcoming Rails versions.


@mikz would there be any change in Formtastic behaviour that you're aware of? If there's likely to be any subtle changes, I'd prefer to bump this out to 4.0. If it's okay for 3.2, maybe I'll start by adding tests to check existing behaviour?


I18n allows fallbacks which could be used, so for sake of gradual change it should be done in phases. It would be hard to how a deprecation message though. But the final change should be definitely for 4.0. The 3.2 would be just adding support for the 'rails consistent' mode. (unless it is already consistent, dunno).


I just tried this with Formtastic master (~3.1.1) and Rails 4.1.6:

        title: Foo

# app/views/nested/posts/new.html.erb
<%= semantic_form_for @nested_post do |f| %>
  <%= f.inputs :title %>
<% end %>

The form correctly rendered the label for the :title as "Foo", there's no deprecation or i18n key errors, and this behaviour is consistent with how Rails translates nested models, so I'm closing this issue for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.