This is looking great @elia! 🙌

I'm a bit late to the party, but what about using a dot as a way to disambiguate between local and global I18n?

app/components/example_component.yml

en:
  hello: "Hello world!"

To access the local translation:

app/components/example_component.html.erb

<p><%= t(".hello") %></p>

To access a global translation

<%= t("my.global.translation") %>

So if a global translation is shadowed by the sidecar file you just have to drop the dot:

app/components/example_component.html.erb

<%= t("hello") %>

Seems very Railsy to me but maybe I'm missing something?

@Spone @joelhawksley that's surely feasible, although I have some concerns about that:

1. introducing more complexity, either by copying some code from the Rails own TranslationHelper, the current implementation is super simple, if we want to have it to mimic Rails maybe we should just use Rails and move back to something more like Sidecar translations #552
2. t(".my-key") already has a meaning in Rails, I'm not too concerned, since I don't expect it to be a very popular feature, but we should probably add instructions on how to get the original behavior
3. how likely it is to have a key shadowed by the component's translations? my purely speculative guess: not very often

I don't necessarily oppose doing that, but I lean more toward keeping things simple, adding features later, if required.
What are your thoughts?

One of the first things I tried was to include the original TranslationHelper and have it point to the components I18n. That is actually easier said than done, the helper is full of I18n references and the I18n library itself was built to be global.

I don't necessarily oppose doing that, but I lean more toward keeping things simple, adding features later, if required.

I totally agree. Let's just keep in mind that changing how locale lookup works in a future version of view_component could be a massive breaking change, and migration would be painful in some cases...

For the sake of the argument, I'm taking the point of view of a developer using view_component here, regardless of the internal implementation (whose complexity has obviously to be considered).

t helper lookup behavior

As stated in the docs, let's follow the principle of least surprise. If I read the code of a project using view_component, and I see this anywhere:

t("hello")

knowing Rails conventions on translations lookup, I would expect it to reference the hello key at the root of the global locale file. It would be surprising that this code looks up at the root when in a controller or view, but in the component sidecar locale file if it's in a component class or template.

If I see this:

t(".hello")

I know that a "lazy" lookup is used, so I'll look a the file structure to figure out what the path to the translation key is. Lazy lookup, that can be used in controllers and views, could be likened to a "local lookup".
In the current version of view_component, calling t(".hello") from ExampleComponent will look up en.example_component.hello, so it can actually also be used in components already (but without strict isolation).

Switch between global and local translations

In a component, seeing both helpers.t/I18n.t (for global translations) and t (for local translations) could be surprising, especially because you usually pick the former only when you don't have access to t in the current context (eg. in a decorator, in a service object...). Without reading view_component documentation, I would consider this a lack of consistency in coding style, and not necessarily infer that it triggers a different lookup behavior.

Compare it to t("hello") vs. t(".hello"): it shows a clear intent.

Side note : where to put translations

In some projects, I prefer to put my translations in multiple small files, matching the structure of the project (it's easier to find the key you're looking for). Alternatively, especially when I'll need to request translations from other people, it makes more sense to have them all in config/locales/en.yml.

view_component could enable both solutions with t(".hello") by:

• looking up the key hello in the sidecar locale file first,
• then, if not found, look up the namespaced key globally at example_component.hello (current behavior)

But is it still real isolation? 🤔

Is it still real isolation?

Probably doesn't matter, the worst that can happen is that we change the title of this PR 😄

@Spone I've been sitting on your comment for 3 days, pondering how could we possibly do that in a way that makes sense for the consumer of this API and the code that needs to implement it. Below I tried to summarize what we're trying to accomplish and the problems we need to overcome.

Desired features

It seems like what we want is:

1. having the lazy lookup as the preferred way to get the sidecar translations
2. have it fall-back on the lazy lookup in Rails
3. have the sidecar translations unreachable from anywhere else in the application

Current issues

I would add the following as issues, but @BlakeWilliams and @joelhawksley please check if these are things we don't want to worry too much about:

• try to avoid duplicating existing Rails functionality
  Would be quite easy to copy and paste the TranslationHelper from Rails along with its tests, do a few tweaks and make it work. I'm not how well that would work with:

  • supporting different Rails versions and potentially diverging implementations
  • maintaining all that code and keeping up with changes in Rails

• acknowledge the fact that the I18n library is global in nature
  I had to find out this about the I18n library at my own expense while working on this PR, in multiple occasions I had to fight the fact that I18n really likes to rely on the ::I18n constant for many things. That's why I ended up using just a backend instead of an isolated I18n instance… because there's no such thing! 😅

Open questions

• in which direction we want to proceed?
• on which features we're ready to compromise?
• how much this can become it's own thing (vs. relying on Rails)?

Especially if we want to use the "lazy lookup" I'd say we need to rely on Rails, which in turn means that we need to keep the sidecar translations global either respecting the virtual_path of the templates or adding our own view_components scope.

I'm interested in your thoughts on this, but also on alternative approaches I might have missed.

@Spone @BlakeWilliams I just pushed an additional commit with an attempt at isolated lazy path translations for components.

I also dropped support for multiple translations using the t/translate helper directly in the component, that can be added back, either now, or down the road. In this case I think we're on a good long term path for improvements (unlike changing from lazy to non-lazy and vice-versa, as pointed out by @Spone), and we're free to ship a minimalistic version initially.

What else can change to have this ready for a merge? / What other criteria should it meet?

@elia I have a small favor to ask you ❤️

Might you be willing to open a separate PR introducing _sidecar_files? I'd love to use it on a PR I'm working on 😄

@joelhawksley sure, will take just a minute 👍

@joelhawksley there you go #676

OT is there a reason for sticking with bundler v1?

OT is there a reason for sticking with bundler v1?

I think it's due to how many Ruby/Rails versions we support in CI?

Thanks for your work on this PR @elia!

Thanks for making the final changes and merging!