# General Translation Integrations: Rilevamento degli utilizzi URL: https://generaltranslation.com/it/docs/integrations/paraglide/reference/usage-detection.mdx Docs index: https://generaltranslation.com/llms.txt Description: Come vengono selezionati i file sorgente, come vengono risolte le importazioni e come vengono individuati gli utilizzi dei messaggi di Paraglide JS. Riferimento per il rilevamento degli utilizzi. Un'esecuzione di [`paraglide-context`](/docs/integrations/paraglide/reference/paraglide-context) o di [`collectContext`](/docs/integrations/paraglide/reference/collect-context) legge il codice sorgente dell'app senza mai avviarne il bundler. Supporta Paraglide JS 1, 2 e 3 su Node.js 20 o versioni successive. ## Come funziona [#how-it-works] | Passaggio | Cosa determina | | ----------------------------------- | -------------------------------------------------------- | | [File](#files) | Quali file sorgente vengono analizzati. | | [Importazioni](#imports) | Quali importazioni puntano a un file Paraglide JS. | | [Directory di output](#outdirs) | Quali directory contengono l'output di Paraglide JS. | | [Progetti inlang](#inlang-projects) | Quali file di messaggi ottengono un file di metadati. | | [Utilizzi](#usages) | Dove viene utilizzato ciascun messaggio. | ## File [#files] I file analizzati sono quelli indicati in [`include`](/docs/integrations/paraglide/reference/collect-context#include), esclusi quelli in [`exclude`](/docs/integrations/paraglide/reference/collect-context#exclude), `node_modules`, l'output della build e del framework e tutto ciò che viene ignorato da un `.gitignore`. Anche i file esterni al progetto vengono analizzati, se elencati in `include` (`../shared`). Un file che non può essere analizzato sintatticamente viene ignorato e viene mostrato un avviso. Per i formati diversi da JavaScript, TypeScript e JSX, consulta [Formati di file supportati](/docs/integrations/paraglide/reference/file-formats). ## Importazioni [#imports] Le importazioni non vengono mai individuate in base al loro testo. Ciascuna viene risolta, seguita attraverso le riesportazioni (ESM e CommonJS) e conteggiata solo se porta a un file di Paraglide JS. Vengono risolte come farebbe il bundler dell'app, ma senza eseguirlo. Gli alias vengono letti, nell'ordine, da: 1. L'opzione [`alias`](/docs/integrations/paraglide/reference/collect-context#alias). 2. Il primo file `vite.config.*`, `webpack.config.*` o `rspack.config.*` trovato. La config di Vite viene risolta dalla versione di Vite installata nel progetto, quindi funzionano sia gli alias definiti dai plugin (come `$lib` di SvelteKit) sia i percorsi relativi alla radice (`/src/a.js`). Una config di webpack o rspack viene invece importata, per cui una config scritta in TypeScript richiede una versione di Node.js in grado di eseguire TypeScript. Sono supportati i suoi alias `name$` e quelli con caratteri jolly (`"@/*"`). 3. `paths` in `tsconfig.json` e `imports` in `package.json`. Se non è possibile leggere alcuna config del bundler, le importazioni non risolte vengono elencate in un avviso, perché potrebbero essere alias non dichiarati. (Vedi [Risoluzione delle importazioni](/docs/integrations/paraglide/guides/resolving-imports)). ### Importazioni automatiche I nomi usati senza un'importazione esplicita vengono ricavati dai file `.d.ts` di unplugin-auto-import, unplugin-vue-components e Nuxt. Per dichiararne altri, usa [`autoImports`](/docs/integrations/paraglide/reference/collect-context#auto-imports). ## Directory di output [#outdirs] Le directory di output di Paraglide JS vengono rilevate automaticamente, quindi più progetti Paraglide JS all'interno della stessa app non richiedono alcuna configurazione. Una directory viene riconosciuta quando contiene esattamente ciò che genera la versione installata di Paraglide JS, su disco o come moduli virtuali. Per Paraglide JS 1, è sufficiente che abbia la stessa struttura. Una directory che sembra di output ma non supera la verifica viene ignorata e viene mostrato un avviso. Per utilizzarla comunque, aggiungila a [`outdirs`](/docs/integrations/paraglide/reference/collect-context#outdirs). Se non viene trovata alcuna directory di output, un avviso segnala che non è possibile registrare alcun utilizzo. ## Progetti inlang [#inlang-projects] Ogni directory di output è associata a un progetto inlang, i cui file dei messaggi nell'impostazione regionale di base ricevono i metadati. Il progetto viene individuato secondo questo ordine: 1. Quello che il `README.md` della directory di output indica come progetto da cui è stata compilata. 2. L'unica directory `*.inlang` presente tra [`root`](/docs/integrations/paraglide/reference/collect-context#root) e la radice del monorepo. 3. Se esistono più directory di questo tipo, quella che definisce il maggior numero di messaggi della directory di output. [`inlangProjects`](/docs/integrations/paraglide/reference/collect-context#inlang-projects) sostituisce questa ricerca. Per una directory di output senza progetto viene generato un avviso e per i relativi messaggi non viene creato alcun file di metadati. ## Utilizzi [#usages] I valori vengono tracciati tramite l'analisi degli ambiti di typescript-eslint attraverso: * Alias (`const t = m`), destrutturazione e riassegnazione * Spread di oggetti * Argomenti di funzione e valori predefiniti dei parametri * Props dei componenti, anche tra moduli diversi e a partire dai template * Chiavi calcolate (`m["a"]`, `m[c ? "a" : "b"]`) Un messaggio è considerato utilizzato ovunque venga: | Utilizzo | Esempio | | ------------------------------------ | ----------------- | | Chiamato | `m.tos()` | | Chiamato tramite uno dei suoi metodi | `m.tos.parts()` | | Referenziato senza essere chiamato | `message={m.tos}` | Gli utilizzi di messaggi assenti dal catalogo generato vengono segnalati in un avviso. Per impostazione predefinita, i file di Paraglide JS sono `messages.js`, i moduli in `messages/`, `runtime.js`, `server.js`, `registry.js` e i pacchetti adattatori per framework di Paraglide (vedi [Target](/docs/integrations/paraglide/reference/extension-api#targets)). ## Limiti [#limits] * **Alias:** da una config del bundler si ricavano solo i suoi alias e la radice di Vite, non i moduli virtuali dei suoi plugin. Le config di Next.js, Nuxt e Astro non vengono lette; i loro alias vengono ricavati da `tsconfig.json`. * **Altri target:** gli utilizzi delle funzioni di runtime e dei componenti adattatori vengono analizzati ma non scritti. Solo i messaggi hanno una chiave in cui scrivere. * **Flusso dei valori:** il tracciamento si interrompe in corrispondenza di valori di ritorno, Contesto React, `provide`/`inject`, array e oggetti assegnati in seguito. Una lettura successiva a una riassegnazione incondizionata vede solo il nuovo valore. I cicli non vengono modellati. * **Props:** le props vengono seguite all'interno dei componenti Svelte, Vue e Astro, ma non nei componenti registrati con `app.component()` o renderizzati con ``. * **Chiavi calcolate:** una chiave con più di 16 alternative diventa `*`, che non corrisponde a nessun messaggio specifico. * **CommonJS:** gli export non definiti al livello superiore di un modulo non vengono seguiti. * **File Astro malformati:** dopo una `{` non chiusa, il resto dell'elemento va perso. Con il solo `@astrojs/compiler` (Astro 6 e precedenti), va perso il resto della riga. ## Sitemap See the full [sitemap](https://generaltranslation.com/sitemap.md) for all pages.