Internationalization (i18n) testing asks whether your product is capable of being localized:
are strings externalized rather than hard-coded, is the encoding Unicode end to end, will the layout
stretch when a label doubles in length, and do date, number, and sorting routines read the user's locale
instead of the developer's? Localization (L10n) testing asks whether a specific locale has been
adapted correctly.
The order matters commercially. Internationalization testing runs earlier and is a prerequisite: if
internationalization is broken, every locale fails in the same way, and each new market repeats the same
engineering bill. Localization testing is what you run per locale, per release, once the foundation holds.
Teams that discover this the hard way usually do so after shipping their first non-Latin script.
Localization testing is also a distinct discipline from adjacent QA work, and we scope it that way rather
than folding it into a general pass. Broad usability questions — whether the journey itself makes sense —
belong in usability testing services.
Whether the same build renders correctly across browsers, devices, and operating systems belongs in
compatibility testing services.
Localization testing owns one axis only: does this product behave, read, and look right for this locale?