# General Translation Integrations: Detección de usos
URL: https://generaltranslation.com/es/docs/integrations/paraglide/reference/usage-detection.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Cómo se seleccionan los archivos de origen, cómo se resuelven las importaciones y cómo se detectan los usos de mensajes de Paraglide JS. Referencia sobre la detección de usos.

Cada ejecución de [`paraglide-context`](/docs/integrations/paraglide/reference/paraglide-context) o [`collectContext`](/docs/integrations/paraglide/reference/collect-context) lee el código fuente de la aplicación sin ejecutar nunca su empaquetador. Es compatible con Paraglide JS 1, 2 y 3 en Node.js 20 o versiones posteriores.

## Cómo funciona [#how-it-works]

| Paso                                    | Qué determina                                             |
| --------------------------------------- | --------------------------------------------------------- |
| [Archivos](#files)                      | Qué archivos de origen se analizan.                       |
| [Importaciones](#imports)               | Qué importaciones apuntan a un archivo de Paraglide JS.   |
| [Directorios de salida](#outdirs)       | Qué directorios contienen la salida de Paraglide JS.      |
| [Proyectos de inlang](#inlang-projects) | Qué archivos de mensajes reciben un archivo de metadatos. |
| [Usos](#usages)                         | Dónde se usa cada mensaje.                                |

## Archivos [#files]

Se analizan los archivos de [`include`](/docs/integrations/paraglide/reference/collect-context#include), excepto los de [`exclude`](/docs/integrations/paraglide/reference/collect-context#exclude), `node_modules`, la salida de compilación y del framework, y cualquier archivo ignorado por un `.gitignore`. Los archivos situados fuera del proyecto se analizan si aparecen en `include` (`../shared`).

Si un archivo no se puede analizar sintácticamente, se omite y se muestra una advertencia. Para formatos distintos de JavaScript, TypeScript y JSX, consulta [Formatos de archivo compatibles](/docs/integrations/paraglide/reference/file-formats).

## Importaciones [#imports]

Las importaciones nunca se identifican por su texto. Cada una se resuelve, se sigue a través de las reexportaciones (ESM y CommonJS) y solo se cuenta si termina en un archivo de Paraglide JS.

Se resuelven igual que lo haría el empaquetador de la aplicación, pero sin ejecutarlo. Los alias se obtienen, por orden, de:

1. La opción [`alias`](/docs/integrations/paraglide/reference/collect-context#alias).
2. El primer `vite.config.*`, `webpack.config.*` o `rspack.config.*` que se encuentre. El de Vite se resuelve con el propio Vite del proyecto, por lo que funcionan los alias de plugins (el `$lib` de SvelteKit) y las rutas desde la raíz (`/src/a.js`). Las configuraciones de webpack o rspack se importan, así que una configuración en TypeScript requiere una versión de Node.js capaz de ejecutar TypeScript. Admiten alias `name$` y alias con comodines (`"@/*"`).
3. `paths` en `tsconfig.json` e `imports` en `package.json`.

Si no se pudo leer ninguna configuración del empaquetador, las importaciones que no se resolvieron se muestran en una advertencia, ya que podrían ser alias no declarados. (Consulta [Resolución de importaciones](/docs/integrations/paraglide/guides/resolving-imports)).

### Importaciones automáticas

Los nombres que se usan sin importarlos se obtienen de los archivos `.d.ts` de unplugin-auto-import, unplugin-vue-components y Nuxt. Declara el resto con [`autoImports`](/docs/integrations/paraglide/reference/collect-context#auto-imports).

## Directorios de salida [#outdirs]

Los directorios de salida de Paraglide JS se detectan automáticamente, por lo que no hace falta ninguna configuración inicial para tener varios proyectos de Paraglide JS en una misma aplicación. Un directorio se considera válido cuando contiene exactamente lo que genera la versión instalada de Paraglide JS, ya sea en disco o como módulos virtuales. En Paraglide JS 1, basta con que tenga la misma estructura.

Si un directorio parece de salida pero no supera la comprobación, se omite y se muestra una advertencia. Inclúyalo en [`outdirs`](/docs/integrations/paraglide/reference/collect-context#outdirs) para usarlo de todos modos. Si no se encuentra ningún directorio de salida, se muestra una advertencia que indica que no se puede registrar ningún uso.

## Proyectos de inlang [#inlang-projects]

Cada directorio de salida se asocia a un proyecto de inlang, cuyos archivos de mensajes de la configuración regional base reciben los metadatos. El proyecto se determina, por orden de prioridad, así:

1. El que el `README.md` del directorio de salida indica como el proyecto a partir del cual se compiló.
2. El único directorio `*.inlang` entre [`root`](/docs/integrations/paraglide/reference/collect-context#root) y la raíz del monorepo.
3. Si hay varios directorios de ese tipo, el que define más mensajes del directorio de salida.

[`inlangProjects`](/docs/integrations/paraglide/reference/collect-context#inlang-projects) sustituye esa búsqueda. Si un directorio de salida no tiene proyecto, se emite una advertencia y sus mensajes no reciben ningún archivo de metadatos.

## Usos [#usages]

Los valores se rastrean mediante el análisis de ámbitos de typescript-eslint a través de:

* Alias (`const t = m`), desestructuración y reasignación
* Propagación de objetos (spread)
* Argumentos de funciones y valores predeterminados de parámetros
* Props de componentes, entre módulos y desde plantillas
* Claves calculadas (`m["a"]`, `m[c ? "a" : "b"]`)

Un mensaje se considera usado siempre que se:

| Uso                                  | Ejemplo           |
| ------------------------------------ | ----------------- |
| Llama                                | `m.tos()`         |
| Llama a través de uno de sus métodos | `m.tos.parts()`   |
| Referencia sin llamarlo              | `message={m.tos}` |

Los usos de mensajes que no están en el catálogo generado se muestran en una advertencia.

De forma predeterminada, los archivos de Paraglide JS son `messages.js`, los módulos de `messages/`, `runtime.js`, `server.js`, `registry.js` y los paquetes de adaptadores de frameworks de Paraglide. (Consulta [Targets](/docs/integrations/paraglide/reference/extension-api#targets)).

## Limitaciones [#limits]

* **Alias:** de la configuración de un empaquetador solo se obtienen sus alias y la raíz de Vite, no los módulos virtuales de sus plugins. Las configuraciones de Next.js, Nuxt y Astro no se leen; sus alias se toman de `tsconfig.json`.
* **Otros destinos:** los usos de funciones de tiempo de ejecución y de componentes de adaptador se analizan, pero no se escriben. Solo los mensajes tienen una clave en la que escribirse.
* **Flujo de valores:** el seguimiento se detiene en los valores de retorno, el Contexto de React, `provide`/`inject`, las listas y los objetos asignados posteriormente. Una lectura posterior a una reasignación incondicional solo ve el nuevo valor. Los bucles no se modelan.
* **Props:** las props se siguen dentro de los componentes de Svelte, Vue y Astro, pero no dentro de los componentes registrados con `app.component()` ni de los renderizados con `<svelte:component this={X}>`.
* **Claves calculadas:** una clave con más de 16 alternativas se convierte en `*`, que no coincide con ningún mensaje concreto.
* **CommonJS:** no se siguen las exportaciones que no están en el nivel superior de un módulo.
* **Archivos de Astro con errores:** tras una `{` sin cerrar, se pierde el resto del elemento. Si solo se dispone de `@astrojs/compiler` (Astro 6 y anteriores), se pierde el resto de la línea.

## Sitemap

See the full [sitemap](https://generaltranslation.com/sitemap.md) for all pages.