Domande frequenti

No. Funziona su React e Next.js, React Native e Expo, Flutter, Angular, Vue e Nuxt, Svelte e SvelteKit, Astro, Solid, Qwik, Lit, Ember, Electron e Tauri, siti HTML semplici, modelli Rails, Django e Laravel, layout Android, Jetpack Compose e codice View, e app iOS e macOS in SwiftUI e UIKit. Configura la libreria i18n corrispondente per ciascuna: react-i18next, ngx-translate, vue-i18n o @nuxtjs/i18n, svelte-i18n, ember-intl, gen-l10n di Flutter, Rails I18n, gettext di Django, risorse stringa Android, o uno script per pagine statiche.

Sì. localize-dev translate riempie le traduzioni mancanti nei file di localizzazione già esistenti, in qualsiasi stack: JSON (i18next, react-intl, vue-i18n, ngx-translate), YAML di Rails, gettext .po, Flutter .arb, Android strings.xml, Cataloghi di Stringhe Apple e .strings, e messaggi di estensione browser. Il codice non viene modificato, le traduzioni esistenti non cambiano, e in CI apre una pull request ogni volta che vengono aggiunte nuove chiavi.

Solo Node.js 22 o successivo per eseguire il CLI: npx localize-dev lo esegue senza aggiungere un package.json al tuo progetto. Oppure salta le esecuzioni locali e usa l’azione GitHub, che gira sulle macchine di GitHub.

Sì. localize-dev sync push carica i tuoi file di localizzazione sorgente e sync pull riporta il lavoro dei traduttori, così le traduzioni automatiche, la revisione umana e il tuo repository rimangono sincronizzati.

La tua app continua a funzionare. Il risultato è la libreria di internazionalizzazione che il tuo framework utilizza già (react-i18next, vue-i18n, ngx-translate, Rails I18n, gettext, risorse stringhe Android, Apple String Catalogs…) con file di localizzazione semplici nel tuo repository. Non c'è bisogno di rimuovere alcuna runtime, SDK o proxy di localize.dev.

Sì. Collega il repository nella dashboard e scegli 'Apri una pull request di anteprima': localize.dev localizza la branch predefinita (fino a 200 stringhe, una lingua) e apre una pull request da localize-dev/preview. Nessun workflow, chiave o checkout necessario.

