Lingo.dev - Toolkit i18n open-source per la localizzazione basata su LLM
MCP •CLI • CI/CD •SDK • Compiler
| Tool | Caso d'uso | Comando rapido |
|---|---|---|
| MCP | Setup i18n assistito da AI per app React | Prompt: Set up i18n |
| CLI | Traduzione di file JSON, YAML, markdown, CSV, PO | npx lingo.dev@latest run |
| CI/CD | Pipeline di traduzione automatizzata in GitHub Actions | uses: lingodotdev/lingo.dev@main |
| SDK | Traduzione runtime per contenuti dinamici | npm install lingo.dev |
| Compiler | Localizzazione React a build-time senza wrapper i18n | Plugin withLingo() |
Configurare l'i18n nelle app React è notoriamente soggetto a errori, anche per sviluppatori esperti. Gli assistenti di codifica AI peggiorano la situazione: allucinano API inesistenti, dimenticano configurazioni middleware, rompono il routing o implementano metà soluzione prima di perdersi. Il problema è che la configurazione i18n richiede una sequenza precisa di modifiche coordinate su più file (routing, middleware, componenti, configurazione) e gli LLM faticano a mantenere quel contesto.
Lingo.dev MCP risolve questo problema fornendo agli assistenti AI accesso strutturato alla conoscenza i18n specifica per framework. Invece di indovinare, il tuo assistente segue pattern di implementazione verificati per Next.js, React Router e TanStack Start.
IDE supportati:
- Claude Code
- Cursor
- GitHub Copilot Agents
- Codex (OpenAI)
Framework supportati:
- Next.js (App Router & Pages Router v13-16)
- TanStack Start (v1)
- React Router (v7)
Utilizzo:
Dopo aver configurato il server MCP nel tuo IDE (vedi guide rapide), richiedi al tuo assistente:
Set up i18n with the following locales: en, es, and pt-BR. The default locale is 'en'.
L'assistente:
- Configurerà il routing basato su locale (es.
/en,/es,/pt-BR) - Configurerà i componenti per il cambio lingua
- Implementerà il rilevamento automatico del locale
- Genererà i file di configurazione necessari
Nota: la generazione di codice assistita da AI è non deterministica. Rivedi il codice generato prima di committare.
Mantenere le traduzioni sincronizzate è tedioso. Aggiungi una nuova stringa, dimentichi di tradurla, rilasci un'interfaccia rotta agli utenti internazionali. Oppure invii file JSON ai traduttori, aspetti giorni, poi unisci manualmente il loro lavoro. Scalare a oltre 10 lingue significa gestire centinaia di file che costantemente vanno fuori sincronia.
Lingo.dev CLI automatizza questo processo. Puntalo ai tuoi file di traduzione, esegui un comando e ogni locale si aggiorna. Un lockfile traccia ciò che è già tradotto, quindi paghi solo per contenuti nuovi o modificati. Supporta file JSON, YAML, CSV, PO e markdown.
Setup:
# Initialize project
npx lingo.dev@latest init
# Run translations
npx lingo.dev@latest runCome funziona:
- Estrae i contenuti traducibili dai file configurati
- Invia i contenuti al provider LLM per la traduzione
- Scrive i contenuti tradotti nel filesystem
- Crea il file
i18n.lockper tracciare le traduzioni completate (evita elaborazioni ridondanti)
Configurazione:
Il comando init genera un file i18n.json. Configura le locale e i bucket:
{
"$schema": "https://lingo.dev/schema/i18n.json",
"version": "1.10",
"locale": {
"source": "en",
"targets": ["es", "fr", "de"]
},
"buckets": {
"json": {
"include": ["locales/[locale].json"]
}
}
}Il campo provider è facoltativo (predefinito: Lingo.dev Engine). Per provider LLM personalizzati:
{
"provider": {
"id": "openai",
"model": "gpt-4o-mini",
"prompt": "Translate from {source} to {target}"
}
}Provider LLM supportati:
- Lingo.dev Engine (consigliato)
- OpenAI
- Anthropic
- Mistral
- OpenRouter
- Ollama
Le traduzioni sono la funzionalità che è sempre "quasi pronta". Gli sviluppatori fanno il merge del codice senza aggiornare le locale. Il QA scopre le traduzioni mancanti in staging - o peggio, gli utenti le scoprono in produzione. La causa principale: la traduzione è un passaggio manuale facile da saltare sotto la pressione delle scadenze.
Lingo.dev CI/CD rende le traduzioni automatiche. Ogni push attiva la traduzione. Le stringhe mancanti vengono completate prima che il codice raggiunga la produzione. Non serve disciplina - la pipeline se ne occupa.
Piattaforme supportate:
- GitHub Actions
- GitLab CI/CD
- Bitbucket Pipelines
Setup GitHub Actions:
Crea .github/workflows/translate.yml:
name: Translate
on:
push:
branches: [main]
permissions:
contents: write
jobs:
translate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Lingo.dev
uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}Requisiti di setup:
- Aggiungi
LINGODOTDEV_API_KEYai secret del repository (Settings > Secrets and variables > Actions) - Per i workflow PR: Abilita "Allow GitHub Actions to create and approve pull requests" in Settings > Actions > General
Opzioni workflow:
Committa le traduzioni direttamente:
uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}Crea pull request con le traduzioni:
uses: lingodotdev/lingo.dev@main
with:
api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
pull-request: true
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}Input disponibili:
| Input | Default | Descrizione |
|---|---|---|
api-key |
(obbligatorio) | Chiave API Lingo.dev |
pull-request |
false |
Crea PR invece di committare direttamente |
commit-message |
"feat: update translations via @LingoDotDev" |
Messaggio di commit personalizzato |
pull-request-title |
"feat: update translations via @LingoDotDev" |
Titolo PR personalizzato |
working-directory |
"." |
Directory in cui eseguire |
parallel |
false |
Abilita elaborazione parallela |
I file di traduzione statici funzionano per le etichette UI, ma cosa succede con i contenuti generati dagli utenti? Messaggi di chat, descrizioni di prodotti, ticket di supporto - contenuti che non esistono al momento della build non possono essere pre-tradotti. Rimani bloccato mostrando testo non tradotto o costruendo una pipeline di traduzione personalizzata.
Lingo.dev SDK traduce i contenuti a runtime. Passa qualsiasi testo, oggetto o HTML e ottieni una versione localizzata. Funziona per chat in tempo reale, notifiche dinamiche o qualsiasi contenuto che arriva dopo il deployment. Disponibile per JavaScript, PHP, Python e Ruby.
Installazione:
npm install lingo.devUtilizzo:
import { LingoDotDevEngine } from "lingo.dev/sdk";
const lingoDotDev = new LingoDotDevEngine({
apiKey: process.env.LINGODOTDEV_API_KEY,
});
// Translate objects (preserves structure)
const translated = await lingoDotDev.localizeObject(
{ greeting: "Hello", farewell: "Goodbye" },
{ sourceLocale: "en", targetLocale: "es" },
);
// { greeting: "Hola", farewell: "Adiós" }
// Translate text
const text = await lingoDotDev.localizeText("Hello!", {
sourceLocale: "en",
targetLocale: "fr",
});
// Translate to multiple languages at once
const results = await lingoDotDev.batchLocalizeText("Hello!", {
sourceLocale: "en",
targetLocales: ["es", "fr", "de"],
});
// Translate chat (preserves speaker names)
const chat = await lingoDotDev.localizeChat(
[{ name: "Alice", text: "Hello!" }],
{ sourceLocale: "en", targetLocale: "es" },
);
// Translate HTML (preserves markup)
const html = await lingoDotDev.localizeHtml("<h1>Welcome</h1>", {
sourceLocale: "en",
targetLocale: "de",
});
// Detect language
const locale = await lingoDotDev.recognizeLocale("Bonjour le monde");
// "fr"SDK disponibili:
- JavaScript SDK - App web, Node.js
- PHP SDK - PHP, Laravel
- Python SDK - Django, Flask
- Ruby SDK - Rails
L'i18n tradizionale è invasivo. Avvolgi ogni stringa in funzioni t(), inventi chiavi di traduzione (home.hero.title.v2), mantieni file JSON paralleli e guardi i tuoi componenti gonfiarsi con boilerplate di localizzazione. È così tedioso che i team ritardano l'internazionalizzazione finché non diventa un refactoring massiccio.
Lingo.dev Compiler elimina le cerimonie. Scrivi componenti React con testo in inglese semplice. Il compiler rileva le stringhe traducibili al momento della build e genera automaticamente le varianti localizzate. Niente chiavi, niente file JSON, niente funzioni wrapper - solo codice React che funziona in più lingue.
Installazione:
pnpm install @lingo.dev/compilerAutenticazione:
# Recommended: Sign up at lingo.dev and login
npx lingo.dev@latest login
# Alternative: Add API key to .env
LINGODOTDEV_API_KEY=your_key_here
# Or use direct LLM providers (Groq, OpenAI, Anthropic, Google)
GROQ_API_KEY=your_keyConfigurazione (Next.js):
// next.config.ts
import type { NextConfig } from "next";
import { withLingo } from "@lingo.dev/compiler/next";
const nextConfig: NextConfig = {};
export default async function (): Promise<NextConfig> {
return await withLingo(nextConfig, {
sourceRoot: "./app",
sourceLocale: "en",
targetLocales: ["es", "fr", "de"],
models: "lingo.dev",
dev: { usePseudotranslator: true },
});
}Configurazione (Vite):
// vite.config.ts
import { lingoCompilerPlugin } from "@lingo.dev/compiler/vite";
export default defineConfig({
plugins: [
lingoCompilerPlugin({
sourceRoot: "src",
sourceLocale: "en",
targetLocales: ["es", "fr", "de"],
models: "lingo.dev",
dev: { usePseudotranslator: true },
}),
react(),
],
});Setup del provider:
// app/layout.tsx (Next.js)
import { LingoProvider } from "@lingo.dev/compiler/react";
export default function RootLayout({ children }) {
return (
<LingoProvider>
<html>
<body>{children}</body>
</html>
</LingoProvider>
);
}Selettore lingua:
import { useLocale, setLocale } from "@lingo.dev/compiler/react";
export function LanguageSwitcher() {
const locale = useLocale();
return (
<select value={locale} onChange={(e) => setLocale(e.target.value)}>
<option value="en">English</option>
<option value="es">Español</option>
</select>
);
}Sviluppo: npm run dev (utilizza pseudotranslator, nessuna chiamata API)
Produzione: Imposta usePseudotranslator: false, quindi next build
Committa la directory .lingo/ nel version control.
Caratteristiche principali:
- Nessun costo di performance a runtime
- Nessuna chiave di traduzione o file JSON
- Nessuna funzione
t()o componente wrapper<T> - Rilevamento automatico del testo traducibile in JSX
- Supporto TypeScript
- ICU MessageFormat per i plurali
- Override manuali tramite attributo
data-lingo-override - Widget editor di traduzione integrato
Modalità di build:
pseudotranslator: Modalità sviluppo con traduzioni placeholder (nessun costo API)real: Genera traduzioni reali utilizzando LLMcache-only: Modalità produzione utilizzando traduzioni pre-generate da CI (nessuna chiamata API)
Framework supportati:
- Next.js (App Router con React Server Components)
- Vite + React (SPA e SSR)
Supporto per framework aggiuntivi in programma.
I contributi sono benvenuti. Si prega di seguire queste linee guida:
- Issue: Segnala bug o richiedi funzionalità
- Pull request: Invia modifiche
- Ogni PR richiede un changeset:
pnpm new(opnpm new:emptyper modifiche che non richiedono rilascio) - Assicurati che i test passino prima di inviare
- Ogni PR richiede un changeset:
- Sviluppo: Questo è un monorepo pnpm + turborepo
- Installa le dipendenze:
pnpm install - Esegui i test:
pnpm test - Build:
pnpm build
- Installa le dipendenze:
Supporto: Community Discord
Se trovi Lingo.dev utile, lasciaci una stella e aiutaci a raggiungere 10.000 stelle!
[
](https://www.star-history.com/#lingodotdev/lingo.dev&Date)
Traduzioni disponibili:
English • 中文 • 日本語 • 한국어 • Español • Français • Русский • Українська • Deutsch • Italiano • العربية • עברית • हिन्दी • Português (Brasil) • বাংলা • فارسی • Polski • Türkçe • اردو • भोजपुरी • অসমীয়া • ગુજરાતી • मराठी • ଓଡ଼ିଆ • ਪੰਜਾਬੀ • සිංහල • தமிழ் • తెలుగు
Aggiungere una nuova lingua:
- Aggiungi il codice locale a
i18n.jsonutilizzando il formato BCP-47 - Invia una pull request
Formato locale BCP-47: language[-Script][-REGION]
language: ISO 639-1/2/3 (minuscolo):en,zh,bhoScript: ISO 15924 (maiuscolo iniziale):Hans,Hant,LatnREGION: ISO 3166-1 alpha-2 (maiuscolo):US,CN,IN- Esempi:
en,pt-BR,zh-Hans,sr-Cyrl-RS