# General Translation Key Concepts: Contenido dinámico
URL: https://generaltranslation.com/es/docs/key-concepts/dynamic-content.mdx
---
title: Contenido dinámico
description: Un breve resumen sobre cómo trabajar con el contenido dinámico en GT.
---
## Resumen
**El contenido dinámico** es generalmente cualquier contenido que puede cambiar según el usuario, el contexto, el entorno, etc.
Esto contrasta con el **contenido estático**, que permanece igual independientemente del usuario, el contexto, el entorno, etc.
En resumen
* El contenido estático nunca cambia (cadenas sin procesar, texto, etc.).
* El contenido dinámico puede cambiar (nombres, correos electrónicos, hora, idioma, etc.).
**¿Qué es el contenido estático?**
El contenido estático generalmente se refiere a cualquier texto sin procesar que existe en el bundle que se entrega a tus usuarios.
Una buena regla general es que cualquier texto o cadena que un desarrollador pueda leer en el código de origen es texto estático.
Por ejemplo, considera este archivo:
```jsx title="Landing.jsx" copy
export default function Landing() {
return (
<> Welcome to my app!
);
}
```
El texto "Welcome to my app!" es contenido estático porque nunca cambia.
Pero ¿qué pasaría si quisiéramos cambiar la página para que respondiera en función de si el usuario ha iniciado sesión?
```jsx title="Landing.jsx" copy
export default function Landing(user) {
if (user) {
return (
Welcome to my app, {user.name}!
);
}
return (
Welcome to my app!
);
}
```
Aunque estas dos frases se renderizan de forma condicional, ambas se consideran texto estático.
Recuerda nuestra regla general: podemos ver este contenido al leer el código de origen en `landing.jsx`.
Sin embargo, `{user.name}` se considera contenido dinámico porque puede cambiar.
No podemos saber qué se renderizará en la pantalla del usuario con solo leer el archivo `landing.jsx`.
## "Hacer Tx o no hacer Tx"
A veces queremos traducir contenido dinámico, pero otras veces queremos que permanezca igual.
Un buen ejemplo sería la dirección de correo electrónico o el nombre de un usuario.
Otro ejemplo podría ser el saldo de una cuenta bancaria o el número de la seguridad social de un usuario.
Estos elementos (1) probablemente no necesiten traducción cuando tu aplicación se renderiza en un idioma diferente y (2) pueden variar (en este caso, de un usuario a otro).
### Ejemplo
```jsx title="Greeting.jsx" copy
import { T, Var } from 'gt-next'
export default function Greeting(name) {
return (
Hello, {name}!
);
}
```
En lo que respecta a la traducción, esto tiene dos ventajas:
1. No tienes que crear una traducción para cada nombre posible.
* Al usar ``, solo generamos una traducción que, en esencia, se vería así:
* `¡Hola, ${name}!`
* Si no usamos ``, tendríamos que realizar una traducción bajo demanda para cada nombre único:
* "¡Hola, Alice!", "¡Hola, Bob!", "¡Hola, Charlie!", "¡Hola, David!", ...
2. Tampoco tienes que preocuparte de que los nombres se traduzcan a otra forma: (es decir, "¡Hola, Alicia!", "¡Hola, Roberto!", ...).
Como puedes ver, el componente `` debe usarse para envolver cualquier contenido que deba permanecer igual independientemente de la configuración regional.
De esta forma, evitamos tener que crear traducciones para cada valor posible del contenido dinámico.
Al envolver información privada en un componente ``, puedes asegurarte de que esa información no se envíe a la API de General Translation.
**Excepciones**
Las excepciones a la afirmación anterior son (1) en el caso de un componente `` anidado usado dentro de un componente `` (es decir, el elemento hijo del componente `` anidado se traducirá)
o (2) cuando los datos se pasan intencionadamente a nuestra API por algún otro medio dentro de un elemento hijo del componente `` (es decir, una llamada `fetch`).
Sin embargo, este no es el uso previsto del componente `` ni de la API de General Translation, y hacerlo puede perjudicar el tiempo de carga y el rendimiento.