# M14 / issue-145 开发日志：admin 中文主编辑与翻译工作区重构

- Issue：`#145`
- 里程碑：`M14 编辑体验与亮点表达重构`
- 分支：`fys-dev/feat-m14-issue-145-admin-translation-workspace`
- 日期：`2026-04-06`

## 背景

上一张 issue 先把后台编辑页从“长表单”收成了“模块工作区”，但字段层面的负担还在：

- 同一个模块里，中文和英文输入框大量并排出现
- 结构字段、主文案字段、翻译字段混在一起
- 模块变多以后，录入效率和理解成本都在上升
- 如果未来继续扩更多语言，当前双列直填几乎没有扩展空间

也就是说，`StandardResume` 保留双语模型是对的，但“怎么编辑”已经需要换一套方式。

## 本次目标

- 保持 `{ zh, en }` 数据模型不变
- 把后台编辑方式改成“中文主编辑 + 英文翻译工作区”
- 给后续 AI / 工具翻译预留动作入口
- 保证保存 payload 继续维持当前标准简历结构

## 非目标

- 不新增真实翻译 API
- 不改后端 schema
- 不扩成多语言系统重构
- 不改公开页展示逻辑

## 实际改动

### 1. 建立编辑模式切换

更新：

- [resume-draft-editor-panel.tsx](/Users/fri/Desktop/personal/my-resume/apps/admin/components/resume-draft-editor-panel.tsx)

编辑器顶部新增了两种模式：

- 中文主编辑
- 英文翻译工作区

中文主编辑负责：

- 中文主文案
- 条目增删
- 时间
- 技术栈
- 链接地址

英文翻译工作区负责：

- 所有 `LocalizedText` 的英文内容
- 链接标签英文
- 多行亮点 / 兴趣方向的英文内容

这样结构字段和翻译字段不再挤在同一屏里。

### 2. 用“翻译参考 + 英文输入”取代双列直填

本轮新增了 `LocalizedEditorField`，在英文工作区里统一提供：

- 当前英文输入框
- 上方中文参考

这样用户在翻译时仍然能看到中文来源，但不会再被左右双列持续干扰。

这一步的关键不在于减少字段数量，而在于把“主编辑”和“翻译校对”从同一个动作拆成两个更清楚的动作。

### 3. 为各模块补上翻译工作流动作

英文翻译工作区里，每个主模块都补了三类动作：

- `复制中文到英文`
- `清空英文`
- `AI 翻译入口预留`

其中前两者已经能直接工作，第三个先只提供占位反馈，用来明确后续接 AI / 工具翻译的挂点，而不是这轮就硬接一条假的翻译链路。

### 4. 保持现有 payload 和保存链路不变

虽然编辑交互变了，但保存时仍然提交标准简历模型：

- `profile`
- `education`
- `experiences`
- `projects`
- `skills`
- `highlights`

也就是说，这轮改变的是“后台交互方式”，不是“数据契约”。

## Review 记录

### 是否符合当前 issue 目标

符合。

这一轮只围绕 admin 编辑方式展开，没有碰 server schema，也没有提前扩到 web 展示端。

### 为什么不继续坚持双列直填

因为双列直填的真实问题不是“视觉难看”，而是它把两件不同的事绑在了一起：

- 写主内容
- 做翻译

这两件事的节奏、注意力和操作粒度都不一样。把它们硬放在一屏里，只会让维护成本越来越高。

### 为什么还保留 `{ zh, en }` 模型

因为数据模型本身没错，它仍然是：

- 对前端展示清楚
- 对导出稳定
- 对后端校验直接

真正应该调整的是“后台怎么维护它”，而不是为了躲开交互问题去推翻模型。

## 自测结果

已执行：

- `pnpm --filter @my-resume/admin test`
- `pnpm --filter @my-resume/admin typecheck`

结果：

- 单元测试通过
- 类型检查通过

## 后续可沉淀为教程的点

- 为什么双语模型不等于双列直填
- 为什么“中文主编辑 + 翻译工作区”更适合后续扩展到 AI / 工具翻译
- 为什么在教程型项目里，应该先把翻译工作流立住，再接真实翻译能力
