Unreal Engine Localization QA: FText, PO Files and Packaged Builds

Unreal Engine localization QA becomes faster when a team stops treating translated sentences as isolated files and starts checking the path that carries them into the game. If you are looking for an Unreal Engine 5 localization workflow, the important questions are practical: was the text gathered, did the translation retain its identity, was it compiled, and will the packaged game display it under the intended culture?

That is why a useful Unreal translation checklist begins with FText, the Localization Dashboard, Portable Object (PO) export and import, and a real packaged-build test. Searching for “Unreal Engine gather text not working” or “Unreal translations missing in packaged game” often points to different failures that look identical to the player: English appears where Spanish, French or Japanese was expected.

Did you know that a beautiful translated PO file can be irrelevant to the finished game? A line that was never gathered cannot be repaired by editing a translation catalog. A catalog that was not compiled or staged cannot be fixed by proofreading the words. This guide gives one reader job a complete treatment: prove that the correct localized player-facing text actually arrives, survives and behaves in an Unreal project. For translation-memory matching, sentence craft and the broader value of localization, follow the related eduKateSG series rather than trying to solve those separate jobs here.

Quick answer: what does a good Unreal localization QA pass prove?

A complete pass follows one string through five evidence points. First, the string exists as gatherable, localizable text. Second, the gathering rules include the asset or source file containing it. Third, a stable localization identity connects the source, extracted catalog and target-language entry. Fourth, the target data is imported, compiled and included in the build. Fifth, the correct text appears during real gameplay with the intended language and locale, including dynamic arguments, fonts, input behavior and layout.

Imagine a game in which a door opens only when the player has collected three keys. The screen says “You need {Count} more keys.” An English development build looks perfect. A French translation is approved. Yet the French shipping build says the English sentence. That is not automatically a translation-quality problem. It may be a missing gather path, an uncompiled resource, an unsupported culture, a string built with the wrong Unreal type, or a runtime widget that never refreshes. The effective workflow identifies which layer failed before anyone rewrites a good sentence.

The fastest reliable order is inventory, gather, compare, translate, import, compile, package, switch culture, play, record. Resist the urge to start with random edits to visible strings. Changing several layers at once often destroys the evidence needed to identify the real cause.

Why Unreal text has more than one identity

People normally read the words on screen and assume the words are the data. Unreal’s localization model is richer. The documentation describes localizable text through namespace, key and source string. The namespace and key identify the text entry; the source string is the current original wording and helps determine whether an existing translation is stale. Two identical English expressions can legitimately carry different identities if they mean different things in the game.

Take the word “Charge.” In one inventory menu it may be a noun describing the energy stored in a weapon. In a combat tutorial it may be an imperative instructing a player to attack. In a payment screen it could mean a fee. If developers flatten these into one string because the spelling matches, translators cannot reliably choose the right target expression. Different namespaces or keys make the intent inspectable. The QA task is not to demand a unique translation for every occurrence; it is to ensure that the system permits different meanings when they are needed.

Now consider a designer changing “Gather three keys” to “Collect three keys.” A catalog may still contain a translation of the earlier source wording under the same identity. The change is small, but it can affect the tone or action label. A good update process detects source changes and marks the relevant target for review. An outdated string should not be waved through merely because its key still exists.

Identity is also different from location. An entry can retain its namespace and key while moving from one screen to another. That reuse can be valid, but the destination may provide new context or a new character limit. Quality assurance checks what the string means where it appears, not just whether the lookup succeeds. This is especially important for controls such as Continue, Back, Skip and Exit, whose verbs acquire meaning from the user’s current state.

FText, FString and FName: pick the correct tool before gathering

Unreal documents FText as the primary type for localized user-facing text. FString is useful for manipulating strings, and FName is useful for identities or identifiers. They are not interchangeable merely because each can relate to readable characters. A tempting shortcut is to create a displayed message through a bare string conversion and assume it will enter the gather process. Whether it has an appropriate localizable identity matters more than whether the widget successfully displays the English words.

