Skip to content
GitLab

Fix i18n inconsistencies in forms for associations

Closed Administrator requested to merge fix-associations-i18n-inconsistencies into master

Created by: cpytel

Fixes #1105 (closed). As described in #1105 (closed), 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.