Localization Guide: Language Support & Setup

Localization controls how in-game names and descriptions are presented to players in different languages; it ensures text fits UI constraints and preserves tone, clarity, and consistency across translations.

Goals and scope

• Convey each entity’s intended meaning and role (function, flavor, or lore) rather than perform literal word-for-word translation.
• Preserve proper nouns, item/building names, and technical terms verbatim as they appear in the game (do not translate or alter them).
• Keep descriptions concise to fit UI elements while retaining distinctive tone where present (e.g., dry humor, clinical tone, or flavor text).

Handling of different text types

• Names: Keep exact in-game names (e.g., GATE, G.A.S.S., Automate de Claustration Automatisée du GATE) and avoid adding or removing punctuation. If a name contains an acronym, retain the acronym form used in the source.
• Short descriptions (one-liners): Translate meaning and tone faithfully while ensuring they remain short and readable. Prefer natural target-language phrasing over literal structure.
• Longer descriptions / lore: Preserve important lore facts and relationships (who developed something, prototypes, testing status) and include only what fits the intended UI space.
• Flavor text (food descriptions, item quips): Maintain the intended flavor (appetizing, burned, humorous, bland) succinctly. If multiple languages present slightly different adjectives, choose the clearest single rendering in the target language.

Consistency rules

• Proper nouns and titles: Leave scientific or project names intact. Example: “GATE” and “G.A.S.S.” remain unchanged across locales.
• People’s names: Always retain original spelling (e.g., Dr Alice Mayfield, Dr Stewart Wakeman).
• Tone matching: Match the register of the original locale. If source is clinical, keep clinical phrasing; if whimsical, keep playful phrasing.
• Repetition: If multiple source locales provide the same fact, state it once in localization text.

Special cases and examples

• Robots and security units

  • GATE defense and containment units: Describe the unit as an enhanced security automaton derived from earlier designs by Dr Alice Mayfield, with protocols added by Dr Stewart Wakeman. Note testing/field-evaluation status and any notable quirks present in the source text. For example:
    • Defense Bot (GATE automatic defense droid): an upgraded combat prototype based on the original G.A.S.S., currently field-tested and exhibiting identification errors between friend and foe; retains a known failure mode where severe damage can detonate the rear power module.
    • Containment Bot (GATE automated containment automaton): built on the same security-bot architecture with added containment protocols; under field evaluation at Cascade Research Facility.
  • Localizers must include the development attribution (Mayfield, Wakeman) because it is lore-relevant.

• Deployable markers

  • Deployable Beacon: short, literal descriptor such as “A placeable, nameable positional marker that bypasses conventional occlusion.” Keep wording tight and unambiguous.

• Food items and consumables

  • Burned / spoiled variants: Use a consistent adjective for “burned” (e.g., “burnt” or “burned”) across items in a locale and maintain the food’s base name. Examples:
    • Burnt Apple Pie — “Burnt apple pie.”
    • Burnt Carrot Cake — “A burnt carrot cake.”
    • Burnt Buttery Popcorn — “A bucket of burnt popcorn.”
  • Subtle flavors and descriptors: Keep descriptions compact but descriptive (e.g., “Creamy corn soup — a comforting corn-based soup”; “Carrot Pumpkin Soup — a slightly sweet vegetable soup made from Carrot and pumpkin”).
  • When the source indicates poor quality or texture (e.g., “hard and dry”, “overcooked”, “charcoal-like”), include that single clear descriptor rather than embellishing.

• Miscellaneous items

  • Office furniture and props: Short descriptive phrases are sufficient: “Cubicle — full-size paintable office cubicle”; “Cafeteria Table — once suitable for lunches before a string of events.”
  • Apparel/armor: Keep material and purpose: “A.E.G.I.S. Pauldrons — carbon-reinforced hand protection” (or “arm protection” depending on the item’s slot).
  • Toys/seasonal content: Preserve tone: “Christmas Express — steam and joy power this engine.”

Formatting and length constraints

• Target one short sentence for UI description lines when possible; two sentences only if necessary to include critical lore or mechanical warnings.
• Avoid parenthetical asides unless they are part of the canonical name or necessary for clarity (e.g., abbreviations).
• Do not include meta-information (translation notes, source language tags) in the localized text.

QA checklist for localizers

• Did you keep proper nouns exactly as in the game?
• Is the text concise (preferably ≤ one UI line)?
• Does the text preserve original tone (clinical, whimsical, dry)?
• Are critical facts and failure modes retained when present (prototype status, field testing, known defects)?
• Are adjectives for common conditions (burnt/overcooked/bland) consistent across similar items?

Maintaining multilingual parity

• If a concept appears only in one language source, include it in other locales with equivalent phrasing that matches the tone and length used elsewhere.
• When multiple locales offer slightly different details (e.g., one mentions a testing site like “Cascade Research Facility”), include the site name consistently if space allows; otherwise prioritize the relationship (field evaluation/testing) and retain names only when they are part of the lore.

Use this guide as the authoritative style and content reference when producing or reviewing in-game localization for the entities and short descriptions represented here.