Add base_field_translation_key to BaseResouce allowing fields to be nested localized

[djalmaaraujo]

trafficstars

Description

Currently Avo supports users to Localize Resources or Fields as in a root-level perspective. You can define translation_key for resources or each field, but you cannot tell avo to translate fields from a specific nested base point.

The proposed change allow users to continue to use the regular approach, but also adds the support for specifying where the fields from a specific resource will be localized.

This is useful for migrating big applications with other Admin capabilities, but also it allows users to have the same field name in different locations.

Fixes #1593

Checklist:

• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [x] I have added tests that prove my fix is effective or that my feature works

Screenshots

Manual review steps

1. Pull the branch
2. Change your avo.en.yml locale file

# lib/generators/avo/templates/locales/avo.en.yml
field_translations:
      status: Status Root
      project:
        status:
          zero: Status Nesteds
          other: Status Nesteds
          one: Status Nested

3. Inside class Avo::Resources::Project < Avo::BaseResource, write:

self.base_field_translation_key = "avo.field_translations.project"

4. Go to the dummy project /projects path
5. You should expect to see Status Nested as the table column instead of just Status

Output:

[qlty-cloud-legacy[bot]]

Code Climate has analyzed commit 1880802f and detected 0 issues on this pull request.

View more on Code Climate.

[djalmaaraujo]

@adrianthedev @Paul-Bob I think the tests should be in a unit-test matter, not in a browser related test, but I could not find a better example. Feel free to guide me on the best alternative.

[djalmaaraujo]

The name you suggested is great. I don't understand the issue with the project you mentioned. You can have both project and project status. The idea of the example is that you would nest project as a "group/model".

I will do one or two tests before asking for another review. 🤙

[adrianthedev]

The problem with field_translations.project.status is that someone might have the project field and that will be in conflict with the proposed naming scheme.

[djalmaaraujo]

The problem with field_translations.project.status is that someone might have the project field and that will be in conflict with the proposed naming scheme.

I might not get this right, but isnˋt the conflict ok? For example, if you have a global field translation for project, when you are on the specific resource, it will be overwritten by the specific, no? Again, I may be not getting what you are saying.

[adrianthedev]

The conflict is not an override from global to specific. The docs: https://docs.avohq.io/3.0/localization.html#localizing-fields

Let me show you the way the key is used and where the conflict might appear:

# How it is now
es:
  avo:
    field_translations: # the field translations holds the fields
      file: # field name
        zero: 'archivos'
        one: 'archivo'
        other: 'archivos'

# the override will break that
es:
  avo:
    field_translations:
      project: # this key is not a field anymore, but refers to a resource
        file:
          zero: 'archivos'
          one: 'archivo'
          other: 'archivos'
      project: # if this is a field it will clash with the `project` specified above
        zero: 'archivos'
        one: 'archivo'
        other: 'archivos'

# Proposed resolution
es:
  avo:
    resource_translations: # we are in the resource translation key, not `field_translation`
      project: # the resource
        zero: 'usuarios' # usual zero
        one: 'usuario' # usual one
        other: 'usuarios' # usual other
        fields: # add specific resource overrides here
          file:
            zero: 'archivos'
            one: 'archivo'
            other: 'archivos'

I propose using the resource_translations.RESOURCE_NAME.fields.FIELD_NAME key for resource-specific overrides

[github-actions[bot]]

This PR has been marked as stale because there was no activity for the past 15 days.

[adrianthedev]

@djalmaaraujo, I'd so love to see this go past the finish line! It solves a painful problem.

[github-actions[bot]]

This PR has been marked as stale because there was no activity for the past 15 days.

[adrianthedev]

I'd love to have functionality in Avo.

Closing for now to keep the queue free.