Add support for I18n

[domingo2000]

Provide I18n Support

It would be great to have I18n translation support in the Rails addon. The main use cases when implementing internationalization with I18n are:

Use Cases

1. Read what the translation says. e.g., I18n.t("hello") returns en: "Hello World", es: "¡Hola Mundo!".
2. Find out if a translation is missing.
3. Locate where a translation is defined.
4. Create new translations.
5. Update translations (for a key, across one or multiple locales).

Idea

The goal of this issue (if you agree) is to build a simple implementation that addresses the use cases above, avoiding and solving some of the drawbacks we’ve encountered over the years.

Starting with point 1 in the list:

• Provide hover support for translations in I18n.t("key") calls.
• Synchronize the I18n backend when users modify their translation files.

I will open a PR showcasing an initial implementation.

Next, we could work on:

• Autocompletion while typing, e.g., I18n.t("hel
• “Go to definition” for translations

These features are already implemented in our custom solution.

Some Limitations with the Rails I18n API

In our implementation, we store the file path for each translation key. However, the Rails I18n API doesn’t store the source location of translations, which makes points 3, 4, and 5 difficult to implement without modifying the I18n backend.

That said, points 1 and 2 already provide substantial value on their own.

Current Addon Implementation

At our organization, we’ve been using ruby-lsp-i18n internally for over a year. It addresses all of the use cases listed above and has significantly improved the developer experience when working with translations.

Because a project can contain millions of translations, managing them efficiently is crucial. For example, to accomplish point 1, developers often resort to opening a Rails console just to call I18n.t.

Here's a summary of what our addon currently does:

• On startup, it indexes all translation keys across all YAML files.
• It creates an index: key => (value, file).
• It builds a Trie from the values to enable autocompletion.
• It displays an inlay hint for the value of the base language (es) and shows a markdown tooltip with:
  • A link to the file (serving as a "go to definition").
  • A “recommended” file path for new translations (based on our internal convention).
• It attaches a file watcher to keep all translations in sync when files change — updating both the index and the Trie on each change.

Current Drawbacks of Our Implementation

• It maintains an in-memory index for all I18n translations, consuming additional memory. This memory is duplicated in the Rails process running the ruby-lsp-rails addon server.
• It only supports the es locale for now, which limits its usefulness for other projects around the world.
• Synchronizing the index is complex, and syncing it with the editor is not as instantaneous as we would like.
• It uses inlay hints via a monkey patch, which (as mentioned here) can disrupt some developers' workflows. Additionally, the hints are only refreshed when code changes, so if a developer edits a .yml file but not the source code, the inlay hint isn't updated.
• Because we don't access the I18n backend directly, we just show the text in the yaml, and do not provide support for other I18n backends as recursive backends or other specific backend implementation.

Despite these drawbacks, the addon has been extremely helpful. It has required very few changes since the initial implementation, thanks to developer feedback. We believe that we can port the most useful, non–organization-specific features into the ruby-lsp-rails addon.