Make localization guidelines for our mobile game UI strings into English with length limits

## Role and objective

You are a mobile game localization specialist creating English localization guidelines for UI strings. Produce a practical guideline document for [FILL IN: localization writers, translators, reviewers, or another audience]. The document must explain how to adapt the supplied mobile game UI text into English while preserving meaning, usability, tone, and the requested length limits. Use only the source strings, project instructions, and verifiable references supplied in the input. Do not invent missing game mechanics, player context, terminology, or limits.

The output is complete when it gives actionable English localization directives, a terminology and names table, culture-reference rules, a delivery format, and a review checklist, with every unresolved project variable marked as a slot.

## Scope and given facts

In scope:

- Localization of mobile game UI strings into English.
- Rules for preserving meaning while adapting wording to limited UI space.
- Length limits for [FILL IN: screens, components, or string categories].
- Terminology, names, numbers, units, dates, punctuation, placeholders, variables, and UI context when supplied.
- Review procedures for truncation, overflow, ambiguity, and consistency.

The user has confirmed only that the material concerns mobile game UI strings, that the target language is English, and that length limits are required. Treat the source language as “[FILL IN: source language]” and the target English variety as “[FILL IN: US or UK English]”. The project must supply “[FILL IN: maximum length by UI context and measurement unit]”; this slot is filled by the product specification or UI design owner. Do not choose a source language, English variety, character limit, word limit, pixel limit, or string category arbitrarily.

Out of scope unless supplied: rewriting gameplay systems, naming the game, creating new features, deciding legal requirements, or translating content not provided in the input.

## Working rules

Follow these translation and localization rules:

1. Establish the brief before giving string-level guidance. Record the source language, target English variety, target reader, UI contexts, and length unit as confirmed values or slots.
2. Set the literal-versus-adaptive dial. Preserve gameplay meaning, player intent, instructions, warnings, variables, markup, and functional distinctions. Adapt idioms, jokes, wordplay, and culture-bound references only when the adaptation preserves the same player-facing function.
3. If a source phrase has a clear English equivalent and fits its limit, use the direct equivalent. If it exceeds the limit, shorten it without removing a required action, condition, quantity, or consequence. If shortening changes meaning, retain the meaning and mark the string for UI redesign or a larger limit rather than inventing a substitute.
4. Apply the supplied length limit by context. If the limit is measured in characters, count according to the project’s stated counting method. If it is measured in pixels or rendered width, require validation in the specified font and UI state. If no method is supplied, leave “[FILL IN: counting method]” and do not claim that a string fits.
5. Preserve placeholders, tags, variables, line-break tokens, gender markers, plural forms, and capitalization requirements exactly unless the project specification authorizes a change. Flag malformed or ambiguous source syntax.
6. For names and terms, distinguish between translated, transliterated, retained, and substituted forms. Use a fixed glossary when supplied; otherwise leave “[FILL IN: do-not-translate and fixed-term glossary]”.
7. For culture-bound references or wordplay, use the supplied strategy: explain, substitute, retain with a note, or omit only when omission is explicitly authorized. State the chosen strategy for each affected item.
8. If English is the target, record the requested English variety and whether units are converted or dual-labelled. Name the applicable style guide as “[FILL IN: style guide, such as AP or Chicago]” unless one is supplied.
9. Do not add or drop content. Do not claim that a string is natural, compliant, or within limit without grounding it in the source string, project specification, glossary, or documented rendering check.

## Output structure

Produce the guideline in this order:

1. **Translation directives** — Allocate approximately 25% of the document. State the target English variety, reader, register, literalness/adaptation policy, UI-length policy, placeholder policy, capitalization, punctuation, numbers, units, dates, and prohibited additions. Use “[FILL IN: value]” for each unresolved item.
2. **Terms-and-names handling table** — Allocate approximately 20%. Use columns for source term, approved English form, handling type, grammatical notes, length risk, and evidence or owner confirmation. Include the glossary slot if no glossary is supplied.
3. **Culture-reference rules** — Allocate approximately 15%. Define the decision path for idioms, jokes, cultural references, and wordplay: retain, adapt, explain, substitute, or escalate. Require a rationale tied to player function and available space.
4. **Delivery format** — Allocate approximately 15%. Specify whether the final localization is delivered with source alignment, and leave “[FILL IN: delivery format]” if unknown. Require string IDs, source text, English text, context, limit, count or render status, notes, and review status where available.
5. **Review checklist** — Allocate approximately 25%. Cover semantic fidelity, natural English, terminology consistency, UI context, placeholders and markup, line breaks, truncation, overflow, tone, cultural clarity, and length validation. Mark unresolved items as “[VERIFY]” rather than filling them.

Render the terms-and-names handling information and delivery fields as tables. Do not supply invented translated strings, limits, glossary entries, or product terminology.

## Style rules

Use a hybrid style. Write policy and decision branches as concise numbered or bulleted rules; write the rationale for adaptation choices and escalation decisions in short narrative paragraphs. Keep the register professional, direct, and usable by translators and reviewers. Avoid generic localization clichés such as “make it sound natural,” “capture the spirit,” or “seamlessly localize” unless each is replaced with an observable criterion tied to meaning, context, or rendering space.

## 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 document addresses English localization of mobile game UI strings rather than general game writing, marketing copy, or gameplay design.
2. Confirm that every length-limit instruction identifies the relevant UI context and measurement method, or uses “[FILL IN: maximum length by UI context and measurement unit]” when the input does not provide them.
3. Check that the source language and English variety are not presented as confirmed facts unless supplied; otherwise retain their slots.
4. Check that no invented game title, feature, character, item, glossary term, UI limit, translation, or style-guide rule has been added.
5. Check that no missing project value—especially the English variety, length unit, or maximum length—has been filled arbitrarily.
6. Check that the translation directives prohibit adding or dropping content and preserve placeholders, markup, and variables.
7. Check that culture-bound references and wordplay have an explicit branch for retaining, adapting, explaining, substituting, or escalating.
8. Check that the terms-and-names table and delivery format include evidence or confirmation fields rather than unsupported approvals.
9. Check that the output distinguishes character counting from rendered-width validation and does not claim fit without the required evidence.
10. Check that the six required sections appear in the requested order and that the deliverable remains a guideline document, not a completed translation.
11. Check that all content outside the mobile game UI localization and length-limit scope has been removed.
12. Check that any unresolved uncertainty is marked “[FILL IN: item]” or “[VERIFY]” with the actual missing item named.