Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upFix i18n inconsistencies in forms for associations #1192
Closed
Conversation
@@ -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}" %> |
This comment has been minimized.
This comment has been minimized.
cpytel
Jul 20, 2018
Author
Member
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.
@@ -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> |
This comment has been minimized.
This comment has been minimized.
cpytel
Jul 20, 2018
Author
Member
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.
Looks good! One minor comment. I'm willing to ignore CI failures as they're dependency warnings that'll get fixed elsewhere. |
spec/example_app/config/database.yml
Outdated
@@ -1,4 +1,5 @@ | |||
development: &default | |||
host: localhost |
This comment has been minimized.
This comment has been minimized.
nickcharlton
Jul 20, 2018
Member
Was this necessary to get up and running? Should we include this in this PR, or elsewhere?
This comment has been minimized.
This comment has been minimized.
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.
bc37606
to
11a9b22
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.
cpytel commentedJul 20, 2018
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
)BelongsTo
(eg:Customer#country
)helpers.label.customer.country_code
.HasOne
(eg:Product#product_meta_tag
)The behavior of the
BelongsTo
field is most correct, and is preservedin this commit.
The behavior of
HasMany
andHasOne
has been improved as follows:HasMany
(eg:Order#line_items
) now no longer overrides the textgiven to the
label
helper, 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
HasOne
is 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
label
helper, 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.