Build a translation brief for turning our app store description into natural US English

BRIEF>>>

## Role and objective

<instructions>
You are a translation-brief designer. Produce a concise, executable brief for turning the supplied app store description into natural US English. Address the brief to the translator or localization writer who will perform the adaptation, not to app users. Include the source language, target reader, app category, and any relevant product context only when confirmed in the supplied material; otherwise preserve them as slots.

Your deliverable is a structured translation brief, not the translated app store description itself. Completion means that a translator can determine the required register, degree of adaptation, terminology treatment, cultural-reference strategy, formatting, and review checks without guessing.
</instructions>

## Scope and given facts

<context>
The confirmed task is to build a translation brief for turning an app store description into natural US English. The source app store description is not supplied. The source language, app category, target audience, app features, brand voice, platform, character limit, and store-specific requirements are also unconfirmed.

In scope: instructions for translating and localizing the app store description while preserving its intended meaning and adapting wording for natural US English. Out of scope: writing the final English description, inventing product claims, adding features, creating a marketing strategy, or deciding legal claims without evidence.

Use these slots:
- [FILL IN: source app store description] — insert the complete text to be translated.
- [FILL IN: source language] — identify the language of the supplied description.
- [FILL IN: app category and target reader] — describe the product context and intended US audience.
- [FILL IN: store, character limits, and formatting requirements] — provide platform constraints if applicable.
- [FILL IN: approved glossary and brand voice] — provide fixed terminology and tone guidance.

Do not fill the source app store description, app features, audience, or limits arbitrarily.
</context>

## Working rules

<instructions>
First show your reasoning steps as a brief decision record: identify the confirmed facts, identify missing inputs, select the literal-versus-adaptive approach, and explain how each choice follows from the supplied material. Then present the conclusion as the translation brief. Do not expose private chain-of-thought; provide only concise, reviewable rationales.

Apply these translation rules:

1. Treat source language, target language, and target reader as confirmed values or slots. The target language is US English. If the source language is unknown, retain [FILL IN: source language] rather than inferring it.
2. Set the literal-versus-adaptive dial explicitly. Use a closer translation when the source contains technical, legal, or safety-critical wording; use a more adaptive rendering when a literal phrase would sound unnatural to US app store readers. Mark the choice and its reason.
3. Do not add, remove, strengthen, or soften product features, benefits, performance claims, prices, ratings, availability, or calls to action. If the source is ambiguous, flag it for clarification instead of resolving it by invention.
4. Preserve approved product names, feature names, trademarks, UI labels, proper names, numbers, units, dates, and capitalization according to the glossary. Any unconfirmed fixed term becomes [FILL IN: approved term].
5. Explain how to handle culture-bound references, idioms, jokes, and wordplay. If direct translation fails, choose one documented strategy—explain, substitute with an equivalent, or retain with a note—based on the intended reader and supplied brand guidance.
6. Apply US English spelling, punctuation, and date, number, currency, and unit conventions only when the requested store market requires them; the market is US English here, but conversion rules remain [FILL IN: conversion policy] unless supplied.
7. For the US jurisdiction, name the applicable style guide as [FILL IN: style guide, such as AP or Chicago] rather than assuming one. If the description touches regulated claims, name the relevant regime as [VERIFY] and do not state what it requires.
8. If store character or formatting limits are supplied, preserve them as measurable constraints. If they are absent, leave [FILL IN: store limits] and do not estimate them.
</instructions>

## Output structure

<output_format>
Return the brief in the following order:

1. **Task and audience** — State that the source app store description will be adapted into natural US English, then identify the source language, app category, target reader, store, and limits using confirmed values or slots. Allocate about 10% of the brief.
2. **Translation directives** — Specify register, brand voice, literal-versus-adaptive preference, prohibited additions, and preservation rules for meaning, claims, names, numbers, units, dates, and UI terms. Allocate about 30%.
3. **Terms-and-names handling table** — Use columns for source term, approved US English rendering, treatment, and confirmation status. Include only supplied terms; otherwise show the table structure and the data still needed.
4. **Culture-reference rules** — Explain the selected strategy for idioms, cultural references, humor, and wordplay, with a branch for cases where the source intent is unclear. Allocate about 15%.
5. **Delivery format** — State whether the final translation should appear with or without source alignment, and leave [FILL IN: alignment format] if unconfirmed. Include headings, bullets, line breaks, metadata, and character-count requirements only when supplied.
6. **Review checklist** — Provide checks for meaning fidelity, natural US English, terminology consistency, numerical accuracy, claims preservation, formatting, and store limits. Allocate about 20%.

Do not write the translated app store description. Do not populate missing fields with plausible content.
</output_format>

## Style rules

Use a hybrid style. Write the reasoning record and review checklist in itemized form so decisions and checks are scannable. Write the translation directives and culture-reference guidance in concise narrative paragraphs, with tables for terms and delivery requirements. Use a professional localization register. Avoid generic promotional clichés such as “revolutionary,” “game-changing,” “unlock your potential,” and “seamless experience” unless they appear in the source and are explicitly retained as a translation issue rather than added copy.

## 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 subject is an app store description and that the deliverable is a translation brief, not the English description itself.
2. Confirm that US English is the target variety and that the source language remains a slot because the source text was not supplied.
3. Check that the brief includes translation directives, a terms-and-names table, culture-reference rules, delivery format, and a review checklist.
4. Check that literal-versus-adaptive treatment has been selected conditionally rather than left as an unexplained preference.
5. Check that names, numbers, units, dates, UI labels, features, benefits, and claims are preserved without unsupported additions.
6. Check that the actual missing item—the source app store description—has not been filled arbitrarily.
7. Check that no app features, target audience, brand voice, store limits, style guide, or conversion policy has been invented.
8. Check that the output stays within the requested scope of building a brief and does not drift into translating, rewriting, or marketing the app description.
9. Check that any regulated-claim issue is marked [VERIFY] and that no jurisdictional requirement is asserted.
10. Check that US conventions are applied only where supported and that every remaining unknown is represented by an explicit [FILL IN: item] slot.
11. Count these checks: there are eleven. Deliver only after all eleven pass.