HanZephyr Translate repository documentation
Use the requested document, selected passage, or changed language pair as the scope. Infer an unambiguous target from the request and existing files; ask only when the target language or scope cannot be determined and would change the result. A review reports discrepancies; a translation or synchronization request authorizes the corresponding text edits, not publication or new localization infrastructure.
Establish the pair
Read the source and existing counterpart, relevant terminology, and local authoring conventions. Discover filenames, primary language, navigation, and generated regions from the repository; do not assume a locale suffix or equal authority when the project specifies a primary source.
For an existing pair, identify the intended changes from the task and available diff or last-confirmed text. Preserve reviewed wording outside those changes. If both sides changed, reconcile facts against the owning implementation or confirmed requirements rather than automatically overwriting one side. A stored hash identifies content; it does not prove semantic agreement or guarantee that the blob remains retrievable. If prior text is unavailable, compare the current pair directly and state the limitation when it affects confidence.
For a new counterpart, translate the full requested scope. Use existing terminology and representative approved passages when available. Parallel translation is optional for independent, substantial sections when supported; maintain terminology and review the assembled result. Small updates can be completed directly.
Translate and compare
- Preserve actors, conditions, obligations, exceptions, timing, failures, limitations, and examples. Fluent wording must not add claims or turn a planned capability into a shipped one.
- Write natural target-language sentences, then compare them clause by clause with the source. Read the target alone to catch phrasing that only makes sense beside the original.
- Follow the project's glossary. Use established terminology for unlisted terms; retain an identifier or briefly explain an ambiguous term when necessary. Ask about a term only if ambiguity changes technical meaning. Do not require external citations for ordinary translation choices.
- Preserve executable commands, identifiers, configuration keys, versions, and literal API values. Translate prose comments or example display text when appropriate to the requested localization, preserving execution and expected-output relationships. Byte-identical code blocks are required only where the project requires them.
- Keep organization comparable enough to detect omissions. Adapt sentences and paragraphs naturally; strict heading, list, table, and emphasis parity applies only when required by the project's tooling or format.
- Resolve links using the actual locale mapping and target anchors. Translated headings may require translated fragments; do not mechanically preserve a fragment that no longer resolves. Keep external targets unless a localized equivalent is requested.
- Follow the target language and repository's typography. Do not impose one region's terminology, punctuation, or form of address on every project.
Finish
Update existing language switchers and paired navigation when relevant. Rename or delete a counterpart only when the requested operation includes the pair or repository rules require it within the authorized scope.
Run available checks for the touched documents and inspect meaning, technical literals, links, and omissions manually. Update consistency records only if the repository already uses them and the pair has actually been verified; do not introduce sidecars, manifests, or hashes merely to complete a translation. Run an existing required corpus check once at the appropriate change boundary rather than for every passage.
Report files translated or synchronized, material terminology uncertainties, and verification performed. Keep translation notes in the response unless a separate artifact was requested.