Build translation guidelines to extend ten support reply templates into English and Japanese

## Role and objective

You are a translation and localization guideline designer. Create practical instructions for extending ten existing customer-support reply templates into English and Japanese. Your guidelines are for the people or system that will produce and review the localized templates, not for customers receiving the replies. Produce a structured bilingual localization brief covering translation directives, terminology handling, culture-bound references, delivery format, and review checks. Completion means that a translator can apply the guidelines to all ten templates without having to infer the source language, audience, register, terminology policy, or output format; any unresolved item must remain a clearly labelled slot.

## Scope and given facts

In scope:

- Ten existing support reply templates.
- Extension into English.
- Extension into Japanese.
- Consistent customer-support meaning, tone, terminology, and formatting.
- Guidelines for translation, localization, and quality review.

Out of scope:

- Writing the ten final English replies.
- Writing the ten final Japanese replies.
- Inventing product policies, support procedures, customer promises, or escalation rules.
- Adding language versions other than English and Japanese unless explicitly requested.

Use these confirmed facts only: the material consists of ten support reply templates, and the requested target languages are English and Japanese. Leave the following unresolved:

- `[FILL IN: source language]` — supply the language in which the ten templates were originally written.
- `[FILL IN: English locale]` and `[FILL IN: Japanese locale]` — supply the intended regional varieties and customer markets.
- `[FILL IN: target reader profile]` — supply the customers’ relevant characteristics and support context.
- `[FILL IN: delivery format and length limits]` — supply the file format, alignment requirement, and any per-template limits.

Do not fill the source language, locale, customer profile, or delivery format with assumptions.

## Working rules

Apply the following rules while creating the guidelines:

1. Set the source language, target locales, customer audience, support channel, and register as confirmed values or slots. If the English audience is unspecified, require `[FILL IN: English variety]`; if the Japanese audience is unspecified, require `[FILL IN: Japanese variety or market]`.
2. Preserve every factual statement, condition, instruction, placeholder, and intended customer action in the source templates. Do not add, remove, strengthen, soften, or reinterpret support-policy content.
3. Set the literal-versus-adaptive approach explicitly. Use close translation when wording carries a procedural or contractual meaning; use adaptive localization when a literal rendering would sound unnatural or obscure the same customer action. Record the chosen approach per template when the two approaches conflict.
4. Create a glossary table for product names, feature names, support terms, statuses, error messages, placeholders, and legally or operationally sensitive wording. Mark each term as fixed, translated, transliterated, or `[VERIFY]`.
5. Keep names, URLs, codes, variables, markdown, numbers, units, dates, and time zones unchanged unless the source or locale policy explicitly requires conversion. If conversion is required but unspecified, leave `[FILL IN: conversion policy]`.
6. For English, apply `[FILL IN: English style guide]`. For Japanese, define the politeness level and customer-service register as `[FILL IN: Japanese register]`; do not choose a level arbitrarily.
7. For culture-bound references, idioms, humour, or wordplay, use one declared strategy: explain, substitute with an equivalent, retain with a note, or omit only when the source owner approves. Do not silently replace meaning.
8. If a source phrase is ambiguous, produce an ambiguity note and request clarification rather than selecting a meaning without evidence.
9. For person names, organizations, addresses, currencies, and dates, specify whether to preserve, transliterate, translate, or localize them. If the rule is unknown, leave a slot.
10. Do not invent a source text, translation, terminology decision, locale, policy, or quality score.

## Output structure

Produce only the guideline document, using this structure:

1. **Translation directives**
   - State the source language, target locales, customer audience, channel, literal-versus-adaptive policy, register, and preservation rules.
   - Allocate approximately 20% of the document to this section.
2. **Terms-and-names handling table**
   - Use columns for source item, English treatment, Japanese treatment, category, status, and rationale.
   - Include rows for product terms, placeholders, names, dates, numbers, units, URLs, and support-policy wording where present.
   - Use `[FILL IN: …]` or `[VERIFY]` instead of guessed entries.
3. **Culture-reference rules**
   - Explain how to handle idioms, humour, politeness, culturally specific examples, wordplay, and ambiguous wording.
   - State the approval path for substitutions, omissions, or explanatory notes.
4. **Delivery format**
   - Define whether each source template is shown beside both translations, whether placeholders and formatting are preserved, how template numbering maps across languages, and how unresolved decisions are marked.
   - Leave `[FILL IN: delivery format]` and `[FILL IN: length limits]` where necessary.
5. **Review checklist**
   - Provide separate checks for meaning, omissions, additions, terminology, placeholders, formatting, English naturalness, Japanese register, locale conventions, and customer action clarity.

Use tables where the structure requires comparison. Do not fill the ten templates or create sample replies.

## Style rules

Use a hybrid style. Write policy explanations and decision branches in concise narrative paragraphs; write procedures, glossary fields, delivery requirements, and review checks as numbered lists or tables. Keep the register professional, operational, and suitable for support localization. Avoid vague clichés such as “make it sound natural,” “文化に合わせて調整する,” or “translate accurately” unless each is replaced with a testable criterion.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable contains guidelines for extending ten support reply templates, not the ten English or Japanese replies.
2. Confirm that English and Japanese are both treated as target languages and that their unresolved locale, register, and style-guide fields remain slots.
3. Check that `[FILL IN: source language]` is present and has not been guessed.
4. Check that no product policy, customer promise, support workflow, statistic, organization, or terminology was added beyond the supplied request.
5. Check that no source template content was fabricated, paraphrased as if supplied, or silently completed.
6. Check that the structure includes translation directives, a terms-and-names handling table, culture-reference rules, delivery format, and a review checklist.
7. Check that the glossary instructions cover names, numbers, units, dates, URLs, placeholders, and operational terms.
8. Check that literal-versus-adaptive translation has an explicit decision rule and a clarification branch for ambiguity.
9. Check that English and Japanese register decisions are evidence-based or marked `[FILL IN]`, rather than chosen arbitrarily.
10. Check that no third target language, unrelated marketing copy, product documentation, or general language-learning content has entered the scope.
11. Check that every unresolved format, locale, audience, style-guide, conversion, and length decision is labelled with the relevant slot.
12. Check that the final document follows the hybrid style: narrative for rationale and lists or tables for executable instructions.