# General Translation Overview: 核心概念
URL: https://generaltranslation.com/zh/docs/overview/key-concepts.mdx
---

title: 核心概念
description: "了解 General Translation 背后的核心概念，包括国际化、本地化、翻译、区域设置和上下文"

---

General Translation 可将你的产品本地化为任意语言。本页将用通俗易懂的语言介绍这一过程背后的核心概念。

## 国际化、本地化和翻译 [#i18n-l10n]

这三个术语彼此相关，但各有区别。理清它们有助于更顺畅地阅读文档。

### 国际化 (i18n) 

国际化，也写作 **i18n**，是指让代码库具备支持多种区域设置的能力，并能处理与区域设置相关的细节，例如日期和数字、复数、货币以及布局 (例如从右向左书写的语言) 。

这通常通过国际化库来实现，例如 React 应用可使用 [`gt-react`](/docs/react/react-quickstart)，Next.js 可使用 [`gt-next`](/docs/react/nextjs-quickstart)，由它们替你处理这些工作。

国际化不同于翻译内容或组件。它的作用是让代码库为支持翻译和本地化做好准备。

### 翻译

翻译是指将内容从一种语言或方言转换成另一种语言或方言。每种语言都由一个[区域设置代码](#locales)标识。

*例如：将* `es` * (西班牙语) 翻译为* `en-US` * (美式英语) 时，就是把西班牙语内容改写成美式英语。将同一源内容翻译为* `en-GB` *时，则会生成英式英语。方言也同样重要——将* `en-GB` *翻译为* `en-US` *时，会把英式英语改写成美式英语。*

```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"
```

### 本地化 (l10n) 

本地化，也写作 **l10n**，是指让产品适配特定区域设置的过程。在 General Translation，我们将本地化作为整个工作流程的统称：国际化、翻译，以及将两者衔接起来的工具。我们构建了完整的本地化技术栈来覆盖这一整套工作流程。

本地化也不止于语言。根据不同的区域设置，它还可能意味着支持以不同的 Currency 付款、采用不同的日期和数字格式，以及遵守当地法规。

## 区域设置和区域设置代码 [#locales]

**区域设置**是指一种语言或方言。**区域设置代码**是用于表示某个区域设置的标准化代码。在本文档中，“区域设置”通常指区域设置代码。

*示例：* `en-US` *是表示美国英语的区域设置代码。*

区域设置代码会告诉 General Translation 源文件是用什么语言编写的、要翻译成什么语言，以及如何格式化日期、数字和 Currency 等与区域设置相关的值。

### 区域设置代码的工作方式

General Translation 使用 **BCP 47** 语言标签标准。一个区域设置代码最多可由三个子标签组成，并以 `-` 分隔：

* **语言** (必填) ：主要语言，例如英语的 `en` 或中文的 `zh`。
* **文字系统** (可选) ：书写系统，例如表示繁体中文的 `Hant`。
* **地区** (可选) ：国家或地区，例如表示美国的 `US`。

代码既可以是通用的，也可以是更具体的：

* `zh` 表示中文。
* `zh-Hant` 表示使用繁体字书写的中文。
* `zh-Hant-HK` 表示香港使用的繁体中文。

完整说明请参阅[理解区域设置代码](/docs/platform/core/guides/locale-codes)以及可搜索的[支持的区域设置](/docs/platform/dashboard/reference/supported-locales)列表。

### 源区域设置和目标区域设置

* **源区域设置**是你的内容所使用的语言 (也称为默认区域设置) 。
* **目标区域设置**是你要翻译成的语言。

大多数项目都有一个源区域设置和一个或多个目标区域设置。

## 翻译上下文 [#context]

**上下文**用于告诉 AI 应该如何理解并翻译你的产品。良好的上下文能让译文体现你的品牌、产品和表达风格，而不是看起来像千篇一律的机器翻译。

上下文可帮助 General Translation：

* 保留永远不应翻译的品牌名和产品名。
* 消除词义歧义——例如，“cells”究竟是指房间、手机、电池、细胞，还是电子表格单元格。
* 在你的组织和项目之间保持术语和风格的一致性。

General Translation 通过 **上下文组** 应用上下文，它由两部分组成：

* **词汇表**定义关键术语：需要统一处理的产品名称、功能名称和技术术语。
* **指令**定义风格和语气：受众、正式程度、约定规范和格式。

请参阅[添加翻译上下文](/docs/platform/dashboard/guides/adding-translation-context)进行设置。

## 静态内容和动态内容 [#content]

理解静态内容与动态内容的区别，有助于你判断哪些内容需要翻译。

* **静态内容** 永远不会变化：开发者可以在源代码中直接看到的原始文本和字符串，例如“Welcome to my app!”。一个简单的经验法则是，凡是你能直接在源代码里读到的文本，都是静态内容——即使这些字符串只会在特定条件下渲染。静态内容通常都应翻译，除非它是专有名词。
* **动态内容** 会在 Runtime 根据用户、环境或数据发生变化：例如用户名、电子邮件地址或账户余额。仅靠阅读源代码，你无法知道它的值。当动态内容会归结为一组有限且已知的情况时——例如数量的单数或复数，或像 *active* 与 *archived* 这样的值——General Translation 可以基于它进行分支，并使用 [`<Plural>`](/docs/react/reference/components/plural) 和 [`<Branch>`](/docs/react/reference/components/branch) 这样的逻辑组件，或通过 [`<Derive>`](/docs/react/reference/components/derive) 列出所有可能的值并翻译每个变体，从而为每种情况生成正确的翻译。请参阅 [处理复数和分支](/docs/react/guides/handling-plurals-and-branches)。

### 变量与格式化

在 i18n libraries 中，你可以将动态值包裹在 [`<Var>`](/docs/react/reference/components/var) 组件中，这样它们在所有语言里都会保持不变：

```jsx
import { T, Var } from 'gt-next';

<T>
  Hello, <Var>{name}</Var>!
</T>;
```

这样做有两个好处：你只需生成一条翻译，例如 `¡Hola, {name}!`，而不必为每个可能的名字分别生成单独的翻译；而且名字本身也永远不会被改写成翻译后的形式。

对于需要重新格式化但不需要翻译的值——例如价格、日期和数字——请改用格式化组件 ([`<Currency>`](/docs/react/reference/components/currency)、[`<DateTime>`](/docs/react/reference/components/datetime) 和 [`<Num>`](/docs/react/reference/components/num)) 。`<Var>`、`<Currency>`、`<DateTime>` 和 `<Num>` 在 `gt-next`、`gt-react` 和 `gt-react-native` 中均可用。

### Private information

`<Var>` 也可用于避免将私人信息——如姓名、电子邮件地址、住址或社会安全号码——纳入翻译。包裹在 `<Var>` 中的内容会按原样渲染，且绝不会发送到 General Translation API。

*注意：例外情况包括在* `<Var>` *内部嵌套了一个* [`<T>`](/docs/react/reference/components/t)&#x20;*&#x20;(其子元素会被翻译) ，或者你在* `<Var>` *内部自行将数据发送到 API (例如发起 fetch 调用) 。这两种情况都不是* `<Var>` *的预期用法。*