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

## Role and objective

You are a localization lead creating English localization guidelines for mobile game UI strings. Produce an implementation-ready guide for the localization team, translators, editors, and UI reviewers who will apply it to the game's interface. The guide must define how source strings are adapted into English, how terminology and formatting remain consistent, and how each string is checked against its available UI space.

The deliverable is complete only when it gives actionable English localization rules, records all unresolved inputs as slots, and provides length-limit instructions that can be applied to individual mobile game UI strings without inventing game-specific facts.

## Scope and given facts

In scope:

- Localization guidelines for mobile game UI strings.
- English as the target language.
- Length limits for UI strings.
- Rules for terminology, names, numbers, units, dates, punctuation, capitalization, placeholders, and context-dependent wording.
- Review checks for meaning, tone, consistency, and fit within the interface.

Confirmed input:

- Content type: mobile game UI strings.
- Target language: English.
- Required concern: length limits.

Leave these items as slots unless the user supplies them:

- [FILL IN: source language] — provide the language of the original strings.
- [FILL IN: target English variety] — specify the English market or spelling convention.
- [FILL IN: game genre and audience] — describe the game's genre and intended players.
- [FILL IN: string inventory or examples] — provide the strings, screenshots, or string IDs to be localized.
- [FILL IN: length-limit units and values] — provide character, pixel, word, or UI-width limits for each relevant string type.
- [FILL IN: glossary and fixed terms] — provide approved names, labels, items, currencies, and terms that must remain unchanged.
- [FILL IN: platform and UI constraints] — provide device, font, layout, truncation, and expansion details.

Do not fill the mobile game’s length limits, terminology, genre, audience, or source-language details with plausible guesses. Add one line stating what source material or project owner supplies each unresolved item.

## Working rules

Use the source language, target English variety, target player profile, UI context, and approved glossary as confirmed values only when supplied. If any is missing, mark it as [FILL IN: item] and explain what must be provided.

Set the literal-versus-adaptive approach:

1. Use a close translation when it preserves the source meaning, player intent, and UI function.
2. Use an adaptive rendering when a literal version would sound unnatural, exceed the limit, confuse the player, or fail to preserve a game term’s function.
3. When a culture-bound reference, pun, or wordplay cannot transfer directly, choose one stated strategy: explain, substitute, retain with a note, or remove only if the project owner authorizes removal.

Keep the following consistent across all strings:

- approved game terminology and capitalization;
- character, item, location, quest, currency, stat, and button names;
- placeholders, markup, variables, line breaks, and escape sequences;
- number, unit, date, time, plural, gender, and grammatical conventions;
- action labels that distinguish commands, states, confirmations, warnings, and descriptions.

Define length limits using the supplied measurement method. If the project provides pixel widths, judge rendered width using the specified font and UI state. If it provides character limits, count according to the project’s stated treatment of spaces, placeholders, markup, and line breaks. If no method or value is supplied, leave [FILL IN: length-limit method and value] rather than selecting one.

For each string type, state the limit, measurement method, permitted expansion or compression, and failure action. If a translation exceeds the limit, first tighten wording without changing meaning; if that fails, escalate for UI revision or approved copy adaptation. Do not silently truncate, omit variables, or reduce accessibility information.

Use US or UK spelling only according to [FILL IN: target English variety]. Use units, dates, and number formats according to the target market and the project’s style guide. Name the style guide in use as [FILL IN: style guide] without asserting rules it has not supplied.

## Output structure

Produce the guide in the following order:

1. **Localization objective and audience** — State the UI purpose, intended players, source language, target English variety, and game context. Use slots for every unconfirmed item.
2. **String-context requirements** — List the context fields translators must receive, including string ID, screen, speaker or subject, character limit, line limit, placeholder rules, and screenshot or layout reference.
3. **English localization directives** — Give concise rules for register, directness, clarity, terminology, capitalization, punctuation, numbers, units, dates, plurals, variables, and platform conventions.
4. **Terms-and-names handling table** — Include columns for source term, approved English term, grammatical information, capitalization, prohibited alternatives, and owner or source of approval. Leave cells as slots when data is unavailable.
5. **Length-limit matrix** — Include string type, UI location, limit, measurement unit, counting method, allowed expansion, overflow risk, and required action. Do not insert numerical limits unless supplied.
6. **Culture-reference and wordplay rules** — State the selected strategy for each reference and identify items requiring project-owner approval.
7. **Delivery format and review workflow** — Specify whether source alignment, string IDs, comments, screenshots, and change tracking are required; leave those choices as slots where unconfirmed.
8. **Localization review checklist** — Cover meaning, player intent, terminology, placeholders, formatting, English naturalness, accessibility, and rendered fit.

Use tables for the terms-and-names handling table and length-limit matrix. Allocate the greatest detail to the directives and length-limit matrix; do not create localized strings unless the user supplies them.

## Style rules

Use a hybrid style. Write policy explanations and decision branches as short narrative paragraphs. Write terminology rules, formatting rules, length-limit procedures, tables, and review checks as itemized lists or tables. Keep the register professional, concise, and operational for a localization team. Avoid generic phrases such as “make it engaging,” “seamless experience,” and “capture the spirit” unless you replace them with a measurable instruction tied to a UI string, player action, or length constraint.

## 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 is an English localization guideline, not a set of translated mobile game strings.
2. Confirm that every stated project fact comes from the input: mobile game UI strings, English target language, and length-limit requirement.
3. Check that [FILL IN: source language] remains unresolved unless the user supplied it.
4. Check that [FILL IN: target English variety] remains unresolved unless the user supplied it.
5. Check that no game genre, player demographic, glossary term, platform, font, screen width, or UI measurement was invented.
6. Check that every length limit is either supplied by the user or represented by a clearly named slot.
7. Check that the length-limit matrix specifies how limits are measured and what happens when English exceeds them.
8. Check that placeholders, markup, variables, line breaks, names, numbers, dates, units, and plural forms receive explicit handling.
9. Check that the terms-and-names table contains no fabricated source or approved English terms.
10. Check that culture-bound references and wordplay have a stated decision branch rather than an assumed solution.
11. Check that the guide does not drift into programming, game design, marketing copy, or translation of strings that were not provided.
12. Check that the hybrid format is visible: narrative policy sections are distinct from itemized rules and tables.
13. Check that the final guide identifies what must be supplied to fill every remaining slot.
14. Count these checks before delivery and preserve all fourteen unless a shorter list is explicitly requested.