Petal Quest Localization: RTL, Plurals and a Small Font Atlas

Rank by the product of failure likelihood and user-facing impact, and by how late the fix can be made.

1. Arabic and Hebrew RTL layout (likelihood 5, impact 4). Every screen is affected, and a wrong arrow or reversed progress bar is immediately visible and embarrassing. Fixes can also require layout changes, so this must be found before freeze.
2. Polish and other plural strings (likelihood 5, impact 3). The concatenated gift string is a known architectural fault; it will be wrong, and it is cheap to fix early by converting to a plural-aware key.
3. Font atlas coverage for Arabic, Japanese and Chinese (likelihood 4, impact 5). A missing glyph is a visible box on every occurrence. It is expensive to fix late because the atlas is generated at build time; test it this week or accept broken text.
4. German expansion and truncation (likelihood 4, impact 2). Cosmetic-to-functional depending on the screen; buttons and tooltips matter more than body text.
5. Subtitle CPS in Spanish (likelihood 3, impact 2). Readability issue, fixable by editing timing without engineering.

The ordering also reflects fix cost over time: anything touching layout, fonts or string architecture goes first; text-only timing issues can be fixed after freeze.

Pseudo-localization replaces English strings with generated text that preserves structure but stresses the UI: accented and extended characters for the Latin pass, a length multiplier of about 1.4 to mimic German, brackets around the whole string to reveal truncation and concatenation boundaries, and doubled characters to expose hard-coded widths.

A second pass, RTL pseudo-localization, mirrors the layout and substitutes right-to-left characters to expose directionality assumptions.

It catches: text that overflows or is clipped, strings that are concatenated rather than composed, hard-coded strings never sent to the string table, fixed-width buttons, text baked into textures, layout that does not mirror, and missing glyphs in the atlas when the character set is extended.

It misses: translation quality, actual Polish plural rules, Japanese line-breaking rules, cultural appropriateness, and real Arabic shaping and bidirectional text mixing. It also misses length problems specific to a language that is shorter than the multiplier, and any issue caused by the actual translated string being semantically wrong but structurally fine.

So pseudo-localization is a pre-freeze engineering check, not a substitute for even a small native-speaker review on the highest-risk languages. I would run it nightly in CI and treat new overflow as a build failure.

Treat it as a data problem first. Polish needs separate forms for 1, 2-4 excluding 12-14, and everything else, so the string must become a plural-aware resource with at least three categories, not a concatenation with a number dropped in. I would check the resource file to confirm that the key exists with the required plural categories for Polish and that the runtime selects the category from the number rather than from a boolean 'is one'.

Test data: values 0, 1, 2, 3, 4, 5, 11, 12, 13, 14, 21, 22, 25, 101, 102, 112, and a large number, plus names that are long, contain RTL characters, and are empty. Expected result is not 'the Polish sentence is correct' - I cannot judge that - but 'the correct plural category is selected and no placeholder is dropped or duplicated'.

Evidence before sign-off: a screenshot or log per value showing the selected category and the rendered string; confirmation from the localization vendor or a native reviewer that the three category strings are grammatical; and the string shown as a plural key in the source, not a concatenation. Without the native review I would sign off the engineering behaviour and flag the linguistic quality as unverified, not silently accept it.