# General Translation Key Concepts: Dynamic Content
URL: https://generaltranslation.com/en-GB/docs/key-concepts/dynamic-content.mdx
---
title: Dynamic Content
description: A brief overview of working with Dynamic Content in GT.
---

## Overview

**Dynamic Content** is generally any content that can change based on the user, context, environment, etc.
This contrasts with **Static Content**, which remains the same regardless of the user, context, environment, etc.

<Accordions>
  <Accordion title="What's the difference between dynamic and static content?">
    TL;DR

    * Static Content never changes (raw strings, text, etc.).
    * Dynamic Content can change (names, emails, time, language, etc.).

    **What is Static Content?**

    Static Content generally refers to any raw text that exists in the bundle served to your users.
    A good rule of thumb is that any text or strings a developer can read in the source code are static text.

    For example, consider this file:

    ```jsx title="Landing.jsx" copy

    export default function Landing() {
        return (
            <> Welcome to my app!</>
        );
    }
    ```

    The text, &quot;Welcome to my app!&quot;, is Static Content because it never changes.

    But what if we wanted to change the page so that it responded when the user was logged in:

    ```jsx title="Landing.jsx" copy

    export default function Landing(user) {

        if (user) {
            return (
                <h1> Welcome to my app, {user.name}! </h1>
            );
        }
        
        return (
            <h1> Welcome to my app!</h1>
        );
    }
    ```

    Even though these two phrases are rendered conditionally, they are both still considered static text.
    Remember our rule of thumb: we can see this content by reading the source code in `landing.jsx`.

    However, `{user.name}` is considered dynamic content because it can change.
    We cannot know what will be rendered on the user&#39;s screen just by reading the `landing.jsx` file.
  </Accordion>
</Accordions>

## &quot;To Tx or not to Tx&quot;

Sometimes, we want to translate dynamic content, but at other times we want it to remain the same.

A good example would be a user&#39;s email address or name.
Another example might be a bank account balance or a user&#39;s SSN.
Such items are (1) unlikely to need translation when your app is rendered in a different language and (2) can vary (in this case from user to user).

### Example

```jsx title="Greeting.jsx" copy
import { T, Var } from 'gt-next'

export default function Greeting(name) {
    return (
        <T id='greeting'>
            Hello, <Var>{name}</Var>!
        </T>
    );
}
```

In terms of translation, this has two benefits:

1. You do not have to create a translation for every possible name.
   * Using `<Var>`, we only generate one translation that essentially looks like this:
     * `¡Hola, $&#123;name&#125;!`
   * If we do not use `<Var>`, we would have to perform an on-demand translation for every unique name:
     * &quot;¡Hola, Alice!&quot;, &quot;¡Hola, Bob!&quot;, &quot;¡Hola, Charlie!&quot;, &quot;¡Hola, David!&quot;, ...
2. You also do not have to worry about names themselves being changed to translated versions: (i.e. &quot;¡Hola, Alicia!&quot;, &quot;¡Hola, Roberto!&quot;, ...).

<Callout type="info">
  **Note:** The `<Var>`, `<Currency>`, `<DateTime>`, and `<Num>` components are available in `gt-next`, `gt-react`, and `gt-react-native`.
</Callout>

As you can see, the `<Var>` component should be used to wrap any content that should remain the same regardless of locale.
This avoids the need to create translations for every possible value of the dynamic content.

By wrapping private information in a `<Var>` component, you can ensure that the information is not sent to the General Translation API.

<Callout>
  **Exceptions**

  The exceptions to the statement above are (1) in the case of a nested `<T>` component used inside a `<Var>` component (i.e. the children of the nested `<T>` component will be translated)
  or (2) when data is intentionally passed to our API by some other means within a child of the `<Var>` component (i.e. a fetch call).
  However, this is not the intended use of the `<Var>` component or the General Translation API, and doing so can harm load times and performance.
</Callout>