How to Test Multilingual Product Listings: Prices, Currencies, Units and Translation Errors

Mytrade.kz — Wed, 21 Oct 2026 15:26:06 GMT

By the Mytrade team

A translated product title can look correct while the order is wrong. A comma may change the interpreted amount, a unit may describe the package instead of one item, or a model identifier may be altered during translation.

This checklist is prepared by Mytrade.kz for developers and QA teams working on multilingual product listings. All products, amounts and exchange rates below are synthetic test fixtures. They are not findings from an audit of Mytrade or claims about production behavior. This article was prepared with AI assistance.

1. Start with a fixture that separates meaning from presentation

Keep the product identity, money and physical quantities independent of translated labels. For example:

{
  "sku": "TEST-00042",
  "model": "AX-1500B",
  "price": { "minorUnits": 123456, "currency": "EUR", "scale": 2 },
  "netWeight": { "value": "1.5", "unit": "kg" },
  "itemsPerPack": 6,
  "title": {
    "en": "AX-1500B replacement filter, pack of 6",
    "de": "AX-1500B Ersatzfilter, 6er-Pack"
  }
}

Here, 123456 minor units with scale 2 means EUR 1234.56. The scale belongs to this fixture; do not assume every currency uses two decimal places. Decide whether the weight describes one filter or the entire pack, and encode that distinction explicitly.

Build a small matrix before testing:

Language: English, German, French, Russian, Kazakh and Arabic where supported.
Currency: EUR, USD, KZT and a zero-decimal currency such as JPY.
Viewport: narrow mobile and desktop; include text zoom.
State: listing, product detail, cart, checkout and order confirmation.

Language, region, currency and shipping destination are separate inputs. An English interface does not imply USD, and an Arabic interface does not determine the shipping country.

2. Reproduce number and currency formatting

Run the following JavaScript in a browser console or save it as format-check.js and run it with Node.js. It prints the runtime's formatting, structured parts and Unicode code points so invisible spacing is inspectable.

const amount = 1234.56;

for (const locale of ["en-US", "de-DE", "fr-FR", "ru-RU", "kk-KZ", "ar-EG"]) {
  const formatter = new Intl.NumberFormat(locale, {
    style: "currency",
    currency: "EUR",
    currencyDisplay: "code",
    minimumFractionDigits: 2,
    maximumFractionDigits: 2
  });
  const text = formatter.format(amount);
  console.log(locale, JSON.stringify(text));
  console.log(formatter.formatToParts(amount));
  console.log(Array.from(text, c =>
    `U+${c.codePointAt(0).toString(16).toUpperCase().padStart(4, "0")}`
  ).join(" "));
}

The English US presentation normally uses a comma for grouping and a period for decimals; German uses the opposite. French commonly includes a narrow non-breaking space for grouping. Exact spacing, direction marks and locale data can differ between runtime versions. Record the browser or Node version and the resolved locale when reporting a difference. Pin the runtime when using exact string snapshots.

Check that:

The numeric value and ISO currency remain unchanged when only the display locale changes.
The amount and currency do not separate awkwardly across lines.
Fraction digits follow the currency and your documented display policy. Test JPY separately rather than forcing the fixture's two digits on every currency.
Zero, fractions below one, large amounts and refund values render correctly. Missing prices must not silently become zero.
Ambiguous symbols such as "$" have enough context to distinguish USD from other dollar currencies.

Do not use parseFloat on localized user input:

console.log(parseFloat("1.234,56")); // 1.234, not 1234.56
console.log(parseFloat("1,234.56")); // 1, not 1234.56

Intl.NumberFormat is a formatter, not a general localized-number parser. Define accepted input formats, validate the entire input and convert to a canonical representation. Include regular spaces, non-breaking spaces, Arabic digits, pasted currency codes and invalid mixed separators in input tests. Reject ambiguous input with a useful message instead of guessing.

3. Test translation and conversion as different operations

Translation changes labels and presentation. Currency conversion changes a monetary value using a defined rate. Switching the interface from English to German must not itself convert EUR into another currency unless that is an explicit product requirement.

For a deterministic conversion test, use a fixed fake rate:

Source: EUR 10.00.
Synthetic rate: 1 EUR = 500 KZT. This is a test rate, not a market quote.
Expected converted amount: KZT 5000, before any explicitly modeled fees.

Record the source and target currencies, rate identifier, timestamp and rounding policy in the test evidence. Use decimal arithmetic or an equivalent exact-money design for business calculations. Formatting should happen after the calculation.

Compare line-level and order-level rounding with three synthetic items at EUR 0.01 and a fake factor of 1.5 into a currency displayed with two fractional digits. Under half-up rounding, each converted item rounds from 0.015 to 0.02, totaling 0.06. Converting the 0.03 subtotal first produces 0.045, rounded to 0.05. Neither strategy should be chosen accidentally: document the intended policy and test the backend against it.

