Fix i18n inconsistencies in forms for associations #1192
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cpytel
commented
Jul 20, 2018
| @@ -20,7 +20,7 @@ and is augmented with [Selectize]. | |||
| %> | |||
|
|
|||
| <div class="field-unit__label"> | |||
| <%= f.label field.attribute_key, field.attribute %> | |||
| <%= f.label field.attribute, for: "#{f.object_name}_#{field.attribute_key}" %> | |||
There was a problem hiding this comment.
If there is an existing Rails helper I can use to generate this label key, I think that would be nice, but I couldn't find one.
cpytel
commented
Jul 20, 2018
| @@ -18,7 +18,7 @@ The form will be rendered as nested_from to parent relationship. | |||
|
|
|||
| <%= f.fields_for field.attribute, field.data || field.nested_form.resource.class.new do |has_one_f| %> | |||
| <fieldset class="field-unit--nested"> | |||
| <legend><%= field.nested_form.resource_name.titleize %></legend> | |||
| <legend><%= t "helpers.label.#{f.object_name}.#{field.nested_form.resource_name}", default: field.nested_form.resource_name.titleize %></legend> | |||
There was a problem hiding this comment.
If there is an existing Rails helper or class method I could use to generate this i18n key, that would be nice, but I looked and couldn't find one.
spec/example_app/config/database.yml
Outdated
| @@ -1,4 +1,5 @@ | |||
| development: &default | |||
| host: localhost | |||
There was a problem hiding this comment.
Was this necessary to get up and running? Should we include this in this PR, or elsewhere?
|
Yes, it was necessary for me, but this is because of my computer config. I meant to remove it before opening the PR, but forgot. Thanks for catching, I’ve removed it in bc37606.
…---
Chad Pytel, Developer and CEO
617-482-1300 x113
https://thoughtbot.com
https://twitter.com/thoughtbot
On Jul 20, 2018, at 3:43 PM, Nick Charlton ***@***.***> wrote:
@nickcharlton commented on this pull request.
Looks good! One minor comment.
I'm willing to ignore CI failures as they're dependency warnings that'll get fixed elsewhere.
In spec/example_app/config/database.yml <#1192 (comment)>:
> @@ -1,4 +1,5 @@
development: &default
+ host: localhost
Was this necessary to get up and running? Should we include this in this PR, or elsewhere?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#1192 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAATlwytvxJZcd67FCL5PmnqTXibff3Xks5uIeyQgaJpZM4VYHIJ>.
|
Fixes #1105. As described in #1105, there are some inconsistencies in the way Administrate handles labels for `HasMany`/`BelongsTo`/`HasOne` associations. * `HasMany` (eg: `Order#line_items`) - Gives "line_items" as the label - No i18n. * `BelongsTo` (eg: `Customer#country`) - Defaults to "Country code" (similar to "Country id" in this case). - Allows i18n as `helpers.label.customer.country_code`. * `HasOne` (eg: `Product#product_meta_tag`) - Gives "Product Meta Tag". - No i18n. The behavior of the `BelongsTo` field is most correct, and is preserved in this commit. The behavior of `HasMany` and `HasOne` has been improved as follows: * `HasMany` (eg: `Order#line_items`) now no longer overrides the text given to the `label` helper, and passes the attribute name. This results in a default label of "Line items" and one that can be overridden with i18n with a key at the standard location (`helpers.label.order.line_items`) * `HasOne` (eg: `Product#product_meta_tag`) now can be overriden with the key `helpers.label.order.line_items`. The `HasOne` is rendered into a nested form, inside of a fieldset and with a legend. The text of the "label" in this nested form is actually in a legend tag. I considered the fact that this was not using the `label` helper, whether it should be switch to a label from a legend, or whether we should have a non-standard i18n key. In the end, I decided that the least surprising behavior would be to customize the "label" for that attribute at the expected label's i18n key.
cpytel
force-pushed
the
fix-associations-i18n-inconsistencies
branch
from
bc37606
to
11a9b22
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1105. As described in #1105, there are some inconsistencies in
the way Administrate handles labels for
HasMany/BelongsTo/HasOneassociations.
HasMany(eg:Order#line_items)BelongsTo(eg:Customer#country)helpers.label.customer.country_code.HasOne(eg:Product#product_meta_tag)The behavior of the
BelongsTofield is most correct, and is preservedin this commit.
The behavior of
HasManyandHasOnehas been improved as follows:HasMany(eg:Order#line_items) now no longer overrides the textgiven to the
labelhelper, and passes the attribute name. This resultsin a default label of "Line items" and one that can be overridden with
i18n with a key at the standard location (
helpers.label.order.line_items)HasOne(eg:Product#product_meta_tag) now can be overriden withthe key
helpers.label.order.line_items.The
HasOneis rendered into a nested form, inside of a fieldset andwith a legend. The text of the "label" in this nested form is actually
in a legend tag. I considered the fact that this was not using the
labelhelper, whether it should be switch to a label from a legend, orwhether we should have a non-standard i18n key. In the end, I decided
that the least surprising behavior would be to customize the "label" for
that attribute at the expected label's i18n key.