Un glosario le da al motor de localización control total sobre términos específicos: ya sea para imponer una traducción precisa o para evitar que se traduzcan por completo. Las reglas del glosario tienen prioridad sobre el criterio del modelo, así que el motor las aplica de forma consistente en cada solicitud.
Cómo funciona#
Cada elemento del glosario pertenece a un motor de localización y se aplica a un par de idioma de origen e idioma de destino (o * para cualquier idioma). Cuando el motor procesa una solicitud de traducción, recupera los elementos relevantes del glosario mediante búsqueda semántica: compara el significado del texto de entrada con los términos almacenados, no solo coincidencias exactas de texto.
| Campo | Descripción |
|---|---|
| Idioma de origen | El idioma del texto de origen, o * para cualquier origen |
| Idioma de destino | El idioma del texto de destino, o * para cualquier destino |
| Texto de origen | El término en el idioma de origen |
| Texto de destino | La traducción obligatoria (o el mismo término, para elementos no traducibles) |
| Tipo | custom_translation o non_translatable |
| Sugerencia | Contexto opcional para desambiguar el término (p. ej., "sustantivo, función del producto") |
Tipos de glosario#
Traducciones personalizadas#
Fuerza una traducción específica para un término. El motor siempre usará tu traducción en lugar de la del modelo.
| Texto de origen | Texto de destino | Idioma de origen | Idioma de destino |
|---|---|---|---|
| Deploy | Bereitstellen | en | de |
| 911 | 112 | en | de |
| workspace | espace de travail | en | fr |
Usa traducciones personalizadas para:
- Terminología de producto con traducciones ya establecidas
- Adaptaciones culturales (números de emergencia, unidades de medida)
- Términos en los que el modelo suele elegir el sinónimo equivocado
No traducibles#
Evita que se traduzca un término. El motor conserva el texto de origen tal cual.
| Texto de origen | Texto de destino | Tipo |
|---|---|---|
| Lingo.dev | Lingo.dev | non_translatable |
| OAuth | OAuth | non_translatable |
| GraphQL | GraphQL | non_translatable |
Usa elementos no traducibles para:
- Nombres de marca y de productos
- Protocolos y estándares técnicos
- Nombres propios que deben mantenerse en el idioma de origen
Coincidencia semántica#
Los elementos del glosario se identifican por significado, no por comparación exacta de texto. Cuando el motor recibe una solicitud de traducción, genera embeddings para el texto de entrada y encuentra elementos del glosario con términos de origen semánticamente similares.
Eso significa que una entrada de glosario para "Deploy" también coincidirá con "Deploying", "deployment" y "deploy your application", sin necesidad de crear entradas separadas para cada variación.
Campo de sugerencia
Usa el campo de sugerencia para desambiguar términos con varios significados. Por ejemplo, una entrada de glosario para "bank" con la sugerencia "financial institution" no coincidirá con "river bank" en el texto de entrada.
Idiomas comodín#
Configura el idioma de origen o de destino como * para aplicar un elemento del glosario a todos los pares de idiomas.
Patrones comunes:
| Texto de origen | Idioma de origen | Idioma de destino | Caso de uso |
|---|---|---|---|
| Lingo.dev | * | * | No traduzcas nunca el nombre de la marca en ningún idioma |
| API | en | * | Mantén "API" sin traducir en todos los idiomas de destino |
| Deploy | en | de | Usa una traducción específica al alemán para este término en inglés |
Los elementos comodín y los específicos por idioma se combinan; no se reemplazan entre sí.
Coincidencia de idiomas#
Los elementos del glosario coinciden entre variantes regionales, no solo con códigos de idioma exactos. Una entrada de se aplica a de-DE; una entrada de-DE se aplica a una solicitud simple de de. Variantes hermanas como de-DE y de-AT nunca comparten entradas. Cuando coinciden varias, prevalece la región predeterminada de CLDR. Las mismas reglas se aplican a las voces de marca, las instrucciones y las configuraciones del modelo. Consulta Locale Resolution para ver el comportamiento completo, incluida la regla de seguridad de escritura para las traducciones personalizadas.
Glosario vs. instrucciones vs. voces de marca#
Cada uno cumple una función distinta dentro de la configuración del motor:
| Glosario | Instrucción | Voz de marca | |
|---|---|---|---|
| Controla | Términos individuales | Reglas lingüísticas | Tono y estilo generales |
| Granularidad | Por término | Por regla | Por idioma |
| Coincidencia | Semántica (por significado) | Todas las incluidas para ese idioma | Todas las incluidas para ese idioma |
| Prioridad | Máxima: prevalece sobre el criterio del modelo | Media: orienta al modelo | Mínima: aporta contexto |
| Ejemplo | "Deploy" → "Bereitstellen" | "Abbreviate Straße to Str." | "Use informal du, technical tone" |
Prioridad de reglas
Los términos del glosario tienen la máxima prioridad dentro de la jerarquía de reglas del motor. Si un elemento del glosario entra en conflicto con una instrucción, el glosario prevalece. Diseña las instrucciones para complementar el glosario, no para duplicarlo.
Uso de glosarios con la API#
Los elementos del glosario se aplican automáticamente cuando llamas al localize endpoint. El motor recupera los elementos semánticamente relevantes para el par de idioma de origen y destino, y los incluye en el prompt.
No necesitas parámetros adicionales: el motor se encarga de recuperarlos e inyectarlos.
Administrar glosarios con MCP#
Si usas el servidor MCP de Lingo.dev, tu asistente de programación con IA puede administrar elementos del glosario directamente:
"Add a glossary entry: translate 'workspace' to 'espace de travail'
for English to French.""Mark 'GraphQL' as non-translatable for all locales."