Translation and Linguistic Testing

Why it matters

Translators usually work from a spreadsheet or a translation-management system with no view of the screen, so a correct translation of the wrong meaning is common: the English "Open" is both a status and a command, and "Save" means storing data on one screen and paying less on another. Developers rarely read the target language, so a translated placeholder, a missing plural category or an Arabic sentence with a reversed order number passes code review. The first person who sees the defect is often the user.

For the product, these defects cost trust rather than crashes: a shop that cannot count its own products in Arabic, or a bank whose Hindi confirmation is cut off mid-word, looks careless in the market it is trying to win. For the tester, translation testing is a chance to add value with structure: a list of locales, a table of counts, a set of mixed-direction strings and a screenshot per string key find most of these defects without speaking the language.

Linguistic review and functional localization testing are different jobs

A linguistic review (some teams say linguistic QA or in-context review) is done by a qualified native speaker, ideally one who did not translate the text, against the glossary and the style guide. It judges accuracy (does the Arabic mean what the English meant?), fluency, terminology, grammar and spelling, register (how the product addresses the user) and cultural fit. Its output is a list of corrections per string key, not a bug report.

Functional localization testing is done by a tester with the translated build, test data and a checklist, and does not require fluency. It verifies that the translation is loaded and complete, that layout, placeholders, plurals, sorting, search and input work in the locale, and that features behave as they do in the source language. Its output is defects. The two activities meet in one artefact: screenshots of each string in context, which give the reviewer the context the translator never had and give the developer the key to fix.

• Linguistic review needs: the glossary, the style guide, the source text and screenshots; it records string key, current text, proposed text and reason.
• Functional testing needs: the build in each locale, realistic localized test data, a plural count table and a mixed-direction string set; it records string key, locale, screen, expected and actual.
• Order: run pseudo-localization and functional testing first so missing strings do not block the reviewer; run the linguistic review when the strings are stable; retest (confirmation testing) after the corrections land.

What breaks in translated strings: meaning, placeholders, plurals, length

Context defects come from strings translated without seeing where they appear. Short strings are the riskiest: "Open", "Close", "Post", "Clear", "None" and "Home" each have several meanings, and one key reused on two screens with two meanings cannot be right on both. Ask for one key per context and check every short string on its screen.

Placeholders are the parts of a message the code fills in: {name}, {{count}}, %s, %1$s, {0}. A translator may translate one or delete one. Plain %s placeholders are filled strictly in order, so if the target sentence puts the city before the date, the date lands where the city should be; numbered placeholders such as %1$s and %2$s exist so that a translation can reorder them. Test every message that has a placeholder with a real value in every locale, and read the resource files side by side: the set of placeholders in the translation must equal the set in the source.

Plural forms follow the locale, not English. The CLDR plural categories (two for English and Hindi, six for Arabic) and the reason code that picks a form with count === 1 fails in Arabic are covered in the localization testing guide and the lesson on internationalization. The part that belongs to translation testing is the count table: one value per category of the locale, for Arabic 0, 1, 2, 3, 11 and 100, run against every counted message on screen to confirm that each delivered translation carries all the categories its locale needs.

Length and truncation: translated text is often longer than the English source, and Devanagari needs more height for the marks above and below the line. Fixed-width buttons, tabs, table headers, badges, push notification titles and SMS are where it shows. A cut inside an Arabic word gives the last remaining letter its final form, so the fragment can read as a different word; a cut inside a Hindi syllable can leave a half consonant with a visible virama, and a split message can start its next part with a vowel sign that many fonts draw on a dotted circle. Where a hard limit exists, for example a notification title or an SMS segment, measure the translated string against the limit in the unit the system counts.

• Untranslated strings (English left in the Arabic or Hindi interface, see the localization testing guide): compare the key sets of the source and target resource files to find them before opening the app.
• Concatenation (see the lesson on internationalization): a sentence built from fragments in code cannot be translated with the right word order; the fix is one message with parameters, made by the developer.
• Gender and register (see the localization testing guide): the linguistic review checks that the product applies its choice of address, masculine, neutral or by profile, in every string.

Try it: JSON Diff Try it: String Length Counter

Mixed LTR and RTL text inside a translated string

