LUC4N3X Thalarch Localization
Localization completeness is a product contract, not a side effect of the default locale compiling.
1. Discover the real locale surface
Inspect the repository rather than assuming a language list.
Identify:
- default locale resources;
- all translated locale/resource sets;
- plural/select resources;
- locale-specific assets/layout behavior where present;
- existing translation conventions and terminology;
- generated/localization tooling if the project uses one.
Do not add a new parallel i18n system when the project already has one.
2. Key parity
For changed user-facing strings, check:
- missing keys;
- extra/stale keys when relevant;
- duplicate keys;
- raw/unresolved key display risk;
- fallback to the default language that would create mixed-language screens.
A successful default-locale build does not prove translated resource parity.
3. Placeholder and formatting safety
Preserve the semantic contract of:
- positional placeholders such as
%1$s,%2$d; - number/date/time formatting;
- plural quantities;
- escaped apostrophes/quotes where the resource format requires them;
- markup/spans;
- newline intent;
- parameter order differences across languages.
Never "fix" a translation by deleting a placeholder needed by call-site logic.
4. Natural terminology
Translate for the product/domain, not word-by-word.
For established technical/product terms, determine whether the target locale normally:
- translates them;
- transliterates them;
- keeps the standard English/product spelling.
Terms such as Equalizer, ReplayGain, Crossfade, Preamp, codec names, protocol names, or brand
names may legitimately remain unchanged in some locales. Avoid awkward literal translations that a
native user would not recognize.
Do not invent premium/marketing wording absent from the source product intent.
5. Layout expansion
Review changed UI for:
- longer translations;
- wrapping;
- ellipsis/truncation;
- button width;
- chips/tabs/segmented controls;
- slider labels/units;
- dialog height;
- small-screen overflow;
- font scaling.
Short English source strings are not a safe layout bound.
6. RTL
For supported RTL locales, inspect:
- mirrored navigation/directional icons;
- start/end vs left/right alignment;
- padding/margins;
- row ordering when directionally meaningful;
- mixed LTR technical tokens inside RTL text;
- number/unit readability.
Prefer platform-aware start/end semantics and AutoMirrored icon variants where appropriate.
7. Translation review strategy
When authoritative human translations are unavailable:
- preserve existing project terminology;
- keep phrasing concise and idiomatic;
- avoid adding semantic claims not present in the source;
- flag uncertain high-impact wording rather than fabricating domain meaning.
Machine-generated text may be a draft, not proof of native-quality localization.
8. Automated checks
When practical, add or run checks for:
- key parity;
- placeholder signature parity;
- malformed resource syntax;
- duplicate identifiers;
- unresolved localization keys;
- locale resource compilation.
Keep checks aligned with the project's real resource format rather than installing a new framework for a small change.
9. Rendered verification
For a UI change, combine with thalarch-compose-ui or the relevant platform UI skill.
Render representative locales, especially:
- one language with longer labels;
- one RTL locale when supported;
- the default locale.
Source-resource parity does not prove clipping, wrapping, or visual hierarchy.
10. Completion report
State:
- locales discovered;
- keys changed;
- parity/placeholder checks run;
- representative rendered locales tested;
- any translations/layouts still
UNVERIFIED.