# General Translation Integrations: Détection des utilisations URL: https://generaltranslation.com/fr/docs/integrations/paraglide/reference/usage-detection.mdx Docs index: https://generaltranslation.com/llms.txt Description: Comment les fichiers sources sont sélectionnés, les importations résolues et les utilisations des messages Paraglide JS détectées. Référence pour la détection des utilisations. Une exécution de [`paraglide-context`](/docs/integrations/paraglide/reference/paraglide-context) ou de [`collectContext`](/docs/integrations/paraglide/reference/collect-context) lit le code source de l’application sans jamais lancer son bundler. Elle prend en charge Paraglide JS 1, 2 et 3 avec Node.js 20 ou une version ultérieure. ## Fonctionnement [#how-it-works] | Étape | Ce qu'elle détermine | | ---------------------------------- | ----------------------------------------------------------------- | | [Fichiers](#files) | Les fichiers sources analysés. | | [Importations](#imports) | Les importations qui pointent vers un fichier Paraglide JS. | | [Répertoires de sortie](#outdirs) | Les répertoires qui contiennent la sortie de Paraglide JS. | | [Projets inlang](#inlang-projects) | Les fichiers de messages qui reçoivent un fichier de métadonnées. | | [Utilisations](#usages) | L'endroit où chaque message est utilisé. | ## Fichiers [#files] Les fichiers analysés sont ceux couverts par [`include`](/docs/integrations/paraglide/reference/collect-context#include), à l’exception de ceux couverts par [`exclude`](/docs/integrations/paraglide/reference/collect-context#exclude), de `node_modules`, des sorties de compilation et de framework, ainsi que de tout ce qu’ignore un `.gitignore`. Les fichiers situés en dehors du projet sont analysés lorsque `include` les mentionne (`../shared`). Un fichier qui ne peut pas être analysé est ignoré et un avertissement est émis. Pour les formats autres que JavaScript, TypeScript et JSX, consultez [Formats de fichiers pris en charge](/docs/integrations/paraglide/reference/file-formats). ## Importations [#imports] Les importations ne sont jamais identifiées d’après leur texte. Chacune est résolue, suivie à travers les réexportations (ESM et CommonJS), et n’est comptabilisée que si elle aboutit à un fichier Paraglide JS. Elles sont résolues comme le ferait le bundler de l’application, mais sans l’exécuter. Les alias proviennent, dans l’ordre, de : 1. L’option [`alias`](/docs/integrations/paraglide/reference/collect-context#alias). 2. Le premier fichier `vite.config.*`, `webpack.config.*` ou `rspack.config.*` trouvé. Celui de Vite est résolu par l’instance de Vite du projet lui-même, si bien que les alias de plugin (`$lib` de SvelteKit) et les chemins relatifs à la racine (`/src/a.js`) fonctionnent. Une configuration webpack ou rspack est importée : une configuration en TypeScript nécessite donc une version de Node.js capable d’exécuter du TypeScript. Ses alias `name$` et ses alias génériques (`"@/*"`) fonctionnent. 3. `paths` dans `tsconfig.json` et `imports` dans `package.json`. Si aucune configuration de bundler n’a pu être lue, les importations non résolues sont répertoriées dans un avertissement, car il peut s’agir d’alias non déclarés. (Voir [Résoudre les importations](/docs/integrations/paraglide/guides/resolving-imports)). ### Importations automatiques Les noms utilisés sans importation sont lus depuis les fichiers `.d.ts` générés par unplugin-auto-import, unplugin-vue-components et Nuxt. Déclarez les autres avec [`autoImports`](/docs/integrations/paraglide/reference/collect-context#auto-imports). ## Répertoires de sortie [#outdirs] Les répertoires de sortie de Paraglide JS sont détectés automatiquement : plusieurs projets Paraglide JS au sein d'une même application ne nécessitent donc aucune configuration initiale. Un répertoire est retenu s'il contient exactement ce que génère la version installée de Paraglide JS, sur le disque ou sous forme de modules virtuels. Pour Paraglide JS 1, il suffit qu'il présente la même structure. Un répertoire qui ressemble à un répertoire de sortie mais ne passe pas la vérification est ignoré et un avertissement est émis. Ajoutez-le à [`outdirs`](/docs/integrations/paraglide/reference/collect-context#outdirs) pour l'utiliser malgré tout. Si aucun répertoire de sortie n'est trouvé, un avertissement indique qu'aucune utilisation ne peut être enregistrée. ## Projets inlang [#inlang-projects] Chaque répertoire de sortie est associé à un projet inlang, dont les fichiers de messages du paramètre régional de base reçoivent les métadonnées. Le projet retenu est, par ordre de priorité : 1. Celui que le `README.md` du répertoire de sortie désigne comme le projet à partir duquel il a été compilé. 2. L'unique répertoire `*.inlang` situé entre [`root`](/docs/integrations/paraglide/reference/collect-context#root) et la racine du monorepo. 3. S'il existe plusieurs répertoires de ce type, celui qui définit le plus grand nombre de messages du répertoire de sortie. [`inlangProjects`](/docs/integrations/paraglide/reference/collect-context#inlang-projects) remplace cette recherche. Un répertoire de sortie sans projet déclenche un avertissement, et aucun fichier de métadonnées n'est généré pour ses messages. ## Utilisations [#usages] Les valeurs sont suivies grâce à l’analyse de portée de typescript-eslint, à travers : * Les alias (`const t = m`), la déstructuration et la réaffectation * Les décompositions d’objets (spread) * Les arguments de fonction et les valeurs par défaut des paramètres * Les props de composant, d’un module à l’autre et depuis les modèles * Les clés calculées (`m["a"]`, `m[c ? "a" : "b"]`) Un message est considéré comme utilisé dès lors qu’il est : | Utilisation | Exemple | | -------------------------------- | ----------------- | | Appelé | `m.tos()` | | Appelé via l’une de ses méthodes | `m.tos.parts()` | | Référencé sans être appelé | `message={m.tos}` | Les utilisations de messages absents du catalogue généré sont signalées dans un avertissement. Par défaut, les fichiers Paraglide JS sont `messages.js`, les modules de `messages/`, `runtime.js`, `server.js`, `registry.js`, ainsi que les paquets d’adaptateurs de framework de Paraglide (voir [Cibles](/docs/integrations/paraglide/reference/extension-api#targets)). ## Limites [#limits] * **Alias :** d'une configuration de bundler, seuls ses alias et la racine de Vite sont extraits, pas les modules virtuels de ses plugins. Les configurations Next.js, Nuxt et Astro ne sont pas lues ; leurs alias proviennent de `tsconfig.json`. * **Autres cibles :** les utilisations des fonctions d'exécution et des composants d'adaptateur sont analysées, mais pas écrites. Seuls les messages disposent d'une clé sous laquelle les écrire. * **Flux de valeurs :** le suivi s'arrête aux valeurs de retour, au Contexte React, à `provide`/`inject`, aux tableaux et aux objets assignés ultérieurement. Une lecture qui suit une réaffectation inconditionnelle ne voit que la nouvelle valeur. Les boucles ne sont pas modélisées. * **Props :** les props sont suivies dans les composants Svelte, Vue et Astro, mais pas dans les composants enregistrés avec `app.component()` ni dans ceux affichés avec ``. * **Clés calculées :** une clé comportant plus de 16 alternatives devient `*`, qui ne correspond à aucun message en particulier. * **CommonJS :** les exports qui ne se trouvent pas au niveau supérieur d'un module ne sont pas suivis. * **Fichiers Astro mal formés :** après une `{` non fermée, le reste de l'élément est perdu. Avec `@astrojs/compiler` seul (Astro 6 et versions antérieures), c'est le reste de la ligne qui est perdu. ## Sitemap See the full [sitemap](https://generaltranslation.com/sitemap.md) for all pages.