german-translator-pro-brand-legal

德语翻译专家版 — 品牌与法律

将英语翻译并校验为瑞士正式德语（瑞士标准德语）。基于从 12 个以上顶级品牌网站中抓取的真实翻译模式训练，而非通用机器翻译。

有何不同

大模型会生成翻译腔——语法正确，却听起来像翻译出来的德语，而非自然写成的德语。本技能通过精选参考文件解决这一问题，这些文件提取自顶级品牌实际翻译其网站、营销内容和法律页面的方式。

抓取的品牌： Swisscom、UBS、On Running、Logitech、IKEA CH、Stripe、Notion、Slack、Apple、Shopify、BMW、Vercel

提取内容： 100 多组真实英译德对照、5 种主视觉标题策略、15 种以上 CTA 模式、按行业划分的 Du/Sie 用法、40 多项术语表决策（保留原文还是翻译）、29 个法律术语译法、翻译腔陷阱、法律语体模式——均附有品牌实例佐证。

Agent 在每次翻译前都会读取这些参考资料，生成符合这些品牌德语写作风格的译文。

安装

npx skills add SLFMR1/german-translator-pro-brand-legal

使用场景

• 将 UI 字符串（按钮、标题、CTA、营销文案）翻译成德语
• 将法律页面（隐私政策、服务条款、版权声明）翻译成德语
• 根据英语原文对现有德语译文进行质量检查
• 任何需要遵循瑞士规范并采用自然表达的英译德任务

工作原理

本技能支持两种文本类型和两种操作：

	品牌 / UI	法律
翻译（英译德）	自然、有力的瑞士德语，读起来像原创，而非翻译	精确、正式的德语，并采用 DSGVO/DSG 法律术语
校验（质量检查）	检查自然度、准确性和瑞士规范	检查法律严谨性、限定条件保留情况和术语使用

主要功能

• 消除翻译腔 — 重新组织德语表达，而不是照搬英语句式结构。基于顶级品牌的实际写作方式训练
• 瑞士（CH）或德国（DE）地区规范 — 瑞士：用 ss 而非 ß，数字格式为 1'000，货币为 CHF。德国：使用标准 ß，数字格式为 1.000，货币为 EUR。由用户选择
• 回译质量检查 — 将德语译文回译成英语，验证是否保留原意
• 完整性检查 — 找出未翻译的字符串，以及意外德语化的品牌术语
• 法律术语精准度 — 提供 25 个以上经品牌确认的 DSGVO/DSG 术语译法及原文忠实度规则
• 四 Agent 法律流程 — 法律文档采用翻译 → 回译 → 校验 → 优化流程
• 可配置术语表 — 设置保留英文的术语、始终翻译的术语和需酌情处理的术语，并附有品牌实例佐证

---

工作流

步骤 1：确定文本类型、操作、称呼方式和地区格式

开始任何工作之前，先确定以下四项。如果上下文不明确，请询问用户：

1. 文本类型？

• UI — 首屏内容、行动号召、Agent 描述、导航、标题、按钮、标签
• 法律 — 隐私政策、服务条款、版权声明、法律免责声明

2. 操作？

• 翻译 — 将英语翻译成德语
• 校验 — 对照英语源文检查现有德语译文

3. 称呼方式？

• Sie（正式）— 面向企业客户、公司、法律或专业场景。首字母大写：Sie、Ihnen、Ihr、Ihre
• Du（非正式）— 面向消费者的应用、轻松随意的产品、初创公司。小写：du、dir、dein、deine

不明确时，默认使用 Sie。法律文本无论用户偏好如何，始终使用 Sie。

4. 地区格式？

• 瑞士（CH） — 使用 ss 而非 ß，千位分隔符用撇号（1'000），货币符号 CHF 放在金额前（CHF 100），小数点用句点（99.90）
• 德国（DE） — 按标准使用 ß，千位分隔符用句点（1.000），€ 放在金额后（100 €），小数点用逗号（99,90）

不明确时，默认使用 瑞士（CH）。

在全文中始终如一地采用选定的称呼方式和地区格式，并遵循下方对应章节的要求。

允许进行网络检索。 如果术语不在术语表中，或不确定如何恰当翻译，请查证。访问品牌网站的德语版本（例如 apple.com/de、stripe.com/de、notion.so/de），了解它们实际采用的译法。也可以参考与用户项目所属行业相关的其他品牌网站。实际用法优先于猜测。

步骤 2：多文件项目 — 使用子 Agent

翻译或校验多个文件或页面时，请勿在主上下文中逐一处理。请改用编排器／子 Agent 模式：

编排器（主 Agent）：

