Validate English and Spanish paths

1466. Lesson identity

Module

3.18 — Localization architecture

Lesson

2 of the module

Academic type

Integration

Schema type

Practical

Estimated time

50–70 minutes, including practice

Title

Validate English and Spanish paths

1467. Learning objective

After this lesson, you can create or refactor at least one English–Spanish string pair stored under one shared stable semantic key, verify its variables, execute defined failure cases in development and production-mode configurations, and capture evidence that both language paths remain readable in the target control.

1468. Why this matters

A localization system is useful only when players can complete the same interface action in every supported language. Correct wording can still fail because a variable is absent, a fallback conceals missing content, a font lacks a Spanish glyph, or translated text clips when the interface is scaled.

Development and production have different diagnostic priorities. Development behavior should make missing content conspicuous and distinguish a missing shared key, missing locale value, and missing variable. Production-mode behavior should apply the explicitly defined safe response while preserving a diagnostic record. Production-mode tests should run in a safe test or staging context that uses the production configuration; do not create deliberate failures in a live player environment.

1469. Prior knowledge

You should already be able to:

• distinguish a shared semantic key from a key based on screen position or English wording;
• store English and Spanish locale values under one shared key;
• pass named variables to a localized string;
• distinguish a missing shared key, a missing locale value, and a missing variable;
• use the localization contract introduced in Text needs an architecture.

Review the previous lesson if those conditions are not yet true.

1470. Core concept

Validate localization through five separate gates:

1. Meaning: The English and Spanish locale values communicate the same player-facing action or state.
2. Data: Required placeholders are present, consistently named, and supplied with intended values and formatting.
3. Failure behavior: Missing content produces the defined development and production-mode outcomes and diagnostic records.
4. Rendering: Representative Spanish characters are available in the selected font or an intentional fallback font, without replacement boxes or unintended substitutions.
5. Layout and access: Text remains readable and the target control remains identifiable and usable at default size and at one supported scale or zoom setting.

Passing one gate does not prove the others. A Spanish value can be semantically accurate but clipped, or it can fit while displaying a missing glyph.

1471. Five-pass localization gate

Run the gate separately for each locale. An English capture is not evidence for Spanish.

1472. Concrete example

Shared key: delivery.status.remaining
English locale value: Delivery to {destination} in {minutes} min
Spanish locale value: Entrega a {destination} en {minutes} min
Variables: destination = "North Gate", minutes = 4

Removing minutes must produce the behavior defined for a missing variable. Removing the Spanish locale value is a different failure from removing the shared key entirely, so record those cases separately. For glyph coverage, render a representative Spanish test value in the same target control, for example:

Información: misión rápida, año 4, pingüino. ¿Continuar? ¡Sí!

This sample exercises accented vowels, ñ, ü, and inverted punctuation. It is a rendering probe, not a substitute for reviewing the actual interface wording.

1473. Fallback contract

For every supported failure case, state:

• what the developer sees in development;
• what the player-facing control shows under the production-mode configuration;
• what log, event, or other diagnostic record preserves the defect;
• how the evidence distinguishes a missing shared key, missing Spanish locale value, and missing variable.

Do not count a silent English substitution as proof that the Spanish path passed. It may be the defined production fallback, but the missing Spanish locale value remains a recorded defect.

1474. AI-native workflow

Use AI as a comparison and test-generation assistant, not as the final authority:

1. Provide the shared key, both locale values, intended meaning, variable contract, fallback contract, font chain, target-control constraint, and supported scale or zoom setting.
2. Ask for a parity table and possible variable inconsistencies.
3. Ask for edge cases, including long values and representative Spanish characters.
4. Ask it to separate development behavior from production-mode behavior.
5. Reject suggestions that create language-specific keys, change meaning, bypass the fallback contract, or claim visual success without runtime evidence.
6. Execute the tests yourself and retain the resulting captures or logs.

1475. Guided practice

Create or refactor at least one English–Spanish pair under one shared stable semantic key. Prepare a validation record for three interface strings: an action label, a status message, and a message with a variable. You may use these examples or equivalent content:

Shared key: menu.confirm
English locale value: Confirm
Spanish locale value: Confirmar

Shared key: inventory.empty
English locale value: No items available
Spanish locale value: No hay objetos disponibles

Shared key: mission.destination
English locale value: Destination: {place}
Spanish locale value: Destino: {place}

Complete the following work:

1. Record each shared semantic key, its two locale values, and its variable contract.
2. Compare meaning, action, tense, plurality, and implied subject.
3. Define development and production-mode behavior for a missing shared key, missing Spanish locale value, and missing variable.
4. Execute all three failures in both configurations. Capture the visible runtime result and the corresponding diagnostic output or log. If a configuration does not support a case, record that limitation rather than simulating a successful result.
5. Render actual Spanish content and the representative glyph probe in the target control. Identify the active font or intentional fallback font when the tooling makes that information available. Capture any missing-glyph marker, substitution, or spacing problem.
6. Capture the English and Spanish target control at its default presentation and at one supported scale or zoom setting. Check clipping, overlap, line wrapping, hierarchy, readability, and whether the control remains identifiable and usable.
7. Test a long variable value such as Old Foundry Storage District and record the resulting layout.
8. For each failure, decide whether the correction belongs to locale data, the call site, fallback behavior, font configuration, or layout. Explain the decision before changing the implementation.

1476. Validation evidence

Complete the registered practical assessment Localization path runtime validation record. The submission must include:

• at least one English–Spanish pair created or refactored under one shared semantic key;
• the three tested keys, locale values, and variable contracts;
• executed development and production-mode evidence for a missing shared key, missing Spanish locale value, and missing variable;
• visible runtime output plus captured diagnostic output or logs for each failure case;
• visual evidence of representative Spanish glyphs and any font fallback in the target control;
• English and Spanish captures at default size and one supported scale or zoom setting;
• a layout and control-usability observation for each presentation setting;
• at least one corrective decision with its reason.

A statement such as “the translations look correct” is not sufficient evidence.

1477. Key takeaways

• Store both locale values under one stable semantic key.
• Test missing keys, locale values, and variables as distinct failures.
• Execute development and production-mode behavior and preserve runtime evidence.
• Verify Spanish glyphs and font fallback in the actual target control.
• Check readability and control usability at default size and a supported scale or zoom setting.
• AI can propose comparisons and edge cases, but observed runtime and visual evidence determine the result.

1478. Stage 4 handoff

Carry the localization validation record into Stage 4 as release evidence. Do not hand off only a pass/fail summary. List unresolved missing-content, fallback, variable, glyph, font, readability, and layout findings so Stage 4 can classify each one as a blocker, risk, follow-up, or unsupported claim. Preserve links between every finding and its runtime capture, visual evidence, or diagnostic record.

1479. Knowledge check