## 17 — Advanced multilingual play

**Decision: keep as a user-requested major feature.** Each user and PG should have language settings that shape commands, game text, and communication. A PG can decide whether communication is automatically translated **to** them and **from** them. The web game, forum, administration, and Telnet should share the same language model while respecting each interface's needs.

### User and PG language choices

- A user has a default interface language for registration, account management, and other screens without an active PG.
- Each PG can override that default with their own preferred interface language. Switching PG updates the web game, forum, and relevant controls without changing another PG's preferences.
- Each PG can set the natural language they normally write or speak and, if useful, other natural languages they understand. The chosen language should guide replies from help and suitable AI NPCs, subject to what those NPCs know.
- Separate switches control **incoming auto-translation** and **outgoing auto-translation**. The PG can turn either on or off independently; the settings follow that PG across sessions and clients. Optional per-channel or per-conversation exceptions can be designed later.
- A PG can read the original alongside any translated message and change their settings without losing the original text.

These natural-language preferences are distinct from the classic in-world `speak`/`parla`/`lingua` system. That system governs what a character can speak or understand in the fictional world. A real-world translation setting must not reveal words that the game's language rules say a PG cannot understand. Exact interaction between the two systems needs explicit design and playtesting.

### Commands and game text

Support equivalent command names and arguments in each supported language, resolving them to the same game action and permission checks. Command help, errors, prompts, menus, item and ability names, room descriptions, NPC dialogue, notifications, journal, map, quests, and forum controls should follow the active PG's preferred language where translations exist. The account screens follow the user default.

Author and store game text under stable content identities, with reviewed translations by locale and a clear fallback when a translation is missing. Existing Italian text remains available as the original-language fallback. Preserve classic Telnet output and command behavior for players who have not selected a new locale. A localized command should not be guessed from arbitrary prose, and aliases or abbreviations must resolve consistently if two translated commands overlap.

Builders and administrators need a translation workspace showing the source, each locale, missing fields, revisions, and the published version. Prepare high-quality translations of rooms, lore, quests, help, and other authored content with the owner and assistant here during development; review and store them for reuse in the game. The stronger authoring model is used here, not through a paid game API. Reviewed authored text is authoritative for rules, lore, quests, and other published world content. Names and terms that must remain consistent should have an approved glossary. Tie published translations to the source revision, locale, and glossary version so changes identify what needs review; ordinary room visits and page views read saved text without a model call.

### Communication between PGs

Apply the PG's incoming and outgoing choices to relevant live channels such as room speech, tells, groups, and public channels. Preserve the sender's original message. When translation is permitted by the sender's outgoing setting and requested by a recipient's incoming setting, show a translated rendering in the recipient's language, clearly marked as a translation with access to the original. Recipients can have different renderings of the same message; neither changes what the sender wrote.

The same model extends to forum posts and chronicles: preserve the authored original, allow eligible readers to request a translation, and distinguish a translated rendering from an author-approved version in another language. A player writing in one language should not have their words silently presented as an official translation. Translation of private communication must respect its original audience, moderation rules, and retention policy.

Translation must preserve speaker attribution, order, names, commands quoted as text, and game-specific terms. If translation is unavailable or uncertain, deliver the original with an honest indication rather than inventing a message or dropping it. Translation must never turn a player's speech into a game command or bypass visibility, channel, or in-world language restrictions.

Live translation uses suitable free models first, moving to another approved free route when capacity is exhausted, then to the future local GPU or a very inexpensive API within the shared budget. Preserve terminology through the approved glossary. Generate a permitted translation once per message and requested locale, reusing it for eligible recipients without broadening the original audience. Live chat does not automatically escalate to an expensive model. This inexpensive live workflow is separate from preparing and publishing high-quality authored translations here.

### Examples to validate

| Situation | Expected behavior |
| --- | --- |
| One user switches from an Italian PG to an English PG in the web app | Commands, game text, and forum controls follow the newly active PG; each PG keeps their own communication settings. |
| An Italian-speaking PG sends a tell to an English-speaking PG | If the sender allows outgoing translation and the recipient requests incoming translation, the recipient sees a marked English rendering and can inspect the Italian original. |
| Either PG disables a relevant translation switch | The original message remains available; no automatic translated rendering is made for that delivery. |
| A PG receives speech in a fictional language they cannot understand | Real-world auto-translation does not expose the hidden meaning. |
| A room has no reviewed translation in the PG's chosen language | The game uses its explicit fallback and can indicate the available source language. |

### Decisions and open design

- Keep: **advanced multilingual support across web and Telnet, including commands, game content, community writing, and PG-to-PG communication**.
- Keep: **user default plus independent PG language preferences and separate incoming/outgoing auto-translation controls**.
- Keep: **high-quality authored translations prepared here, reviewed, stored, and reused; free-first, local or very inexpensive translation for live messages**.
- Preserve: **original messages, classic in-world language rules, Italian source text, and existing Telnet behavior by default**.
- Still to choose: **first supported locales, translation providers, exact per-channel controls, verification of machine output, latency and cost limits, and the details of fictional-language interaction**.