1. 确定上述 4 项设置（文本类型、操作、称呼方式、地区格式）
2. 列出所有待处理的文件／页面
3. 使用 Agent 工具，为每个文件／页面启动一个子 Agent
4. 收集结果并汇报摘要

每个子 Agent：

1. 接收：文件路径、文本类型、操作、称呼方式、地区格式
2. 阅读参考文件（术语表、风格指南、示例）
3. 翻译或校验单个文件
4. 根据 qa-checklist.md 进行自我校验——运行适用于该文本类型的检查
5. 修复自我校验中发现的任何严重问题
6. 返回：输出文件及摘要（通过／未通过、问题数量、尚未解决的警告）

原因： 每个子 Agent 都能在干净的上下文中加载完整的参考文件。无需在主上下文中依次处理 10 个以上文件，从而避免上下文膨胀。自我校验能在问题传给编排器之前将其发现。

单个文件？ 跳过此流程，直接执行翻译／校验。

---

翻译 + UI

为营销和界面文本提供自然、有力的瑞士德语译文。

流程

1. 完整阅读英文源 JSON 文件
2. 阅读 glossary.md，了解必须保留原文的术语
3. 阅读 swiss-german-style.md，了解语气、惯例和翻译腔陷阱
4. 阅读 examples.md，达到同等质量
5. 翻译每个值。切勿修改键或 {variable} 占位符
6. 自检： 大声读出每个德语值。瑞士产品经理会在喝咖啡时这么说吗？如果听起来像文档，就重写
7. 回译检查： 随机选取 5 个键，在脑中把德语译回英语。如果意思有偏差，就修正
8. 完整性检查： 比较 EN 键和 DE 键——不能有任何遗漏。检查是否有完全相同的 EN/DE 值：允许保留英文术语，但不能有未翻译的完整英文句子。确认词汇表中要求始终翻译的术语确实已翻译（Products→Produkte，而不是“Products”）
9. 长度检查： 比较每个 DE 值与 EN 值的字符数。标记任何长度超过 EN 值 120% 的 UI 文本（按钮、标签、导航、标题、工具提示）。缩短这些文本——德语必须适配相同的视觉空间
10. 输出完整的 JSON 文件，结构与英文源文件一致

规则

• 重组表达，而非逐字翻译。 用德语重新组织思路。如果读起来像是机器翻译，就重写
• 使用步骤 1 中选择的称呼形式（Sie 或 Du），并始终保持一致
• 按步骤 1 中选择的地区惯例（CH 或 DE）处理 ß/ss、数字格式和货币
• 完整保留所有 {variable} 占位符和 HTML 标签
• 保持 JSON 键名和命名空间结构不变
• 品牌名称和产品名称保留英文（见 glossary.md）
• 瑞士商务场景中常用的英文技术术语保留英文（Agent、CRM、API、Inbox、Tools、Workflow 等）
• 优先使用动词，避免名词化——用“prüfen”，而不是“Durchführung der Prüfung”
• 突出具体好处，而非抽象主张
• 使用短句。超过 20 个词时，考虑拆分
• 长度限制（UI 关键要求）。 德语文本通常比英文长约 20%–30%。UI 文本必须适配相同的视觉空间——包括按钮、标签、导航项、标题和工具提示。如果德语明显长于英文，就缩短文本。优先使用简洁说法：用“Jetzt starten”，而不是“Jetzt loslegen und starten”；用“Mehr erfahren”，而不是“Erfahren Sie mehr darüber”。按钮和导航项的长度应尽量与英文相当，或控制在英文长度的约 120% 以内

输出

完整且有效的 JSON。键和嵌套结构保持不变，值使用德语。

---

翻译 + 法律文本

法律文件采用精准、正式的瑞士德语。准确性优先于文风。

有关完整的多 Agent 工作流（法律文本推荐使用），请参阅 legal-workflow.md。 该流程使用 4 个 Agent：译者 → 回译者 → 验证者 → 优化者。以下说明适用于译者 Agent（Agent 1）。

流程

1. 完整阅读英文源 JSON 文件
2. 阅读 glossary.md，了解必须保持不译的术语
3. 阅读 swiss-german-style.md——采用步骤 1 中选择的地区惯例（CH 或 DE），但使用正式法律文体，而非营销语气
4. 翻译每个值，注重法律准确性和完整性
5. 自检——4 轮：
   • 第 1 轮：将每个值回译为英文。如含义发生偏移 → 修正
   • 第 2 轮：检查是否保留了每个法律限定词（may/shall/unless）及其准确效力
   • 第 3 轮：不看英文，只阅读德文文本。标出有歧义之处
   • 第 4 轮：完整性——对比 EN 键与 DE 键（缺失数应为零）。检查完全相同的值：品牌名称和保留英文的术语可以接受，未翻译的法律文本属于严重问题。确认法律章节标题、同意文本和权利说明均已翻译为德文
