A translated form or table can fail even when every string key has a value. Longer labels may crowd controls, right-to-left text may reverse the wrong elements, and validation may reject names that are normal in the target market. Localization testing checks the complete task in context: can a person understand the fields, enter valid local data, read the result, and recover from an error? A small set of representative cases can reveal problems early.
Use realistic text fixtures
Short English labels do not stress a layout. Test longer translations, non-Latin names, mixed-direction email addresses, and numbers with different formatting. Include a narrow mobile viewport and a panel with many columns. A table header that wraps should remain associated with its values; a button that grows should not hide another action. Use test content that resembles actual customer records, not only placeholder words. Avoid making a font-size reduction the default fix for text expansion, since it can harm readability.
Check form semantics
Labels, help text, required status, and error messages should remain connected to their controls after translation. A sentence assembled from fragments may use the wrong word order or plural form. Validate local names, addresses, and phone numbers according to the regions the product supports. The browser and API should agree on accepted input, with the API remaining authoritative. Test invalid submissions and corrected submissions. A translated error that refers to the wrong field can be more confusing than an untranslated label.
Test direction deliberately
Right-to-left layout affects focus order, table navigation, icons, and placement of controls. Use semantic direction and logical CSS properties where possible. Do not mirror URLs, code, charts, or brand marks simply because the page is RTL. Mixed-direction cells may need isolation so punctuation and numbers remain readable. Check sorting indicators and pagination controls: “next” should mean the next set of records, regardless of the arrow's visual direction. Keyboard and screen-reader review should accompany visual screenshots.
Keep data meaning separate from display
A date column may use the viewer's locale while the underlying sort uses a canonical timestamp. A money column should show currency explicitly and sort by an appropriate business value, not by formatted text. Localized numerals and calendars can change what users read without changing stored transaction facts. Test that filtering and exports use the intended values. The API should return render-ready labels and ordering so the client does not sort the current page differently from the full data set.
Include edge states
Forms and tables often look fine with a full set of data but fail in empty, loading, validation, and permission states. Check an empty filtered table, a long error summary, a row action menu, and a form field revealed conditionally. Ensure focus moves predictably when a message appears. Test a user with limited permissions so translated controls do not imply actions they cannot take. Emails and PDFs generated from the same data may need separate localization checks because their rendering engines differ from the browser.
Make review repeatable
Automated checks can find missing keys and invalid placeholders; human reviewers should evaluate meaning and layout in the actual interface. Keep a compact fixture set for each supported writing direction and a few regional data formats. Capture bugs as reusable component improvements so every part benefits. For an SMB product, localization testing need not cover every theoretical locale combination. It should prove that the markets offered by the product can complete their important workflows with accurate, accessible text and data. Review one full journey from entry form through confirmation and later list view. Many defects occur when each screen translates correctly in isolation but the same date, status, or action is described differently across steps.