When a quote expires or a rate changes, the customer must see the new total and confirm it before submission. The server must validate the amount; a formatted string from the browser is not an authoritative price.

4. Keep units and package quantities explicit

Translation of "kg" does not convert a measurement. Test the quantity, unit, scope and conversion together:

1.5 kg remains the same mass when displayed as 1,5 kg in a locale using a decimal comma.
If pounds are supported, 1.5 kg is approximately 3.30693 lb; show precision appropriate to the product rather than all computed digits.
A pack of six must not become six kilograms. Distinguish price per item, per pack and per kilogram.
For dimensions, preserve labeled axes: length 20 cm, width 10 cm, height 5 cm. Translating the labels must not swap them.
Preserve squared and cubed units: m² and m³ are different quantities. Test superscripts in search, exports and confirmation documents.
Avoid ambiguous abbreviations such as "oz" without specifying whether the field is mass or volume; US and Imperial fluid ounces also differ.

Compare the display against canonical data and a separately calculated expected conversion. Do not use a formatter as the only oracle for both implementation and test.

5. Protect identifiers and translation meaning

Mark SKUs, model identifiers, part numbers and serial numbers as non-translatable. Assert exact equality for AX-1500B across every language and every order step. Preserve leading zeros in identifiers such as 00042 by treating them as strings.

Include these cases in a terminology review:

Latin A versus Cyrillic А: visually similar characters can identify different strings.
"Compatible with AX-1500B" versus "manufactured by AX": compatibility is not manufacturer identity.
"Not included", "used", "refurbished" and "minimum order": losing a negative or qualifier changes the offer.
"From EUR 10" versus "EUR 10": a starting price is not a fixed quote.
Singular and plural at 0, 1, 2 and other values required by each supported language.
Untranslated placeholders such as {count}, raw translation keys and fallback text in a different language.

Have a qualified speaker review high-risk descriptions and purchasing instructions. Automated checks can detect missing strings and altered identifiers, but cannot establish that a translation preserves the commercial meaning.

6. Exercise encoding, long text and right-to-left layouts

Create a fixture containing Kazakh characters ә, ғ, қ, ң, ө, ұ, ү, һ, і; Cyrillic; Arabic; an accented character; a multiplication sign; and an emoji. Check the full path through API responses, storage, page rendering, search, CSV export and order messages. Inspect replacement characters such as �, mojibake and characters that disappear after saving.

Unicode normalization needs a documented policy. For ordinary searchable text, compare composed "é" with "e" followed by a combining acute accent. Do not normalize identifiers blindly if the source system treats their code points as significant.

For long text, use realistic translations plus a deliberately expanded fixture. Test an unbroken identifier, a multi-line title, long unit labels and validation messages at narrow widths and 200% text zoom. Essential specifications, price qualifiers and the final action must remain readable. If a title is truncated, provide access to its full text.

For an Arabic product page, set the page direction deliberately and isolate embedded identifiers:


  رقم الطراز: AX-1500B
  المنتج: Replacement filter

Use the locale formatter for price text and inspect the result in the RTL context. Test brackets, slashes, minus signs, selection, copy/paste and keyboard navigation. Use CSS logical properties where appropriate. Review directional icons individually: not every icon should be mirrored.

W3C recommends markup for directionality when HTML is available. Invisible Unicode direction controls may appear in formatted output; do not strip them globally as a cosmetic cleanup. Investigate unexpected controls in user-supplied identifiers separately.

7. Reconcile the final order

Use a sandbox checkout or a test order flow. Before the customer confirms, compare the selected variant, model, quantity, package size, currency, item prices, shipping, tax, discounts and final total against the server's quote. Then compare the accepted order record and confirmation message against the exact quote accepted by the customer.

Check these transitions explicitly:

Switch the language after adding the item to the cart.
Change the display currency, then return to the original one.
Change quantity and shipping destination.
Refresh the page and restore the cart.
Reopen an expired quote.
Test a failed submission and retry without creating a duplicate order.

If an exchange rate, stock condition or shipping charge changes the offer, require a clear updated review before order submission. A confirmation must not silently display a different currency or total from the accepted order. Localized dates should also make the delivery window unambiguous.

8. Capture evidence that another engineer can reproduce

For each failure, record the fixture ID, build, browser/runtime, locale, currency, viewport, exact steps, expected result and actual result. Include canonical API values as well as the rendered text. Capture Unicode code points when the issue involves spacing or direction. Redact customer data and credentials.

A useful release gate is concrete: identifiers remain intact; prices and units preserve meaning; approved conversions and rounding match the server; critical text remains usable; and the accepted order matches the confirmation in every supported locale. A translated screen is ready only when the customer can verify the same product and commercial terms from listing to confirmation.

Mytrade.kz Engineering