LLM translations

[stirkac]

LLM Translations

Objectives

AI based / LLM translations enable a new way to translate user generated content without relying on Microsoft's services.

Using RubyLLM approach, it means that a variety of LLM providers and their models can be used, from paid services to local instances.

Leverage the existing Remote translations framework by providing an alternate LLM based translation, instead of Microsoft service currently in place.

Visual Changes

Introduced a new Settings panel - LLM Settings. Enables Consul admins to configure LLM Settings - LLM provider, model and choosing to use LLM for remote translations

Usage and configuration

1. Setting LLM Provider Credentials

Enter LLM credentials to your secrets.yml file, as shown in secrets.yml.example
To find the exact names of required fields to configure your chosen provider, reference Ruby LLM documentation.

2. Enabling remote translations in Admin

Select the provider, model and turn on the "Content Translation" switch in Admin > Global Settings > LLM Settings

• Switching on LLM Settings takes precedence over Microsoft services, if they are previously configured. If you want to use Microsoft translations, do not turn on "Content Translation" switch in LLM Settings.

3. Configuring LLM prompt

Use config/llm_prompts.yml and edit remote_translation_prompt to set up your own translation prompt. Ensure that the prompt returns the resulting translation as it's expected to be viewed by the end user.

[taitus]

@stirkac Thank you so much for this pull request! 🎉
I’ve left a few comments. Let me know what you think!

For the components under app/components/admin/settings, there’s also a patch attached in the comment of llm_configuration_tab_component.html.erb.
It might make sense to start the review there, since the rest of the feedback builds on that.

Thanks again for the work and for including tests and documentation — much appreciated! 🙌

[taitus]

If we apply the patch suggested in app/components/admin/settings/llm_configuration_tab_component.html.erb, we should review which of the styles in app/assets/stylesheets/admin/settings/dropdown_settings.scss are still needed. At minimum, we should rename the file to dropdown_form.scss to match the new component name.

One specific concern: @include regular-button; on the submit button is overriding the "button hollow expanded" classes used by Admin::Settings::DropdownFormComponent. That means the hollow style won’t take effect.

[taitus]

Hi @stirkac

Thanks for making the suggested changes in the review. Since I wasn't sure whether we'd end up modifying the logic and components, I left the specs for last.

Here I've added a few comments about conventions and some adjustments to the tests.

As I won't be able to continue the review until next week, I'm sending you the suggestions I have so far, along with what's still pending. For example, adding a test to check how providers are loaded across different tenants depending on their secrets, using the stub_secrets helper. Something similar to this code:

stub_secrets(
  llm: {
    openai_api_key: "1234",
    deepseek_api_key: "4321"
  },
  tenants: {
    new_tenant_name: {
      llm: {
        openai_api_key: "2222",
        deepseek_api_key: "4444"
      }
    }
  }
)

I'd also like to review and update spec/shared/system/remotely_translatable.rb to align it as much as possible with the LLM setup.

Of course, feel free to ping me if you have any questions.

[taitus]

I can take care of updating the docs/es/features/user_content_translations.md file.
I'm leaving this comment here so we don't forget.

[taitus]

We could add a new spec file at
spec/components/admin/settings/dropdown_form_component_spec.rb
to cover this component with component specs (similar to the existing FeaturedSettingsFormComponent tests).

[taitus]

We could add a few more specs in the FeaturedSettingsFormComponent tests to cover the recent changes in this component.

[taitus]

We could add a new spec file at
spec/components/admin/settings/llm_configuration_tab_component_spec.rb
to cover this component with component specs. The most interesting part to test here would probably be the disabled states depending on the component's configuration.

[taitus]

Hi @stirkac

Thanks again for applying all the changes to this PR!

In addition to the three small comments you'll see in the review, I'm sharing a couple of patches that you can apply if they make sense to you:

docs-and-es-translations.patch

• Includes the Spanish documentation update and a small structural tweak in the English version (no text changes).
• Since we now have a Spanish version, both guides reference separate images (display-llm-translations-en.png and display-llm-translations-es.png).
  You’ll just need to rename the original image from display-llm-translations.png to display-llm-translations-en.png and add the Spanish one.
• I'd also suggest adding a "Pricing" subsection under Using LLM Translation (same level as Configuration), with a short generic explanation about how costs vary by provider/model 🤔

specs-changes.patch

• Contains the adjustments we discussed for the tests related to spec/shared/system/remotely_translatable.rb, along with a few simplifications and some alignment with our component conventions.
  For the remotely translatable changes, I opted to allow a new provider and make one call for :microsoft and another for :llm. Since the Microsoft option will likely be deprecated in upcoming releases, we can revisit and optimize those tests later on.

They're all small tweaks, that's why I preferred to share them as patches rather than add tiny inline comments in the review.

If anything doesn't quite fit or you'd rather approach it differently, just let me know and we'll figure it out together.

Thanks again! 🙌

[taitus]

@stirkac Thanks a lot for all the work on this! 🙌

Approved! 🚀

We'll merge it as soon as we confirm that the new 2.4.1 release is behaving as expected, just to be sure we don't need to issue a follow-up fix. 😊