Relative keys from root folder not detected

[fpietka]

I have multiple keys defined as .my_translation_key in a model for example, but those keys are in the root of my yaml files.

It works in Rails, and get translated correctly, but using i18n-tasks, those keys are detected in both missing my_translation_key and unused .my_translation_keys.

I tried both path and relative_roots in search configuration, with no luck. I would prefer not to have to rewrite those as they are working. Maybe am I missing something here?

[davidwessman]

@fpietka Can you give an example of a YAML-file with the translations and a small model where you call it?

[wollistik]

@davidwessman I think I have a similar issue: ViewComponents (https://viewcomponent.org) is a framework from Github for building reusable view components for use with Rails. One core concept is that code (a simple Ruby class) and view template (ERB file) reside side by side in the same directory. So the files for a MyComponent class would result in

app/components/my_component.rb
app/components/my_component.html.erb

With the latest release they included a translation feature, which will lookup relative translation keys in a translation file side to side with the other component files. So now it looks like this:

app/components/my_component.rb
app/components/my_component.html.erb
app/components/my_component{.locale}.yml

The key point is, that in this translation files there are no other root keys except the language. The component class/path is omitted, so everything is under root:

# Content of app/components/my_component.yml
en:
  some_key: ...

and the view view I can use

<%= t('.some_key') %>

You can find the documentation of this feature here: https://viewcomponent.org/guide/translations.html

When configuring i18n-tasks to also read the component translations files and check the usages this will end up all component keys are at root level. The health tasks would then report an unused key some_key and a missing key for my_component.some_key.

Since ViewComponent grows in popularity and there were already related issues (see #452 ) this should be proper supported. I think a new configuration option to infer additional keys from file/path would solve the issue. When this option is set for e.g. app/component every encountered translation hash would be enriched with the path and the hash will result in

{
  en: {
           my_component: { some_key: some_value }
        }
}

This must be reverted of course when the files get written.

What do you think?

[davidwessman]

Thank you for great summary and feedback @wollistik I think this relates to the feedback from palkan in https://github.com/github/view_component/issues/892, e.g. that it works poorly with translation services and similar.

I cannot see how i18n-tasks can support reading translations with custom roots from app/components in a simple way, it will be a large change.

@glebm What do you think about native support for ViewComponent?

E.g. finding:

# app/components/event_component.en.yml
en:
  key: Special translation

translating this to en.event_component.key or even en.event_component.key when reading all translations and then write it back to correct location after normalize.

[glebm]

If we can't find a simple way to make this configurable, a plugin/special support for ViewComponent makes sense

One issue I can foresee is that the keys don't seem to share a common prefix (e.g. components.), so routing new keys to the correct files automatically in a general way may be tricky. So pattern_router won't work well but conservative_router should.