Lingo.dev Compiler unexpectedly requires GROQ_API_KEY even when configured to use only Google Gemini model

[iurvish]

What's happening?

🐛 Bug Report

Describe the bug
When running the Lingo.dev Compiler in my Vite (monorepo)project with only the Google Gemini model configured, build starts translating successfully, but then fails part-way with:

Exact Reproduction Steps

Even though I only configured Google (Gemini) in my models setting, and I have a valid GOOGLE_API_KEY, the compiler still tries to use Groq and errors if GROQ_API_KEY is not present.

---

plugins: [
    lingoCompilerPlugin({
      sourceRoot: "src",
      sourceLocale: "en",
      targetLocales: ["es", "de", "fr"],
      models: {
        // "en:es": "google:gemini-2.5-flash", 
        // "en:de": "google:gemini-2.5-flash", 
        // "en:fr": "google:gemini-2.5-flash",
        "*:*": "google:gemini-2.5-flash", 
      },
      dev: {
        usePseudotranslator: true,
      },

Expected

.

Actual

.

Screenshots/Videos

[vrcprl]

@iurvish good catch, the team is looking into it.

[The-Best-Codes]

Others in the Lingo.dev Discord server are experiencing this issue as well! Hopefully it's solved soon 🙂

[yashrajpatilll]

Hi @vrcprl - I took a look at the new compiler (Vite plugin) codepath and I think the Groq requirement may be coming from pluralization defaults. In packages/new-compiler/src/utils/config-factory.ts, pluralization is enabled by default and the model defaults to groq:llama-3.1-8b-instant. In production builds, TranslationService instantiates PluralizationService, which validates API keys for its own model and errors if GROQ_API_KEY is missing. That would explain why it trips even when translation models are Google. Happy to be corrected if I missed something.

Possible fixes:

1. If pluralization.model isn’t set, inherit provider from translation models.
2. Disable pluralization by default unless explicitly configured.
3. Keep Groq default but improve messaging/warnings.

If you want me to proceed, I can take #1737 and implement the chosen approach.

[shashwat-runable]

@vrcprl facing the same issue, would be helpful if it gets a fix soon.

[yashrajpatilll]

Hi @vrcprl — just checking in. I’m still happy to take #1737 and implement the chosen approach. If you’d like me to proceed, please assign and let me know which option you want.

[vrcprl]

sure @yashrajpatilll - assigning to you!

[vrcprl]

Also, great inputs @yashrajpatilll , let’s go with the first two you mentioned:

1. If pluralization.model isn’t set, inherit the provider from the translation model.

2. Disable pluralization by default unless it’s explicitly configured.

Along with that, we’ll keep an option to use a different model (like Groq) for pluralization to keep it faster, and we’ll add this to the docs on our end.