The RTL testing guide explains the Unicode Bidirectional Algorithm (UAX #9) and the bidi test set; translation testing adds one question to them. The translator decides where each placeholder sits in the target sentence, and the values that fill placeholders are often left-to-right: brand names, order ids, emails, URLs, file names and anything a user typed in English. A translated string that reads correctly with an Arabic value can break with a Latin one, so every placeholder needs both.

Three cases come up again and again. First, a value whose digits are followed by a hyphen and Latin letters is reordered inside an Arabic sentence: the order id 1042-A displays as A-1042, while A-1042, which begins with a letter, keeps its order because its digits take the direction of the letter before them. Second, Western digits that follow a Latin value with only spaces or punctuation between them join its left-to-right run: in تقييم {user}: {score} with the user "Sara", the score is laid out next to "تقييم", before the name. Third, a translation that starts with a placeholder: plain text shown without a set direction takes its paragraph direction from the first strong letter (UAX #9 rules P2 and P3), and dir="auto" does the same, so {app} يذكّرك بموعدك غداً. filled with a Latin app name becomes a left-to-right paragraph, aligned left, with the full stop on the wrong side.

• For every message with a placeholder, note where the placeholder sits in each translation (start, middle or end) and test it twice: with an Arabic value and with a Latin value such as a brand, an email or a hyphenated id.
• Ask how the value is isolated: <bdi> or dir="auto" on the element that holds it in HTML, or FSI (U+2068) and PDI (U+2069) around it in plain text. Isolation fixes all three cases: the value is laid out on its own, and UAX #9 skips isolated text when it looks for the first strong letter. Direction marks (U+200E, U+200F) typed or pasted into a translation file are invisible in review and fix only the value they were tested with; convert a suspicious string to code points to see them.
• Check the same string in the Hindi locale too: Hindi is left-to-right, so a defect that appears only in Arabic points at direction handling, and one that appears in both points at the placeholder itself.

Try it: Multilingual Test Data Generator Try it: Unicode Encoder

Worked example: the checkout strings in Arabic and Hindi

A shop externalises its checkout strings in one JSON file per locale. The Arabic and Hindi files arrive from the translation vendor; the tester reads them side by side with the English source before opening the app, then verifies on screen with the counts 0, 1, 2, 3, 11 and 100 and the order id 1042-A.

• cart.items: the Arabic drops the plural structure; for 2 it shows "2 منتج" instead of "منتجان", for 3 it should read "3 منتجات" and for 11 "11 منتجاً". Functional defect, found with the count table; the fix is a message with the six CLDR categories.
• order.shipped: the placeholder {orderId} was translated to {رقم الطلب}, so the formatter prints the raw braces. Functional defect, found by comparing the placeholder sets of the two files.
• order.shipped on screen with 1042-A, once the placeholder is fixed: the id displays as A-1042 inside the Arabic sentence until the value is isolated with <bdi>. Functional defect, found by filling the placeholder with a Latin value.
• status.open: "افتح" is the command "open it"; the key is an order status and should read "مفتوح". Linguistic defect, visible only in context, reported with a screenshot of the orders table.
• Hindi file: cart.items as "{count} आइटम" is acceptable because Hindi has two categories and the loanword does not change, but the reviewer flags "सेव करें" on this screen and "सहेजें" on the settings screen as a terminology inconsistency against the glossary.

en.json
  "cart.items":    "{count, plural, one {# item} other {# items}}"
  "order.shipped": "Order {orderId} shipped to {city}"
  "status.open":   "Open"
  "button.save":   "Save"

ar.json (as delivered)
  "cart.items":    "{count} منتج"
  "order.shipped": "تم شحن الطلب {رقم الطلب} إلى {city}"
  "status.open":   "افتح"
  "button.save":   "حفظ"

hi.json (as delivered)
  "cart.items":    "{count} आइटम"
  "order.shipped": "ऑर्डर {orderId} {city} को भेज दिया गया"
  "status.open":   "खुला"
  "button.save":   "सेव करें"

Try it: Arabic Test Data Generator Try it: Hindi Test Data Generator

Frequently asked questions

References

• Unicode CLDR ProjectUnicode ConsortiumThe Common Locale Data Repository: the locale data for date, time, number and currency formats and plural rules that most platforms use.
• Unicode Standard Annex #9: Unicode Bidirectional AlgorithmUnicode ConsortiumThe algorithm that decides the display order of mixed right-to-left and left-to-right text — the source of most bidirectional-text bugs.
• Inline markup and bidirectional text in HTMLW3CHow the bidirectional algorithm treats inline runs — numbers, names, URLs inside Arabic text — and the markup (bdi, dir) that isolates them.
• The Unicode StandardUnicode ConsortiumThe universal character set and its encoding forms (UTF-8, UTF-16, UTF-32), normalization and the properties of every code point.