# General Translation Overview: Key concepts URL: https://generaltranslation.com/en-GB/docs/overview/key-concepts.mdx --- title: Key concepts description: "Understanding the core concepts behind General Translation, including internationalisation, localisation, translation, locales, and context" --- General Translation localises your product into any language. This page explains the core concepts behind that process in plain language. ## Internationalisation, localisation, and translation [#i18n-l10n] These three terms are related but distinct. Getting them straight helps make the docs easier to follow. ### Internationalisation (i18n) Internationalisation, also written **i18n**, is the process of preparing a codebase so that it can support multiple locales and handle locale-aware details such as dates and numbers, plurals, currencies, and layout (for example, for languages that read right-to-left). This is done with an internationalisation library such as [`gt-react`](/docs/react/react-quickstart) for React apps or [`gt-next`](/docs/react/nextjs-quickstart) for Next.js, which handles this work for you. Internationalisation is distinct from translating content or components. It prepares the codebase to support translations and localisation. ### Translation Translation means converting content from one language or dialect into another. Each language is identified by a [locale code](#locales). *Example: translating* `es` *(Spanish) into* `en-US` *(US English) rewrites Spanish content into US English. Translating the same source into* `en-GB` *produces British English instead. Dialect matters, too — translating* `en-GB` *into* `en-US` *rewrites British English as US English.* ```js gt.translate('Tenemos un ascensor', 'en-US'); // "We have an elevator" gt.translate('Tenemos un ascensor', 'en-GB'); // "We have a lift" gt.translate('We have a lift', 'en-US'); // "We have an elevator" ``` ### Localisation (l10n) Localisation, also written **l10n**, is the process of adapting a product for a particular locale. At General Translation, we use localisation as an umbrella term for the whole workflow: internationalisation, translation, and the tooling that ties them together. We've built the full localisation stack to handle this entire workflow. Localisation can also go beyond language. Depending on the locale, it may mean accepting payments in a different currency, formatting dates and numbers differently, and complying with local regulations. ## Locales and locale codes [#locales] A **locale** is a language or dialect. A **locale code** is a standardised way to refer to a locale. Throughout these docs, "locale" usually means the locale code. *Example:* `en-US` *is a locale code for English as spoken in the United States.* Locale codes tell General Translation what language a source file is written in, which language to translate into, and how to format locale-aware values like dates, numbers and currency. ### How locale codes work General Translation uses the **BCP 47** language tag standard. A locale code combines up to three subtags separated by `-`: * **Language** (required): the primary language, such as `en` for English or `zh` for Chinese. * **Script** (optional): the writing system, such as `Hant` for Traditional Chinese characters. * **Region** (optional): the country or region, such as `US` for the United States. Codes can be general or specific: * `zh` is Chinese. * `zh-Hant` is Chinese written with Traditional characters. * `zh-Hant-HK` is Chinese written with Traditional characters, as spoken in Hong Kong. See [Understanding locale codes](/docs/platform/core/guides/locale-codes) for the full breakdown and a searchable [Supported locales](/docs/platform/dashboard/reference/supported-locales) list. ### Source and target locales * The **source locale** is the language your content is written in (also called the default locale). * A **target locale** is a language you translate into. Most projects have one source locale and one or more target locales. ## Translation context [#context] **Context** tells the AI how to interpret and translate your product. Good context is what makes translations reflect your brand, product and voice rather than reading like generic machine output. Context helps General Translation: * Preserve brand and product names that should never be translated. * Resolve ambiguous words — for example, whether "cells" means rooms, phones, bacteria or spreadsheet cells. * Keep terminology and style consistent across your Organization and Projects. General Translation applies context through **Context Groups**, which combine two parts: * **Glossary** defines key terms: product names, feature names, and technical terms that need consistent treatment. * **Directives** define style and tone: audience, formality, conventions, and formatting. See [Adding translation context](/docs/platform/dashboard/guides/adding-translation-context) to set this up. ## Static and dynamic content [#content] Understanding the difference between static and dynamic content helps you decide what should be translated. * **Static content** never changes: raw text and strings a developer can read in the source code, such as "Welcome to my app!". A good rule of thumb is that any text you can read directly in the source is static — even strings that are only rendered conditionally. Static content is translated unless it is a proper noun. * **Dynamic content** can change at runtime based on the user, environment, or data: a user's name, email, or account balance. You cannot know its value by reading the source alone. When dynamic content resolves to a finite set of known cases — a count that is singular or plural, or a value like *active* vs. *archived* — General Translation can branch on it and generate a correct translation for each case, using logical components like [``](/docs/react/reference/components/plural) and [``](/docs/react/reference/components/branch), or [``](/docs/react/reference/components/derive) to catalogue every possible value and translate each variant. See [Handling plurals and branches](/docs/react/guides/handling-plurals-and-branches). ### Variables and formatting In the i18n libraries, you wrap dynamic values in the [``](/docs/react/reference/components/var) component so they stay the same in every language: ```jsx import { T, Var } from 'gt-next'; Hello, {name}! ; ``` This has two benefits: you generate one translation like `¡Hola, {name}!` instead of a separate translation for every possible name, and the name itself is never rewritten into a translated form. For values that should be reformatted but not translated — such as prices, dates and numbers — use the formatting components ([``](/docs/react/reference/components/currency), [``](/docs/react/reference/components/datetime), and [``](/docs/react/reference/components/num)) instead. All of ``, ``, ``, and `` are available in `gt-next`, `gt-react`, and `gt-react-native`. ### Private information `` is also how you keep private information — names, email addresses, addresses, or a Social Security number — out of translations. Content wrapped in `` is rendered as-is and is never sent to the General Translation API. *Note: the exceptions are a nested* [``](/docs/react/reference/components/t) *inside a* `` *(whose children are translated) or data you send to the API yourself from within a* `` *(for example, a fetch call). Neither is the intended use of* ``*.*