String Catalog Translation QA Checklist

A string catalog translator can shorten your release cycle only if the translated catalog still behaves correctly inside your app. QA is what separates "fast translation" from "safe release."

This checklist is designed for teams shipping Xcode String Catalog files on a regular cadence. You can run it in 15-30 minutes before every release, or use it as the acceptance pass after a larger localization update.

How to use this checklist

Run the checklist in three sweeps:

Technical safety — placeholders, plurals, and structural catalog correctness
UI quality — wording, truncation, and context correctness in visible surfaces
Release confidence — regression testing, spot checks, and final export review

That order matters. A string that sounds slightly awkward is still recoverable after release. A broken placeholder or incomplete plural set can create real bugs immediately.

1. Verify placeholder integrity

Confirm that every translated value preserves the same placeholders as the source string.

High-risk patterns include:

%@, %d, %f, %lld
positional placeholders such as %1$@ and %2$@
escaped line breaks and punctuation around placeholders

Check both presence and order. If the source says "Delete %@?", the translation still needs the same %@ token in a grammatically valid position. A missing or malformed placeholder can cause runtime crashes or obviously broken text in production.

2. Check positional placeholder order for each locale

Some languages naturally reorder sentence parts. That is exactly why positional placeholders exist.

If your source string has multiple dynamic values, verify that the translated string either:

keeps the same order safely, or
uses positional placeholders correctly to change the order

This is especially important in confirmation messages, billing summaries, and any sentence where a noun and number may move relative to each other.

3. Review plural category coverage

Plural QA is where many localization workflows fail quietly. English makes this look simple because it often needs only one and other. Many other languages do not.

Check that:

Arabic strings include all required categories
Russian and Slavic languages include their extra plural forms
zero-count strings still read naturally where applicable
inserted variables appear correctly inside each plural variant

Do not stop at "the catalog has plural entries." Make sure each category has natural wording and that no variant accidentally duplicates the wrong case.

4. Validate device-specific and platform-specific variants

If your String Catalog uses device variations, make sure each platform label still matches the interaction model.

Examples:

iPhone: "Tap to continue"
Mac: "Click to continue"
Apple Watch: shorter text due to space constraints

A translation can be technically correct but still feel wrong if it carries iPhone wording into a Mac string or turns a compact watch label into a sentence that no longer fits.

5. Spot-check short, ambiguous UI strings with context

Short strings cause the most visible translation mistakes because they often have multiple meanings.

Prioritize high-impact items such as:

paywall CTA labels
destructive confirmations
onboarding step headers
settings toggles
empty-state prompts

Words like "Save," "Check," "Clear," and "Post" need context. If the translated result feels slightly off, review it alongside the screen where it appears rather than relying on the catalog row alone.

6. Enforce terminology consistency

Decide your product vocabulary and keep it stable across the entire release.

If one part of the app says "Project," another should not switch to "Workspace" unless you intentionally distinguish the concepts. The same goes for "Upgrade" vs "Go Pro," "Continue" vs "Next," and other repeated labels that define how your product feels.

The fastest way to do this check is to scan repeated strings in:

onboarding flows
settings and preferences
subscription screens
navigation tabs

Consistency matters because users learn your app through repetition. Translation should reinforce that learning, not reset it on each screen.

7. Test for truncation, clipping, and layout overflow

After the catalog is translated, run the app and look for strings that no longer fit.

Check:

compact buttons
tab labels
settings rows
modals and alerts
Apple Watch and small iPhone layouts

German, French, and Russian often expand string length noticeably. If text wraps awkwardly or clips, decide whether to shorten the translation, increase available space, or redesign the component. Fixing layout issues before release is much cheaper than emergency UI patches later.

8. Review RTL and non-Latin languages separately

If you ship Arabic or other right-to-left languages, do not assume standard left-to-right QA is enough.

Verify:

punctuation around placeholders
mirrored alignment in buttons and lists
readability of combined Latin and non-Latin content
correct order in mixed strings such as product names plus numbers

Also spot-check Japanese, Korean, and Chinese separately because line length, density, and tone can differ from Latin-script assumptions even when the translation is correct.

9. Sweep for untranslated, stale, or suspicious entries

Before final export, scan the catalog for obvious leftovers:

English strings inside localized sections
placeholder tokens that look duplicated or broken
strings marked for review
stale entries from removed features
unusually long outputs compared to neighboring strings

This pass is fast, but it catches the "we should have noticed that" class of bugs that often survive until release candidates.

10. Run a final release regression in the translated build

The last step is not in the catalog. It is in the app.

Open the translated build and walk through the surfaces that matter most:

first-run onboarding
sign-in and account flows
paywall and purchase steps
creation, save, delete, and share actions
error messages and recovery states

If you have native-speaking testers or beta users, this is the moment to get feedback. Even a short pass from a real speaker can catch tone or terminology issues that automated checks never will.

What usually blocks a release

In practice, most release-blocking localization bugs fall into a few repeated patterns:

a placeholder is missing from one translated string
a plural category is blank or copied from the wrong form
a short button label uses the wrong meaning of a common verb
a compact layout clips text after expansion
one screen uses a different product term than the rest of the app

Those bugs matter because they affect live user actions, not just editorial polish. A slightly awkward sentence in a help screen is rarely urgent. A broken billing placeholder or destructive-action label is.

Who should own localization QA

The best QA owner is usually the person closest to release quality, not necessarily the person who translated the strings.

That can be:

the developer responsible for the feature
the product engineer who owns the release branch
a designer or PM doing UI acceptance
a native-speaking tester reviewing a target locale

What matters is that someone is explicitly accountable for the pass. If localization QA is "something we should probably do," it tends to happen too late or not at all.

What to do when a string fails QA

When you find a problem, fix it in the smallest loop possible:

identify whether the issue is context, terminology, layout, or technical structure
correct the translation or rerun the string with better guidance
verify the fix in the rendered UI
recheck related strings in the same flow

That final step matters. If one destructive action label is wrong, nearby confirmation text may need review too. Fixing the single string without checking the surrounding surface often leaves a half-solved experience.

Frequently asked questions

How long should translation QA take?

For most indie app releases, a focused pass takes 15-30 minutes. The goal is not to reread every string in every language. The goal is to validate the strings that are most likely to break the app or confuse users.

What are the most common xcstrings translation bugs?

The most common issues are broken placeholders, missing plural forms, ambiguous short labels, and text that expands past the available UI space. Those are the bugs worth prioritizing first.

How do I verify placeholder integrity quickly?

Start with strings that include format specifiers and compare source vs translation directly. Then open the screens where they appear to confirm the runtime output still looks correct once dynamic values are inserted.

Why do short strings like "Save" fail so often?

Because short strings rarely contain enough meaning on their own. The word "Save" can mean store, rescue, or save money depending on the screen. That is why context-aware review matters so much for UI localization.

A practical release routine

For recurring releases, use the same QA routine every time:

Generate or update translations
Run placeholder and plural validation
Spot-check high-visibility strings in the app
Check small-screen layouts for expansion issues
Export only after the final regression sweep passes

That routine keeps translation quality predictable even when release velocity increases.

Final takeaway

The goal of localization QA is not to read every string in every language line by line. The goal is to catch the failures that actually hurt users: crashes, broken placeholders, missing plural forms, inconsistent terminology, and confusing UI labels.

If you use StringWise regularly, this checklist becomes part of your standard release template. For workflow details, visit the XCStrings Translator page and the XCStrings workflow guide.

10-Point QA Checklist for String Catalog Translations (2026)