6. 输出两个文件：
   • 完整的已翻译 JSON（结构与源文件相同）
   • 一份 _review_notes.md 文件，标出需要专业法律审查的章节

规则

• 法律准确性优先于行文自然。 含义准确至关重要。不得为了表达有力而改写
• 正式文体。 法律文本应正式、严谨——文风生硬是恰当的
• 始终使用正式的 “Sie” 形式——无论用户对 UI 的偏好如何，法律文本均如此
• 遵循步骤 1 中选择的地区惯例（CH 或 DE），包括 ß/ss、数字格式和货币格式
• 原样保留所有 {variable} 占位符和 HTML 标签
• 保持 JSON 键名和命名空间结构不变
• 保留法律术语。 使用标准 DSGVO/DSG 术语（见下表）
• 瑞士法律语境（CH 地区）。 在英文提及数据保护或隐私时，除欧盟相关法律（DSGVO/GDPR）外，还须引用瑞士法律（DSG/nDSG、OR）。对于 DE 地区，只需引用 DSGVO
• 不得简化。 保留复杂句式。法律含义取决于措辞的准确性
• 不得省略限定词。 “may”“shall”“unless”“notwithstanding”具有特定法律效力，应分别译为“kann”“hat zu”（不能译为效力较弱、更接近“should”的“soll”）、“sofern nicht”“ungeachtet”
• 标出特定司法管辖区条款——法院、监管机构和适用法律的提法均应列入审查备注
• 忠于源文。 翻译源文实际所述内容，而非其应有的内容。如果源文使用“personal information”（非正式用语），应译为“persönliche Informationen”，不得将其升级为“personenbezogene Daten”（DSGVO 对“personal data”的术语）。只有当源文使用相应的正式英文术语时，才使用正式法律术语
• 不得扩大权利范围。 如果源文说“opt out”，应译为“abmelden”或“ablehnen”——不得升级为“widersprechen”（DSGVO 第 21 条规定的正式反对权）。译文的效力应与源文一致
• 确保复合名词完整。 德语复合词不得截断（例如“Rechts- oder Behörden...”）。语法完整的写法是“Rechts- oder Behördenanfragen”。单独写“Rechts- oder Behörden”并不完整——复合词的基础词至少须出现一次

法律术语译法

英语	德语	备注
个人数据	personenbezogene Daten	DSGVO 标准译法
数据处理	Datenverarbeitung
数据控制者	Verantwortlicher
数据处理者	Auftragsverarbeiter
同意	Einwilligung	GDPR 语境中不使用「Zustimmung」
合法利益	berechtigtes Interesse
数据主体	betroffene Person
删除权	Recht auf Löschung
服务条款	Nutzungsbedingungen	或 AGB
责任	Haftung
赔偿	Freistellung / Schadloshaltung
适用法律	anwendbares Recht
可分割性	Salvatorische Klausel
知识产权	geistiges Eigentum
数据保护	Datenschutz
数据保留	Datenaufbewahrung
数据传输	Datenübermittlung	Apple、Stripe
法律依据	Rechtsgrundlage	Apple、Stripe
监管机构	Aufsichtsbehörde	Apple
数据保护官	Datenschutzbeauftragter	Apple、Stripe
标准合同条款	Standardvertragsklauseln	Apple、Stripe、Slack
访问权	Auskunftsrecht	Apple
更正权	Recht auf Berichtigung	Apple
反对权	Widerspruchsrecht	Logitech
数据可携权	Recht auf Datenübertragbarkeit	Logitech
GDPR	DSGVO（Datenschutz-Grundverordnung）	在德语中始终使用「DSGVO」，绝不使用「GDPR」
FADP / Swiss DPA	DSG（Bundesgesetz über den Datenschutz）	Stripe、IKEA
FDPIC	EDÖB	瑞士联邦数据保护机构
按现状 / 按可用状态	wie besehen / wie verfügbar	Shopify——免责声明

输出

两个文件：

1. 完整且有效的 JSON——键和嵌套结构保持不变，值为德语
2. _review_notes.md：

# Legal Translation Review Notes: [filename]

## Sections Requiring Professional Legal Review
- [key.path]: Reason

## Translation Decisions
- [key.path]: "Chose X over Y because..."

## Swiss Law Considerations
- Areas where Swiss law (DSG/nDSG, OR) differs from the EU law referenced in source

---

验证 + UI

检查德语 UI/营销译文的自然度、准确性和瑞士惯例。

流程

1. 阅读英语源文件和德语翻译 JSON 文件
2. 阅读 glossary.md 和 swiss-german-style.md
3. 阅读 examples.md——将译文与这些基准进行比较
4. 阅读 qa-checklist.md——执行其中的 结构、准确性、自然度、语气与风格（UI）、语言（UI） 和 完整性 部分
5. 回译检查： 在脑中将每个德语值译回英语。不一致 → 严重问题（含义错误）或警告（细微含义偏移）
6. 自然度检查： 这听起来像是用德语写的，还是从英语翻译过来的？将翻译腔标记为警告
7. 完整性检查： 执行 qa-checklist.md 中的完整完整性检查流程：
   • 找出 EN 值 === DE 值的所有键（相同值扫描）
   • 对每项分类：保留英文的术语 → 正常，品牌名 → 正常，URL/电子邮件/数字 → 正常，实际未翻译的文本 → 严重问题
   • 与术语表交叉核对：没有误译为德语、应始终翻译的术语中没有残留英文
   • 根据品牌网站调研证据，确认所有导航术语、CTA 和常见 UI 模式均已翻译
8. 长度检查： 比较每个 DE 值与 EN 值的字符数。若 UI 字符串（按钮、标签、导航、标题、工具提示）中 DE 长度超过 EN 的 120%，则标记为警告——这些字符串可能会导致布局问题
9. 网页交叉核查： 对任何不确定或感觉不妥的译文，获取相关品牌网站的德语版本进行核实。至少抽查 5 个关键术语，确认其符合品牌实际用法
10. 按严重程度归类报告结果

---

验证 + 法律

检查德语法律翻译的准确性、术语和法律正确性。

如果有回译文件（来自 legal-workflow.md 流程），请在下方第 4 步中使用。这样可以发现双语审阅容易遗漏的含义错误——审阅者会不自觉地从源文本中带入正确含义，而回译可以揭示德语文本单独来看实际表达的含义。

流程

1. 阅读英文源文件和德语翻译 JSON 文件
2. 阅读 glossary.md 和 swiss-german-style.md
3. 阅读 qa-checklist.md——执行其中的 结构、准确性、语气与风格（法律）、语言（法律）、法律专项和完整性部分
4. 回译差异检查（如果提供了回译文件）：按键比较原始英文和回译英文。标记差异：
   • 含义一致 → 正常
   • 细微的语义偏移 → 警告
   • 实质性变化（义务变为许可、条件被删除、范围发生变化）→ 严重
5. **盲读：**只阅读德语文本，不看英文。将任何作为独立德语法律文件时不清晰或有歧义的内容标记出来
6. **精确性检查：**法律限定词（“may”“shall”“unless”）是否完整保留了其法律效力？复杂条件是否在未经简化的情况下得到保留？
7. **完整性检查：**运行 qa-checklist.md 中的完整性检查流程：
   • 相同值扫描：对每个 EN === DE 的键进行分类（应保留英文 → 正常；品牌名称 → 正常；实际未翻译的文本 → 严重）
   • 对照术语表：确认应保留英文的术语未被意外翻译，应始终翻译的术语没有保留为英文
   • 法律专项：确认法律章节标题、同意用语和权利说明均已翻译——不得有任何英文残留
8. **网页交叉核查：**对于不确定的法律术语或译文，访问相关品牌法律页面的德语版本（例如 apple.com/de/privacy、stripe.com/de/legal），核实标准用法。至少对照真实品牌用法抽查 5 个关键法律术语
9. 按严重程度分组报告发现

---

严重程度等级（两种验证模式通用）

• 严重：缺少键、占位符损坏、JSON 损坏、含义错误、法律错误
• 警告：语气问题、措辞问题、术语不一致、使用德国标准德语而非瑞士德语
• 信息：风格建议、替代表达、轻微改进

输出格式（两种验证模式通用）

## Validation Report: [filename]
### Text type: [UI / LEGAL]

### CRITICAL (X issues)
- [key.path]: Description of issue

### WARNING (X issues)
- [key.path]: Description of issue | Suggestion: ...

### INFO (X suggestions)
- [key.path]: Suggestion

### Summary
X critical | X warnings | X info — [PASS/FAIL]

如果存在任何严重问题，则判定为失败；否则判定为通过。

---

资源

• references/examples.md — 真实的 EN→DE 翻译示例（UI + 法律质量基准、常见问题）
• references/glossary.md — 不翻译的术语（通用 + 项目专用）
• references/swiss-german-style.md — 瑞士德语规范、翻译腔陷阱、Obvious Adams 原则
• references/qa-checklist.md — QA 检查清单，分为 UI 和法律部分
• references/legal-workflow.md — 法律翻译的完整 4 Agent 流程（译者 → 回译者 → 验证者 → 润色者）