A useful audit labels each visible string by origin: Blueprint text property, C++ LOCTEXT or NSLOCTEXT literal, String Table, Data Table, runtime-generated value, external service response, player-entered name or artwork containing text. The translator does not need to understand every C++ detail, but the QA owner should be able to ask the engineer where each category enters the localization system. A screenshot showing English is not proof that the text was gathered.

In C++, the following illustrates the distinction. The macro marks a localizable literal with an identity; the target-language wording belongs in the localization resources, not in a hardcoded language switch beside the gameplay logic.

#define LOCTEXT_NAMESPACE "InventoryScreen"
const FText UseLabel = LOCTEXT("UseItem", "Use");
const FText InspectLabel = LOCTEXT("InspectItem", "Inspect");
#undef LOCTEXT_NAMESPACE

This snippet is illustrative rather than a drop-in project change. An Unreal project has conventions governing where text is declared, how namespaces are managed and which targets gather each module. More importantly, developers should verify that user-facing strings supplied through Blueprints and assets are similarly gatherable. A code sample that works is useful evidence; a complete asset audit is what makes the evidence representative.

FText also carries text history needed for culture-aware behavior. Turning an FText into FString and back can lose localization information. A team that uses string manipulation for a display message should inspect whether the final text is still produced from a localizable pattern. The better mental model is that a message is a localized template plus runtime values, not an English sentence assembled and then handed to a translation system as an afterthought.

Build a string inventory that follows player behavior

Before the first export, walk through the game’s important user journeys. Write down where text appears: title screen, accessibility options, save confirmation, inventory, tutorials, quests, map markers, combat prompts, pause menu, error messages, downloadable content and end credits. If a player can reach it, it belongs somewhere in the inventory. The key is to distinguish text that belongs to the Unreal localization target from material sourced elsewhere.

Inventory by journeys rather than by raw file count. A spreadsheet with 4,000 localization keys can be complete from the build system’s perspective while the player never sees a translated failure message because it was dynamically constructed in a plugin. A journey-based inventory reveals that gap. For each screen record the triggering action, asset or subsystem, source wording, expected key or table reference, target culture, screenshot reference, importance and reviewer. Low-risk decorative labels can be sampled; critical consent, purchase and irreversible-action messages require deliberate review.

Use a small golden path: launch game, begin a new save, change language, collect an item, fail a task, receive a reward and exit. Trace the same path under two target cultures. This is not enough for complete coverage, but it gives an early warning about systemic failure. If every translated control is missing, investigate target loading. If only one menu is English, investigate that menu’s source. If strings appear but punctuation and numbers are wrong, investigate locale and formatting.

An inventory also prevents a common scheduling error: the linguist finishes a catalog while developers are still adding text under new assets. Record a source snapshot or build revision beside each export. The project’s source version and catalog version should be comparable, not guessed from filename modification times. When the game changes after translation, decide whether to perform a delta gather and focused review rather than blindly retranslating the entire catalog.

Gather Text is an extraction test, not a translation button

The Localization Dashboard manages targets and includes controls for gathering, exporting, importing and compiling localizable text. A typical project uses a Game target, although larger projects can define more than one. The team must specify which source code and assets are gathered and which cultures the target supports. A successful gather means the configured sources were scanned; it does not guarantee that every player-visible sentence was written in a gatherable form.

A practical investigation starts with three questions. Was the correct localization target selected? Did the source and asset gathering paths include the modules, content directories and packaged assets of interest? Did the build log report skipped or unrecognized text? If the inventory screen is absent from the gather output, translating a PO file cannot create a missing entry. Correct the extraction cause first, then gather again.

Treat path patterns and exclude rules as explicit coverage decisions. A developer may exclude prototype assets to reduce noise, which is sensible until production gameplay still references a menu stored in that directory. Another team may reorganize Content folders, leaving a gather path pointed at an older location. The symptom is a mysteriously shrinking catalog. A before-and-after inventory of gathered keys can identify that regression far earlier than a playtester who happens to visit a rare screen.