Sì. `npx localize-dev check` (o l'Action con modalità: check) fallisce se una modifica aggiunge testo codificato duramente, una lingua è priva di traduzioni, oppure se l'inglese è stato modificato e le traduzioni non sono state aggiornate, annotando ogni problema sulla pull request. Si esegue sulla tua macchina o runner, senza chiave API.

Sì. Una scelta come `n === 1 ? "file" : "files"` diventa un messaggio plurale unico, e ogni lingua riceve le forme di cui ha bisogno: polacco (quattro), arabo (sei), giapponese (uno). Una frase con due contatori ("3 file in 2 cartelle") ottiene un plurale per ogni contatore, e gli ordinali come 1°, 2° e 3° diventano plurali ordinali nelle forme proprie di ogni lingua, in React, Next.js, Vue, Svelte, Astro, Ember, Angular e gli altri framework JavaScript. Flutter, Rails, Django, Laravel, Android e iOS ottengono i plurali nei loro formati propri (ARB, YAML, msgid_plural, trans_choice, <plurals>, varianti di String Catalog); le loro librerie non supportano gli ordinali.

Viene tradotto nuovamente. Il file `localize.lock.json` conserva una impronta digitale di ogni messaggio sorgente, quindi un messaggio modificato viene ridotto in tutte le lingue al prossimo avvio o pull request, e `localize-dev check` fallisce finché una traduzione non è aggiornata. Le chiavi che non vengono più utilizzate dal codice vengono segnalate, e `localize-dev prune` le rimuove.

Sì. Il contenuto di localize-dev traduce file Markdown e MDX in una copia per lingua (intro.es.md o le cartelle i18n di Docusaurus), mantenendo blocchi di codice, link, importazioni MDX e componenti esattamente come scritti. Vengono inviati nuovamente solo i documenti modificati dall'ultima traduzione.

Sì. Eseguilo dalla root con --workspaces, o imposta workspaces: true nella GitHub Action, e ogni app viene localizzata con i propri file di localizzazione, in una sola pull request. Le librerie condivise senza uno script di sviluppo o di avvio vengono lasciate intatte. Per localizzare solo un'app, imposta invece working_directory: apps/web nell'Action.

In Next.js, SvelteKit e Nuxt, le pagine vengono renderizzate nella lingua del visitatore sul server. Per i siti HTML statici, attiva htmlPages e localize.dev scriverà una copia tradotta di ogni pagina per lingua, collegata con hreflang, in modo che ogni lingua possa essere indicizzata.

Solo le stringhe che vengono tradotte vengono inviate all'API di localize.dev, con il loro percorso file e la loro posizione (il componente e l'elemento come un pulsante o un'intestazione) come contesto. I file interi non vengono mai inviati. La riscrittura avviene localmente (o sul tuo CI runner), e le scansioni e le esecuzioni offline non toccano mai la rete.

No. La traduzione viene eseguita sul modello ospitato di localize.dev su ogni piano, incluso quello Gratuito. Crea una chiave API, esegui localize-dev login e hai finito.

No. Se la tua app non ne ha ancora nessuna, la pull request ne aggiunge una corretta (incluso il lockfile), crea un modulo che carica ogni file di localizzazione e sceglie la lingua, e la integra nel tuo file di ingresso. Le lingue da destra a sinistra impostano anche la direzione della pagina. Le app che hanno già i18next, vue-i18n o svelte-i18n in esecuzione mantengono la propria configurazione.

Le chiamate t(), e $_() esistenti rimangono invariate, e le chiavi già presenti in en.json vengono riutilizzate quando il testo corrisponde (per testi brevi come "Post", quando anche le traduzioni corrispondono). È sicuro eseguire su codice parzialmente localizzato.

Traduce con contesto. Ogni stringa raggiunge il modello con il suo file, componente ed elemento, quindi "Post" su un pulsante diventa "Veröffentlichen" in tedesco e "Post" come titolo di una scheda diventa "Beitrag", ognuno con la propria chiave; copie identiche condividono una chiave solo quando le loro traduzioni concordano. Il tuo glossario e le note di stile mantengono i termini del prodotto e il tono coerenti, incluso un "tu" formale o informale per lingua, e i plurali ottengono ogni forma di cui ogni lingua ha bisogno. I cataloghi Laravel e Django sono indicizzati dal testo inglese stesso, quindi lì un testo ha una traduzione.

Il file di workflow sopra e un segreto del repository, LOCALIZEDEV_API_KEY. Utilizza il GITHUB_TOKEN integrato con accesso in scrittura ai contenuti e alle pull request, mantiene una pull request per branch aggiornata invece di aprirne una nuova ad ogni push, ed esclude i propri branch e le pull request dai fork, il cui token è di sola lettura.

Sono una prima bozza solida con placeholder corretti e chiavi coerenti. Per testi regolamentati o critici per il brand, assegna un revisore per lingua: ricevono un'email quando un'esecuzione termina, approvano o correggono ogni traduzione nella scheda Revisione, e le correzioni vengono inserite nella pull request aperta e in ogni esecuzione successiva. Le correzioni che continuano a presentarsi diventano termini del glossario con un clic. Il modello segnala anche le traduzioni di cui non è sicuro, con il motivo, in modo che i revisori inizino da quelle.

Un pezzo unico di testo dell'interfaccia utente inviato per la traduzione. Una stringa conta una volta, indipendentemente da quante lingue la contengano. Tradurre “Effettua ordine” in 10 lingue utilizza 1, non 10. Il testo che ha già una chiave non viene mai inviato di nuovo.

L'esecuzione si interrompe prima di scrivere qualsiasi cosa e ti dice perché, in modo che il tuo codice non venga mai lasciato a metà. Aggiorna, o attendi che il limite si azzeri alla fine del tuo periodo di 30 giorni, ed esegui di nuovo. La dashboard mostra la data.

No. Le scansioni e le esecuzioni --offline funzionano interamente sulla tua macchina e non chiamano mai l'API. Non hai bisogno di una chiave per queste.

No. L'Action funziona su ogni piano, incluso quello Gratuito. Aggiungi la tua chiave API come segreto del repository e aprirà una pull request ad ogni push, entro le 3/5/illimitato lingue del tuo piano.

Sì. Il playground esegue lo stesso motore su un componente o una pagina che incolli (React, Vue, Svelte, Angular, Astro, Flutter, Rails, Django, Laravel, Android, iOS o HTML), non è necessario un account.

Elimina il tuo spazio di lavoro personale in Dashboard → Impostazioni. Questo eliminerà anche il tuo account: login, accessi collegati a GitHub e Google, iscrizioni ai team, e sarai disconnesso su tutti i dispositivi. Se possiedi spazi di lavoro di team, eliminali prima. Le stringhe usate in questo periodo contano ancora se ti iscrivi di nuovo con la stessa email.

Sì. Invia un'email a support@uselocalize.dev dall'indirizzo associato al tuo account e te la invieremo. La Privacy Policy elenca cosa conserviamo.

Invia un'email a support@uselocalize.dev con cosa hai eseguito e cosa hai visto. Per problemi di sicurezza, si prega di inviare un'email piuttosto che pubblicare i dettagli.