I18N: Attributes labels translation issue

[michaelkl]

Hello.

First of all, here's my locale/ru.yml:

ru:
  activerecord:
    attributes:
      user:
        email: Email
        password: Пароль
        password_confirmation: Пароль ещё раз
        name: Имя
        role: Роль
        provider: OAuth-провайдер

Now in my User dashboard on new/edit page (one which got the edit form) labels of attributes are displayed using thier translation from locale/ru.yml, but on index and show pages they are don't!

I've dived in sources and found out that on index page the translation is taken from helper.label section, not from the activerecord.attributes one.

I think translation sources should be unified all over Administrate pages and using activerecord.attribues section looks more straightforward to me.

Thank you.

[FerPerales]

@michaelkl I ran into this problem. So far, what I've done to avoid duplicated translations is this:

common: &commons
  patient:
    address: 'Direccion'
    weight: 'Peso (kg)'
    height: 'Altura (cm)'
    allergies: 'Alergias'
    patient_antecedents: 'Antecedentes del paciente'

And then, include &commons in

es:
  activerecord:
    models:
      attributes:
         <<: *commons

Hope it helps

[michaelkl]

@FerPerales Good workaround until the issue will have been fixed! Thank you!

[fikrikarim]

Any update on this? Thanks :)

[nickcharlton]

I'm closing this as the original issue is quite old and the translations have changed quite a bit since this was opened, please open another if this is still an issue.

[eppdot]

This issue still exists!

[pablobm]

Yup; I can reproduce.

I agree this is odd. I wonder what the original intent was, using helpers.label.RESOURCE_NAME.ATTR_NAME instead of activerecord.attributes.RESOURCE_NAME.ATTR_NAME.

Hm, thinking a bit more, I can see an edge case. In forms, fields will tend to match ActiveRecord attributes. On the other hand, in lists/shows there's a higher chance of showing other things, such as constructed attributes (eg: Customer#lifetime_value). I'm not sure if these make sense under activerecord.attributes.* (honestly don't know; perhaps it makes sense).

A potential idea would be to use a helper that tries for helper.label.*, then fall backs for activerecord.attributes.* if missing. I may be overthinking this though. I don't have enough experience with i18n to tell what the conventions are here.

Does anyone have experience with these? /cc @nickcharlton

[jubilee2]

@pablobm i think it's fixed on index page right?

[pablobm]

Indeed, I think it was fixed by https://github.com/thoughtbot/administrate/pull/1064/files :slightly_smiling_face:

Thank you for the heads up, @jubilee2. If anyone still sees this problem, please let us know and we'll reopen.

[lubieniebieski]

hi there! @pablobm I think that the PR #1064 you mentioned solved the issue partially - I can see a proper behaviour for show and index actions, however in form the i18n doesn't work correctly for Field::BelongsTo type. In case of Field::HasMany - everything works as expected.

Examples that fails to apply the correct translation inf form for Field::BelongsTo type:

en:
  attributes: 
    user: "Some translation for user belongs_to#1"

en:
 activerecord:
    attributes:
      post:
        user: "Some translation for user belongs_to#2"

[nickcharlton]

Hey @lubieniebieski, do you think you'd be able to contribute a PR for fixing the forms part of it?

[lubieniebieski]

hi @nickcharlton, I gave it a try in #2590 :)