It helps to establish a tiny fixture: one text literal from source code, one Blueprint-authored label, one String Table entry and one asset or Data Table string from the project’s real architecture. After gathering, confirm that all four appear with recognizable identities. If the fixture fails, do not process thousands of translations. The fastest localization pipelines are not those that avoid tests; they use a very small test to prevent a very large amount of invalid work.

String Tables simplify reuse, but do not remove context

String Tables centralize pieces of text and let assets reference entries instead of embedding new copies everywhere. They can be helpful when a game has common item labels, navigation controls or systematic messages. Their benefit is traceability: the team can point to the entry responsible for a displayed label. Their risk is over-sharing: two screens can reference the same entry even when the words deserve different wording in the target language.

Suppose “Ready” appears on a team lobby and on a cooking mini-game. The lobby describes a player’s state; the cooking mini-game announces that food is prepared. English uses the same surface word. Some target languages require distinct forms. A single shared table entry might therefore be the wrong model even though it reduces maintenance. QA should raise a context issue rather than edit the one translation until one of the screens becomes wrong.

When localizing a table, request not only the key and source text but also the screen, character, grammatical role and any variables. A table entry such as Items.Tooltip_43 reveals little on its own. A screenshot of the inventory plus a note explaining whether “Use” means consume, equip or activate can save repeated translator questions. Consistent context is a speed tool because it eliminates decisions that would otherwise recur for every language.

Data Tables introduce another problem: the identity of imported text may change across reimports if the project’s pipeline does not stabilize keys. Unreal’s documentation describes techniques for assigning deterministic text identities after import. The editorial lesson is simple: if an apparently unchanged CSV refresh causes a large number of translations to look new, investigate identity stability before assuming the language vendor has lost its memory. The right fix is often in how the source data is represented.

Export PO files only after source and context are ready

PO files allow translators and external systems to handle message IDs, source strings and target strings in a familiar interchange format. Unreal’s localization documentation discusses PO export modes and how msgctxt, msgid and msgstr may be used. That matters because a tool configured for the wrong export mode can misunderstand whether an apparent identifier is the source phrase or an identity field.

Read the export’s actual structure before designing a filter. A conventional PO entry may look like this:

msgctxt "InventoryScreen,UseItem"
msgid "Use"
msgstr "Utiliser"

This is a pedagogical shape, not a promise that every Unreal export uses that exact context formatting. Use the project’s generated catalog as the authority. A QA tool should verify that each target entry maps to the expected source identity and that the import respects the same mode used at export. A perfectly grammatical translation associated with the wrong ID is not correct for the game.

Decide how to handle comments, references, obsolete entries and source edits. A tool may import a valid PO file while ignoring entries whose identities no longer match. Record how many messages were exported, translated, reviewed, imported and compiled. The counts will not always be identical, because exclusions and locale-specific decisions exist, but unexplained differences need investigation. This is where a short audit log saves hours of searching through screenshots later.

PO files are also vulnerable to ordinary text-processing damage. An editor can alter quotation marks, character encodings, multiline entries or escapes. The file may look readable in a spreadsheet and still parse differently. Use a PO-aware editor or parser, keep the source snapshot, and validate on import. Never flatten the catalog into a two-column spreadsheet without preserving identity and context. Two occurrences of “Open” can then collapse into one cell and lose the reason they were separate.

Translate dynamic messages as patterns, not fragments

Games create many messages that depend on current values: the number of lives, the player’s name, a quest target, a remaining timer or a currency amount. If developers concatenate English fragments such as "You have " + count + " keys", they force the target language to follow an English word order. A better design is a localizable format pattern with typed or named arguments and localized numeric presentation where appropriate.

