GDPR-compliant organization
ISO 27001 certified organization
SOC II compliant organization
Find the language errors that a passing build cannot catch. Smartcat combines AI translation quality scoring with native-speaker review, so your team can fix unclear instructions, inconsistent terms and text that does not fit before release.
More than 80 of the world’s largest companies have chosen Smartcat
Localization testing checks whether a translated product is accurate, understandable and usable in a particular language and region. It combines language review with checks of text layout, cultural context and local formats such as dates, numbers and currencies.
Linguistic quality assurance, or LQA, is the language-focused part of that process. Reviewers record errors against agreed categories and severity levels, giving your team a clear basis for accepting a translation or sending it back for correction. Learn about linguistic quality assurance.
A technically valid string can still mislead a user. “Save” can mean storing a setting or rescuing someone. A translation of “Next” may be correct in a dictionary but wrong for the action a button performs. Testing connects the text to the task your user is trying to complete.
Localization issues become more expensive to coordinate when they arrive after the release is approved. A reviewer needs the right build, a developer needs a reproducible report, and the corrected string needs another check in every affected screen.
Users hesitate
A translated label changes meaning, leaving people unsure whether they are confirming a payment or saving a draft.
Layouts break
A longer translation overlaps an icon or disappears behind a fixed-width button.
Support repeats the explanation
Help content uses a different product term from the interface, making an otherwise correct article hard to follow.
Approval loses its meaning
The version a linguist reviewed differs from the version included in the build.
Agree on the source version, target locales and acceptance criteria before testing begins. That makes each issue actionable and each approval traceable to a release.
Language, context and product behavior need different checks. Smartcat supports translation QA and access to language specialists; screen-level checks use the screenshots or test environment your team provides.
| Test type | What to inspect | Example | Responsibility |
|---|---|---|---|
| Linguistic | Meaning, grammar, glossary terms and tone | “Save” translated with the wrong meaning | AI quality assessment plus a native reviewer |
| Cultural | Examples, references, imagery and appropriateness for the audience | A seasonal promotion that makes no sense in the target market | A reviewer familiar with the market |
| Text in the interface | Clipping, wrapping, expansion and reading order | A German settings label hidden behind an icon | Tester checks your screens or build |
| Locale formats | Dates, numbers, currencies, units and addresses | An ambiguous numeric date in a booking confirmation | Your QA team and a locale reviewer |
| Resource integrity | Variables, markup, missing keys and plural behavior | A missing %1$s argument or incorrect quantity form | File checks, application tests and linguistic review |
Your engineering team continues to own functional testing, devices and release behavior. A translation quality score does not establish that a payment flow, keyboard or screen reader works correctly in the application.
Start with one release and a defined set of languages. Keep translation, review and issue resolution connected to the same source material.
Import supported software resources or connect an appropriate integration. Give reviewers key descriptions, screenshots and access to the relevant build where needed. Include language, platform and version in the test brief.
Translate with your glossary and translation memory. Explain product terms, protected names and the intended tone before reviewers start making individual decisions.
The Quality Assurance Coworker identifies translation issues, classifies their type and severity, and produces a quality score. It evaluates the text without editing it.
Assign your own native-speaking experts or Marketplace LQA specialists. Ask them to check the text against the supplied screens and flag issues with enough context to reproduce them.
Linguists or the Reviewer Coworker improve the translation. Developers fix resource or layout defects. Retest changed content and the affected user flows; checking only the changed words does not cover every regression.
Your team decides whether the resolved findings meet the agreed quality bar. Export the approved resources, validate them in the build, and keep the release record for the next update.
The software localization setup guide explains collections, imports and exports. The API and CLI workflow supports teams that want to connect those steps to their release process.
Automated checks help reviewers find issues consistently. Human review adds the product and market judgment needed to decide whether a translation is appropriate in use.
The Quality Assurance Coworker measures quality. It does not edit the translation.
Your reviewers, the Reviewer Coworker and your release process decide when corrected content is ready to ship.
Internationalization testing checks whether your product is designed to support different languages and regional conventions. Localization testing checks whether a particular localized version is correct. Both matter: a translation cannot fix hard-coded English or a layout that assumes left-to-right text.
| Internationalization testing | Localization testing | |
|---|---|---|
| Main question | Can this product support the required locales? | Does this locale work for its users? |
| Typical timing | During development, before and alongside translation | After translation and through release validation |
| Typical checks | Externalized strings, Unicode, flexible layouts, locale-aware formatting | Meaning, terminology, layout, regional conventions and localized links |
Pseudolocalization is a useful early check: substitute visibly altered or expanded text to expose hard-coded strings and layout assumptions. It helps identify engineering problems before you pay to translate the full interface. It does not replace review by someone who understands the target language.
Use a shared checklist and record exceptions. A release can contain both resolved language issues and unresolved functional defects; report them separately so the approver understands the risk.
Fix the scope first, then check the text where users will read it.
Mobile app localization testing connects resource files to a small screen and a changing release. Review onboarding, permission explanations, checkout, notifications and error states with the same care as the main navigation, and test store listing copy against the product users will actually download. Explore mobile app localization.
Apply linguistic and cultural review to dialogue, menus, tutorials and store copy. Give reviewers character information, narrative context and length constraints. Language testing can catch a confusing instruction or an inconsistent character name; gameplay balance, performance and device coverage remain part of your game QA program.
Smartcat brings translation assets, AI quality assessment and human review into the same workflow. You can start with your existing reviewers, add specialists for languages you cannot assess internally, and keep approved terminology available for later releases.
298
projects across 29 countries
Topcon’s team delivered 298 translation projects in two years, covering 31 languages, after consolidating eight translation vendors into one Smartcat workspace.
Topcon’s published case describes consolidating eight translation vendors into one platform. That is evidence about managing translation operations, not a claim that Smartcat removes software defects. Read the Topcon case study.
The cost of localization testing depends on the languages, text volume, review depth and access reviewers need. Platform usage and external specialist work are separate parts of the scope. Review Smartcat’s current plans and request a project-specific quote from the linguists you choose.
Select one release, representative screens and a small set of important flows. Agree on error categories, reviewer responsibilities and the final approver. Compare the findings and effort with your current process before expanding coverage.
Localization testing checks a translated product for language accuracy, usability and suitability for a market. It includes terminology, cultural context, text layout and locale conventions. Reviewers need the relevant strings and product context; application QA remains necessary to confirm that the localized build behaves correctly.
LQA means linguistic quality assurance: a structured assessment of translated language against agreed criteria. A reviewer classifies issues such as accuracy, terminology and style, assigns severity, and records the findings. It is one part of localization testing rather than a substitute for functional or device testing.
Internationalization testing checks the product’s ability to support different locales. Localization testing checks an individual language and regional version. Engineering checks can reveal a hard-coded date format before translation; a native reviewer can then confirm whether the final wording and presentation make sense in that market.
Parts can be automated, including resource validation and translation quality checks. Smartcat’s QA Coworker assesses translation issues and produces a quality score. Native reviewers and application testers still need to evaluate context, cultural fit, layout and behavior. Combine these checks according to the content’s risk and release requirements.
Smartcat supports the language-review side of mobile app and game localization. You can use native reviewers to assess text against screenshots or a test environment you provide. Scope device, performance, gameplay and functional testing with your engineering team or specialist testing provider; those are separate responsibilities.
Pricing depends on the language pairs, content volume, screens, review depth and turnaround requirements. Check the platform plan and request quotes for specialist review separately. A clear test brief helps reviewers estimate their work and prevents an inexpensive string check from being mistaken for full application QA.
Use Smartcat for translation assets, language review and quality assessment, then connect the approved output to your build and test process. Define how findings move into your issue tracker and who verifies fixes. Confirm any required issue-export automation during setup rather than assuming it is part of every integration.
Start with the flows where misunderstanding has the largest consequence: onboarding, payments, account access, error recovery and product instructions. Combine linguistic review with checks of layout, variables and locale formats. Expand coverage as you learn which screens and languages generate the most issues; one quality score does not replace a risk-based test plan.
Didn’t find your answer? Talk to a localization specialist
Bring one string set and its product context. See how AI quality assessment and native-speaker review fit your release process.