# KDNA 国际化策略 (i18n)

## 原则

KDNA 格式本身是语言无关的。一个 KDNA 文件可以用任何语言编写。

## 语言选择建议

### 用领域原生语言编写 KDNA

如果一个领域的专业知识沉淀在中文语境中（例如：中国互联网产品决策、中式管理复盘），KDNA 文件应该用中文编写。翻译会丢失术语的精确边界和文化的默认假设。

如果一个领域是全球通用的（例如：代码审查、安全审计），英文是推荐语言，以最大化兼容性。

### 不要翻译 KDNA

将英文 KDNA 翻译成中文不会产生一个"中文 KDNA"，只会产生一个翻译版本。概念边界、误解、触发信号在翻译后可能不再成立。

举例：英文 communication KDNA 中的 banned term `"winning the conversation"` 翻译为 `"赢得对话"` 后，在中国文化语境中的含义和触发场景可能完全不同。

### 中文领域应该从零构建

一个好的中文 KDNA 领域不是翻译产物，而是中文语境下原生提取的判断结构。用中文编写 authoring sentence，从中文场景中提取公理和误解。

## 文件命名

KDNA 文件名保持不变（`KDNA_Core.json` 等），不按语言区分。语言信息内嵌在文件内容和 `meta.domain` 中。

## 领域命名

建议中文领域使用拼音或英文命名作为 domain name：

```
"domain": "product_decision"     # 推荐：英文 slug，便于代码引用
"domain": "chanpin_juece"        # 可选：拼音 slug
```

在 `meta.purpose` 中使用中文说明领域用途。

## 文档

核心文档（SPEC、authoring guide）保持英文。中文用户通过以下文件获取信息：

- `README.zh.md` — 中文项目概述
- `docs/kdna-in-chinese.md` — 中文编写指南
- 中文示例领域中的内联注释

## 社区贡献

欢迎提交中文 KDNA 领域。提交时请确保：

1. 领域内容为原生中文编写（非翻译）
2. domain name 使用英文或拼音 slug
3. 各文件的 `meta.purpose` 和 `meta.load_condition` 使用中文
4. 通过 `kdna-lint` 校验
5. 附带 README 说明领域背景和适用场景