Take a message: “{PlayerName} found {ItemCount} keys.” Imagine a target language that needs to move the player’s name or express a different form for one item and many items. The language reviewer needs to know what each parameter means, which forms are possible, and whether the game produces zero, one or many. The technical reviewer needs to know whether the target preserves the required argument names. A message may compile and display but still tell the player the wrong person received the reward if arguments are swapped.

In Unreal, FText formatting and culture-aware text facilities support working with localized patterns. However, QA must test the actual application logic. A translator should not invent a plural-selection mechanism that the code does not implement. Conversely, an engineer should not assume translators can solve plural behavior by writing a single English-style sentence. Define the parameter contract first, choose the supported formatting strategy, then test counts that reveal grammatical branching: zero, one, two and a larger value.

For each dynamic message, build test fixtures with clearly distinguishable values. Use a fictional player such as “Mina” and an item such as “blue lantern,” not two placeholders that are both generic names. Check the full sentence with the game font, not only the template. If a quantity is already formatted upstream, avoid formatting it again in the translation layer. This is where language, code and presentation intersect, and responsibility must be explicit.

Compile means turning approved translations into usable game data

Importing a translation is not the same as having a player see it. In the Dashboard workflow, translations are compiled to localization resources used by the engine. Teams sometimes stop after the import button reports success. A subsequent runtime test still shows English, and the translator is asked to “try another wording.” The wording is not the cause. Determine whether the correct localization resources were built and whether the game can load them.

Build a short chain-of-custody record: target name, source culture, translated culture, export revision, imported file, import result, compiled resource, packaged build identifier and runtime observation. Each stage should point to a testable artifact. A reviewer who knows that an entry exists in the PO file but not in the compiled resource has already narrowed the issue substantially.

Compile errors deserve separate categories. A malformed message can fail format validation. A catalog may contain obsolete entries that no longer apply. A target may compile for one culture and not another. An import might succeed while leaving untranslated entries untouched. Logging all these as “translation issue” makes the workflow slower because it sends every defect to the wrong person. Use language review for meaning, engineering review for loading and formatting, and production review for scope decisions.

Do a controlled round trip with one highly visible fixture before importing the full set. Change a harmless test string in a non-production branch, import the target translation, compile, and run the build. Restore or finalize it according to project policy. If the fixture does not appear, stop. Repeatedly running full exports on a broken configuration is not diligence; it is expensive repetition.

Culture is not one switch: language, locale and assets can differ

Unreal distinguishes the active language used for localized text, the locale used for formatting dates and numbers, and potentially cultures applied to groups of assets. A French-language interface can be paired with a regional number format that is not French, depending on requirements. Similarly, audio localization may follow a different asset-culture setting. QA therefore should not infer all settings from the language shown in one menu.

A test case might use French interface text, a particular regional date convention and an English voice track. The correct result is whatever the product specification promises, not necessarily an arbitrary assumption that all cultural settings must match. Record each setting separately. Test a date such as 04/05/2026 where interpretation could be ambiguous, a decimal amount such as 1,234.50 in a defined currency, and a culture-sensitive name or sorting example if relevant. These data checks complement linguistic review; they do not replace it.

Unreal provides APIs and Blueprint-accessible facilities for querying and setting active language and locale. The documentation also describes preview controls and startup overrides. A quick preview can show whether translations are broadly present, but it may not reproduce every runtime formatting behavior. Epic’s documentation specifically cautions that editor previews are not always identical to standalone runtime behavior. Use previews for fast discovery and standalone or packaged testing for release confidence.

Test culture switching as an event. What happens to an open pause menu when the player changes language? Are widgets recreated, refreshed or left with cached English text? Does a quest log created before the change update correctly? Do assets using a different culture follow their intended policy? A test that relaunches the game every time can miss problems in live switching. A test that only changes language live can miss startup defaults and persisted preferences.

Packaging is the final boundary between a successful editor test and a real release

