New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
i18n lookup is not performed on nested models #48
Comments
Can you please give more information? How is your model? How is your simple_form_for call? Can you produce a failing test case? |
The case is pretty simple, I think. There is a User model (devise model) which has_one UserProfile, and UserProfile belongs_to User. User "accepts_nested_attributes_for" UserProfile, and User has attr_accessible :profile. The form looks like this:
|
Err, except that your example would raise a NoMethodError? :) Do you mean profile_form.input :first_name? Also, which keys are you expecting it to bring from I18n? Which ones is it bringing instead? The more information you give about an error the easier for it to get fixed. |
Ok. My mistake. The form says <%= profile_form.input :firstname %>
In fact it does not bring any translation from locale yml. |
Now I see your problem. This is done on purpose because when you have a nested attribute, simple form will look at simple_form.labels.user.user_profile.firstname, allowing you to have custom names for nested attributes. If you want however to use the same firstname across all labels, one alternative is to change the human_attribute_name instead (using I18n API for Rails itself) Please try to include the maximum information possible when reporting a bug or issue. Since this really helps us to understand what is happening. |
Thanks and can you clarify something here? You should use a "model name" or "association name" as a key in locale when writing translations. For example, if the association is like: class User < ActiveRecord::Base then locale yml should look like this? en: ? |
Let's look at the source code: http://github.com/plataformatec/simple_form/blob/master/lib/simple_form/inputs/base.rb#L119 SimpleForm uses the object_name. You can retrieve it by doing <%= profile_form.object_name %> inside your fields_for and I believe it will return: "user_profile" instead of "user.profile". Not exactly what I said, but the result at the end is the same. Could you please confirm? Notice I18n allows you to shortcut to translations, so you can eventually do this:
This will link user_profile to the translations for labels profile. |
<%= profile_form.object_name %> |
Ugh. It seems like a rails bug. Which Rails version are you using? object_name should return the underscore version. :( |
Please use the human_attribute_name translation while I investigate this issue. :) Thanks! |
I am using Rails 3 on ruby-1.9.2 |
I also have this problem with Rails 3 on Ruby 1.9.2 with simple_form 1.2.2. You can use this format and it works OK but the underscore version would be prettier :-) :
|
Vesan : You can also redirect everithing nested to the original translation # config/locale/models/address/fr.yml fr: simple_form: hints: address: address_1: "Spécifiez votre numéro d'appartement au besoin" address_2: "Ce champ est facultatif" postal_code: "i.e. H0H0H0" # config/locale/models/lead/fr.yml fr: simple_form: hints: lead[address_attributes]: :"simple_form.hints.address" |
I also have a similar problem with a "has_many" association, nevertheless I cannot use this solution because the object_name returned by Rails for this kind of association includes an index (so, redirecting for each index is not an alternative). My test code is something like this:
with the result: Someone has any idea about how to work with this? I think even if it's a Rails bug, including the orginal model attributes in the translation lookup queue in the SimpleForm::Inputs::Base#translate method could help... |
The reason object_name is the way it is, is because of the code here: https://github.com/rails/rails/blob/master/actionpack/lib/action_view/helpers/form_helper.rb#L1281
The index get's appended a few lines below that: output << fields_for_nested_model("#{name}[#{explicit_child_index || nested_child_index(name)}]", child, options, block) |
Yeah, I think SimpleForm will need to manipulate the object_name and get a readable version from it. |
The above will return an array of model names. For example: route[blocks_attributes][0][blocks_learning_object_attributes][1][asdf_attributes] will result in: ["route", "blocks", "blocks_learning_object", "asdf"] Not immediately obvious to me how to integrate this in the SimpleForm::Inputs::Base.translate method. |
You can add a new lookup in the SimpleForm::Inputs::Base.translate method using this result. |
Sounds a good idea, guess I'll give it a show when I find some time here. This keeps bothering me once in a while. Thanks. |
so is the current status of this still to translate nested models, the format of |
Improve i18n lookup for nested models, closed by 25abdac |
@jpzwarte I've used your scan method to improve the i18n lookup for nested models, it should be working fine now. Could you guys please test with the master branch? Thanks. |
Thanks a lot! |
I've tried every sollution here, but still not working.
|
not working with rails 3.2 and ruby 1.9.3. |
@caarlos0 hi, what version of simple_form are you using? Could you push a simple app to github that reproduces this issue? |
version: 2.0.2 form is like this:
pt.yml like this:
I tried several things... nothing works. |
@caarlos0 hrm, I think here <%= f.simple_fields_for :child_attributes do |ff| %> you should use <%= f.simple_fields_for :child do |ff| %> no? |
ooops, my mistake. Hey, maybe you can add something about this in docs, huh? Thanks anyway. |
So does it work now? If so I don't think we should add something to SimpleForm's docs as |
hmm.. yeah, that's right.. sorry, I'm new on ruby/rails, when I research for nested forms I didn't find this documentations.. so, thank you again for the link :) |
no problem :) |
When using simple_fields_for helper (for a nested model) labels, hints etc. are not loaded from the locale.
The text was updated successfully, but these errors were encountered: