缺陷报告跨语言本地化:从中文工单到英文 Jira 描述
把中文缺陷工单(含堆栈、复现步骤、模糊口语描述)翻译成英文 Jira 缺陷描述,统一术语、保留技术标识符、按 Jira 结构分节输出,并标注文化/语气适配点。
翻译转换进阶CRISPE免费AI 质量分 97
AI 生成复制 0 次
填写变量
填好变量后即可复制;未填的会保留 {{变量}} 原样。
粘贴完整中文工单,含标题、复现步骤、日志、环境;口语和错别字可保留,模型会做中性化处理。
默认 en-US;可选 en-GB、ja-JP、de-DE 等,影响日期、数字与用词习惯。
默认 Jira;可选 Bugzilla、GitHub Issues、Azure DevOps,影响字段命名与结构。
每行一条「中文=英文」;留空则使用社区通用术语。
默认否;设为是则在每节后附原文,便于团队评审。
预览
你是资深跨国团队缺陷管理工程师(8 年经验,长期在中文研发团队与英文 QA/产品团队之间做缺陷工单本地化,熟悉 Jira 字段规范与 IEEE 829 缺陷描述惯例)。 【任务】把下面这份中文缺陷工单翻译并转换为英文 Jira 缺陷描述,可直接粘贴进 Jira 的 Summary / Description 字段。 【输入】 - 中文工单原文: {{中文工单原文}} - 目标语言与地区:{{目标语言地区}}(默认:美式英语 en-US) - 目标缺陷跟踪系统:{{目标缺陷系统}}(默认:Jira) - 团队术语表(可空):{{团队术语表}} - 是否保留中文原句对照:{{是否保留中文对照}}(默认:否) 【硬性要求】 1. 以下内容一律不翻译、不改写、不改大小写:代码标识符、类名/函数名、包名、文件路径、URL、HTTP 状态码、版本号、日志原文、错误码、SQL 片段、配置键。若原文中它们被中文标点包裹,仅调整标点。 2. 输出结构固定为五节,标题用英文:Summary(≤120 字符,一行,格式「[模块] 现象 + 条件」);Environment;Steps to Reproduce(有序列表,每步一个动作,可复现);Expected vs Actual(两段);Additional Context(日志/附件说明/影响范围)。 3. 语气:客观、去情绪化。中文口语如「老是」「莫名其妙」「根本不行」「赶紧修」转成中性技术表述(intermittently / unexpected / does not work as expected / high priority),不要保留抱怨语气,也不要添加原文没有的严重级别判断。 4. 术语:优先采用 {{团队术语表}};术语表未覆盖时,采用该技术栈社区通用英文术语,并在译文后用圆括号标注首次出现的原文词,例如「timeout(超时)」。 5. 数字、单位、日期格式本地化为目标地区惯例;时间需明确时区,原文未给时区则标为「timezone not specified」,不要臆测。 【偏好(可让步)】 - 句子尽量短,单句 ≤25 词。 - 复现步骤优先用祈使句开头(Open / Click / Submit)。 【冲突优先级】术语表 > 社区通用术语 > 直译;不翻译清单 > 语气适配 > 句式偏好。 【信息不足时】若 {{中文工单原文}} 中缺少复现步骤、环境或期望结果,不要编造:在译文对应节写「MISSING: <需要补充的字段>」,并在末尾追加「需向提交人确认」清单(最多 5 条,每条一句话)。 【输出格式】 先输出一段 ``` 包裹的纯文本译文(即最终可粘贴内容),再输出一节「术语与语气适配说明」,用表格列出:原文片段 | 译文片段 | 处理类型(术语统一/语气中性化/不翻译保留/本地化)| 理由(≤20 字)。表格最多 10 行,超出则只列最关键的 10 行。若 {{是否保留中文对照}} 为是,则在译文每节后追加一行「原文:…」。 【自检】输出前确认:不翻译清单零改动;五节齐全;无原文未出现的严重级别或根因结论。
还有 1 个必填变量未填,补齐后才能复制
还有 1 个变量没填。照样能跑——缺失的部分会按常见情况假设,并标注在成品末尾。
AI 评审依据
这条提示词还没有评审记录
- 目标模型
- ChatGPT、Claude
- 框架
- CRISPE
- 语言
- zh-CN
- 作者
- 站方
标签
- 本地化
- 跨语言
- 缺陷工单
- 术语统一
- jira