A translation can work in an editor preview and disappear from a packaged build. Packaging settings determine which localizations are staged and which internationalization data are included. The Unreal localization overview describes settings such as Localizations to Package and Internationalization Support. QA should inspect them for the project’s selected target cultures rather than assuming the editor’s access to data implies the shipping build has it too.

Consider a team that tests French successfully in development, then creates a smaller shipping package that includes only English localization data. The game launches, all controls work, and there may be no crash. The user simply receives the wrong language. This is a release defect even if a translation vendor delivered perfect French and the editor displayed it correctly. A build manifest and a packaged-game language smoke test are necessary evidence.

Another failure concerns fonts and localized artwork. The text resource is present but the font does not contain the required characters; players see boxes or missing glyphs. Or a menu banner includes baked-in English lettering while the widget labels are translated. These are separate assets and may follow different packaging paths. The inventory should identify them before localization begins, and the packaged build should demonstrate the finished screens rather than relying on a translation file diff.

A practical gate uses the exact release candidate, not a developer’s recent editor session. Start with a clean install or clean deployment appropriate to the platform. Select the language, restart, visit high-risk screens, trigger a dynamic error, inspect settings, save and reload, and compare screenshots to the approved context pack. If platform-specific packaging varies, sample each supported platform or document precisely what has not been tested.

Worked example: a quest objective that remains English

Suppose the objective panel says “Return to the lighthouse” in English after switching the game to Spanish. The localization team has translated it as “Regresa al faro.” A beginner might edit the Spanish wording and rebuild. The controlled investigation proceeds differently.

First, capture the screen and identify which quest asset or data row supplies the objective. Confirm the displayed text is represented as FText or a proper String Table reference rather than assembled from an untracked raw string. Second, gather and inspect whether the current source wording appears under a stable namespace and key. Third, locate the Spanish catalog entry and confirm it matches the gathered identity. Fourth, inspect the import and compilation result, not just the existence of a PO file on disk. Fifth, verify the Spanish culture is packaged and loaded.

Now suppose the string appears correctly after restarting but stays English if the player changes language while the quest panel is open. The problem has shifted. The resource path is probably functioning; the active widget or gameplay model may have cached a resolved string and not refreshed it on culture change. The solution belongs to runtime state handling rather than linguistic rewriting. Record the triggering sequence: create quest in English, open journal, switch to Spanish, return to journal. Then test a second path: launch directly in Spanish and create the quest.

Finally inspect the sentence in context. Does “Return” mean physically travel back or hand an item back? The quest screenshot resolves the ambiguity. Engineering QA proves that the intended text arrived. Linguistic QA proves that the text communicates the correct player action. Both are necessary; neither should be mistaken for the other.

Worked example: a payment confirmation with numbers

A game sells a cosmetic item. The English text says “Confirm purchase of {ItemName} for {Price}?” A localization file contains a natural target sentence, and the UI displays it. Yet the price is shown in the wrong regional format and the item name appears twice because the widget builds an outer label and an inner confirmation from different templates.

Start by distinguishing template identity from value provenance. {ItemName} is an item display name and may itself need localization; {Price} should come from the commerce system with the right price and currency information. Never translate a sample number hardcoded into a screenshot and then assume it matches the real price. Never translate the currency symbol as if it represented a fixed currency independent of purchase context. The runtime contract, not the translator’s taste, determines these values.

Create a controlled test item with a known price, a long name and a non-Latin target translation. Open the flow in the source culture and target culture. Compare the item identified in the button, confirmation, receipt and inventory. If any mismatch could cause a user to authorize a different purchase than expected, escalate as a release blocker. A successful string lookup is not enough; the interface must preserve a truthful decision.

This example also shows why a one-size-fits-all word-count or automated quality score can mislead. The consequential issue is the relationship between text, data and action. Two equivalent French phrases may both be acceptable. An attractive phrase attached to the wrong product or amount is not. Risk-based QA spends time on consequences rather than treating every line as equally important.

Test matrix: organize failure modes by the first layer that breaks

