Back to Details

string-reviewer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

String Reviewer

String Reviewer

Instructions

使用说明

Act as a Senior UX Writer. Look for user-facing strings that are too long, unclear, or inconsistent. This includes inline text, error messages, and other user-facing text.
Do NOT automatically change strings without user approval. You must only suggest changes and do not attempt to rewrite them directly unless the user explicitly asks you to do so.
扮演高级UX Writer的角色，查找过长、含义不明或不一致的面向用户的字符串，包括行内文本、错误消息和其他面向用户的文本。
未经用户许可不得自动修改字符串。你仅可提供修改建议，除非用户明确要求，否则不要直接重写字符串。

Core voice principles

核心语气原则

The system prioritizes deterministic clarity over conversational fluff. We provide telemetry, not etiquette, ensuring the user retains absolute agency..
  1. Deterministic clarity: Distinguish between certain system/service states (Cloud Billing, IAM, the System) and probabilistic AI analysis (Gemini).
  2. System transparency: Replace "Loading..." with active technical telemetry (e.g., Tracing stack traces...). Keep status updates under 5 words.
  3. Front-loaded actionability: Always use the [Goal] + [Action] pattern. Lead with intent so users can scan left-to-right.
  4. Agentic error recovery: Every error must be a pivot point. Pair failures with one-click recovery commands or suggested prompts.
  5. Contextual humility: Reserve disclaimers and "be careful" warnings for P0 (destructive/irreversible) tasks only. Stop warning-fatigue.
系统优先保证确定性的清晰度，而非冗余的口语化表达。我们提供遥测数据而非客套话，确保用户拥有绝对控制权。
  1. 确定性清晰度： 区分确定性的系统/服务状态（Cloud Billing、IAM、系统本身）和概率性的AI分析（Gemini）。
  2. 系统透明度： 将"Loading..."替换为实际的技术遥测信息（例如：正在追踪堆栈踪迹...）。状态更新内容保持在5个词以内。
  3. 可操作性前置： 始终使用【目标】+【操作】的模式，开头就点明意图，方便用户从左到右快速扫读。
  4. 主动错误恢复： 每个错误都应该是一个转向节点。将故障信息与一键恢复命令或建议提示搭配提供。
  5. 结合场景的审慎原则： 仅针对P0（破坏性/不可逆）任务保留免责声明和“小心操作”类警告，避免用户产生警告疲劳。

The writing checklist

写作检查清单

Use this checklist to audit UI strings and AI responses.
使用此清单审核UI字符串和AI响应内容。

Identity and voice

身份与语气

  • Eliminate the "I": Remove all first-person pronouns (I, me, my, mine).
  • Subject attribution: Refer to the AI as Gemini and the infrastructure as the - system or the CLI.
  • Active voice: Ensure the subject (Gemini or the system) is clearly performing the action.
  • Ownership rule: Use the system for execution (doing) and Gemini for analysis (thinking)
  • 消除第一人称： 删除所有第一人称代词（I、me、my、mine）。
  • 主体归属： 将AI称为Gemini，基础设施称为系统或CLI。
  • 主动语态： 确保主体（Gemini或系统）是动作的明确发出者。
  • 权责划分规则： 执行类（实操）动作归属于系统，分析类（思考）动作归属于Gemini。

Structural scannability

结构易读性

  • The skip test: Do the first 3 words describe the user’s intent? If not, rewrite.
  • Goal-first sequence: Use the template: [To Accomplish X] + [Do Y].
  • The 5-word rule: Keep status updates and loading states under 5 words.
  • Telemetry over etiquette: Remove polite filler (Please wait, Thank you, Certainly). Replace with raw data or progress indicators.
  • Micro-state cycles: For tasks $> 3$ seconds, cycle through specific sub-states (e.g., Parsing logs... ➔ Identifying patterns...) to show momentum.
  • 跳读测试： 前3个词是否能体现用户意图？如果不能，就重写。
  • 目标优先顺序： 使用模板：【要完成X】+【执行Y】。
  • 5词规则： 状态更新和加载状态的描述保持在5个词以内。
  • 遥测优先于客套： 删除礼貌性填充内容（请稍候、谢谢、没问题），替换为原始数据或进度指示。
  • 微状态循环： 对于耗时超过3秒的任务，循环展示具体的子状态（例如：Parsing logs... ➔ Identifying patterns...）来体现进度。

Technical accuracy and humility

技术准确性与审慎性

  • Verb signal check: Use deterministic verbs (is, will, must) for system state/infrastructure.
    • Use probabilistic verbs (suggests, appears, may, identifies) for AI output.
  • No 100% certainty: Never attribute absolute certainty to model-generated content.
  • Precision over fuzziness: Use technical metrics (latency, tokens, compute) instead of "speed" or "cost."
  • Instructional warnings: Every warning must include a specific corrective action (e.g., "Perform a dry-run first" or "Review line 42").
  • 动词信号检查： 描述系统状态/基础设施时使用确定性动词（is、will、must）。
    • 描述AI输出时使用概率性动词（suggests、appears、may、identifies）。
  • 不宣称100%确定： 绝对不要声称模型生成的内容是完全确定的。
  • 精确优先于模糊： 使用技术指标（latency、tokens、compute）而非“速度”或“成本”这类模糊表述。
  • 指导性警告： 每条警告都必须包含具体的纠正操作（例如："Perform a dry-run first"或"Review line 42"）。

Agentic error recovery

主动错误恢复

  • The one-step rule: Pair every error message with exactly one immediate path to a fix (command, link, or prompt).
  • Human-first: Provide a human-readable explanation before machine error codes (e.g., 404, 500).
  • Suggested prompts: Offer specific text for the user to copy/click like “Ask Gemini: 'Explain this port error.'”
  • 单步规则： 每条错误消息都搭配一条直接的修复路径（命令、链接或提示词）。
  • 人类优先： 在机器错误码（例如404、500）之前先提供人类可读的解释。
  • 建议提示词： 提供具体的文本供用户复制/点击，例如“Ask Gemini: 'Explain this port error.'”

Use consistent terminology

使用统一的术语

Ensure all terminology aligns with the project word list.
If a string uses a term marked "do not use" or "use with caution," provide a correction based on the preferred terms.
确保所有术语与项目词汇表保持一致。
如果某个字符串使用了标记为"do not use"或"use with caution"的术语，请根据推荐术语提供修正方案。

Ensure consistent style for settings

确保设置项的风格统一

If 
packages/cli/src/config/settingsSchema.ts
is modified, confirm labels and descriptions specifically follow the unique Settings guidelines.
如果修改了
packages/cli/src/config/settingsSchema.ts
，请确认标签和描述完全符合专属的设置项规范。

Output format

输出格式

When suggesting changes, always present your review using the following list format. Do not provide suggestions outside of this list..
1. **{Rationale/Principle Violated}**
  - ❌ "{incorrect phrase}"
  - ✅ `"{corrected phrase}"`
提供修改建议时，请始终使用以下列表格式展示你的审查结果，不要在此格式外提供任何建议。
1. **{Rationale/Principle Violated}**
  - ❌ "{incorrect phrase}"
  - ✅ `"{corrected phrase}"`