Symptom in game	Likely layer to inspect first	Evidence to request	Useful repair direction
One screen stays in English	Source representation or gather scope	Asset path, source type, gathered entry	Make text gatherable or include the source
Many screens stay in English	Target compilation or culture loading	Import log, compiled resources, active culture	Repair build/culture configuration
Only shipping build fails	Packaging	Packaged cultures, build manifest, clean install	Stage required localization and ICU data
Translation disappears after source edit	Identity or stale catalog	Namespace, key, old/new source, PO diff	Review source change and regenerate appropriately
Phrase wrong only in one context	Shared key or inadequate context	Screenshots and key references	Separate contexts or clarify the entry
Placeholder appears literally	Runtime formatter or template contract	Pattern, argument names, execution fixture	Fix argument injection and formatting
Text breaks on language switch	Caching or widget refresh	Reproduction sequence and state	Rebuild/rebind the displayed localized text
Boxes replace letters	Font coverage or asset setup	Character samples and packaged font	Supply tested target-script assets

The matrix is a starting hypothesis, not a diagnostic oracle. One visible symptom can have multiple causes. The point is to ask for the most discriminating evidence first. If the translation is present in the compiled resource, there is little value in asking the linguist to retype it. If the asset was not gathered, there is little value in repeating packaging tests. A disciplined ordering reduces cycles between teams.

Practical regression procedure for a small team

A small team does not need a large localization department to follow this method. Appoint one owner of the test build and one owner of the language decisions. Choose a compact baseline representing common features and high-consequence actions. Establish a screenshot set with locations and player states. Keep one simple change log listing source edits, target edits, engine upgrades and packaging changes since the last tested build.

At each content milestone, rerun the fixture and the golden path. After a source text change, compare identities and request only the target-language review that is actually affected. After a UI change, prioritize layout and truncation. After a build-system change, prioritize resource compilation and packaging. After a language switch implementation change, prioritize live refresh and persistence. This separates the regression cause from the mere fact that a defect was noticed today.

Do not assume that a passing English build establishes a passing Spanish or Japanese build. In English, a short button might fit, an unsupported glyph might never appear and a right-to-left layout problem might be invisible. Conversely, do not test every language on every low-risk screen with the same depth. Combine automated resource checks across all languages with sampled real gameplay and deeper human checks for languages, screens and script systems with higher risk.

A release note can summarize evidence without overwhelming anyone: source build, target cultures, catalogs imported, compile status, packaged environments, test routes, exceptions, owner and approval. If someone asks “Was Japanese tested?”, the answer should identify the build and screens rather than depend on recollection. That is both faster and more responsible than treating localization as a final cosmetic pass.

Where automation helps and where it must stop

Automation is useful for repeated assertions. Count entries after gathering. Compare key inventories between versions. Detect missing target entries. Validate expected placeholder names. Inspect target packaging lists. Search logs for import or compile errors. Capture screenshots from scripted game paths where the project supports it. These are bounded, observable tasks. They free human reviewers to inspect actual meaning and use rather than searching for missing commas.

Automation is less reliable when the question depends on the social or gameplay meaning of a sentence. An algorithm can see that “Charge” has been translated consistently, but consistency may be the problem if one occurrence concerns an attack and another concerns currency. A length checker can report that a label fits a character limit but cannot guarantee that a player understands the available action. A screenshot-diff tool can highlight layout changes, but a longer target language may need legitimate rearrangement rather than compression.

Use fast machine translation or suggestions only within an approved workflow that preserves identities and context. Protect names, placeholders, prices and user data according to project policy. Sensitive unreleased content should not be copied into arbitrary online services. Human review remains mandatory for consequential messages and for language forms the team cannot verify through simple string comparisons.

The useful principle is not “automate translation” but “automate inexpensive, repeatable observations.” That makes source problems visible early and keeps linguistic attention on choices that genuinely require it.

Transfer: the same evidence logic applies outside Unreal

If you later work in Unity, Godot or a web framework, the file formats and APIs change. The basic quality question does not: where did the original text come from, how was its identity preserved, which target entry was selected, and what does the user actually see? A new engine may use string keys rather than namespaces, JSON resources rather than compiled localization data, or different build settings. Do not copy Unreal menu names into those environments. Transfer the sequence of proof, not the interface steps.

The same thinking also benefits students who are learning languages. A learner may believe a sentence is correct because its dictionary translation looks convincing. Yet a word may refer to a different actor in context, or a number may be attached to the wrong object. Asking what the sentence does in a real interaction exposes problems that isolated word matching cannot reveal. This is a language-learning principle as much as a software testing principle: meaning is verified in use.

For parents and tutors reading this series, a useful activity is to give learners two screenshots that use the same English word differently. Ask them to explain each action before translating. Then have them compare their versions in a full sentence, not only in a vocabulary list. This reinforces contextual reading, grammatical role and precise communication without pretending that memorizing one dictionary entry solves every case.

Summary: speed comes from proving the pipeline once

An Unreal localization pass is efficient when it can answer five questions without guesswork: Was the text built for localization? Was it gathered from the correct project sources? Does the translated entry belong to the correct namespace and key? Was it imported, compiled and packaged for the intended culture? Did it behave correctly inside the actual game, including when state and language changed?

If the answer is no at an early stage, fix that stage before repeating later work. If all five answers are yes, examine semantic fit, formatting, font coverage and player consequences. A reliable system lets translators spend less time hunting invisible technical defects and more time choosing accurate words.

The practical promise is not zero bugs or instant multilingual release. It is fewer blind loops, clearer ownership and evidence that the player received the intended meaning. The engine can deliver a localized experience only when source, translation, build and runtime are connected deliberately.

Frequently asked questions

Why is my Unreal Engine translation still English after importing a PO file?

An imported PO entry does not prove that its source was gathered, its identity matched, localization resources were compiled, the relevant culture was packaged, or the game loaded that culture. Check the chain in that order. If only one text source is affected, inspect its FText representation and gather coverage. If the problem is widespread, inspect target compilation and packaging.

Should all strings in an Unreal game use FText?

Player-facing text that needs localization generally belongs in FText or another supported localizable structure that resolves to it. FString and FName have different uses, including manipulation and identifiers. Do not convert all data indiscriminately; classify whether the string is displayed to the player and whether it needs language-aware behavior.

Does the Localization Dashboard replace review by a translator?

No. The Dashboard supports gathering, importing, exporting and compiling localization data. It does not know the gameplay situation behind every ambiguous word, whether a joke works, or whether an irreversible-action warning communicates the right consequence. It manages the pipeline; reviewers judge meaning in context.

Can I rely on Play in Editor to approve languages?

Use editor preview for early checks, but test standalone and a packaged release candidate. Epic notes that preview behavior does not reproduce every language and locale condition of runtime. Packaging rules and state-dependent widgets can expose defects that editor-only testing misses.

What is the fastest useful test before translating thousands of strings?

Create a tiny representative fixture with a C++ or Blueprint text, a String Table entry and a dynamic pattern. Gather, export, translate, import, compile and run that fixture under one target culture. Only scale when this round trip works and the result can be demonstrated in the real game.

What should a translator do when “Open” has two meanings?

Request context: the location, player action and object involved. A door command, file-menu action and state label may need different target expressions. If separate meanings share one identity in the source resources, ask engineering to correct the identity model rather than trying to make one phrase serve incompatible jobs.

How much automated QA is enough?

Automate mechanical checks across every locale: entry coverage, missing resources, placeholders and build failures. Add human review of meaning and gameplay behavior, proportionate to risk. An automated pass can establish that a label was delivered, but it cannot prove that the user will interpret it correctly.

How People Translate Quickly | Unreal Engine Localization QA: FText, Gather Text, PO Files and Packaged Culture Testing